Relaxing the validation of server certificates when using self-signed embedded certs

[kkieffer]

When using embedded self-signed (pinned) certificates, the default validation is to use the SSL policy, which is more restrictive than necessary. In addition to validating the x509 certificate, the SSL policy checks that the hostname you are connecting to is listed on the certificate. In iOS13 and MacOS Catalina, Apple has increased the certificate requirements. The hostname must be in the subject alternative field, and the certificate cannot be valid for more than 825 days.

When using certificate pinning, checking the hostname is not necessary because the client is only using the embedded cert for verification (see https://tools.ietf.org/html/rfc2818#section-3.1). Checking the hostname also precludes connecting to a server by IP address instead of a hostname.

To provide flexibility for self-signed certificates, this pull request changes the trust policy from SSL to x509 only when evaluating self-signed certificates.

Also updated the README to describe using embedded self-signed certs.

Motivation and Context

Relaxes certificate requirements that aren't necessary for pinned self-signed certs.

How Has This Been Tested?

Running swift tests, all tests pass. Have also validated against my own server using a self-signed cert that doesn't pass the requirements in ios13.

Checklist:

• [x] I have submitted a CLA form
• [x ] If applicable, I have updated the documentation accordingly.
• [n/a ] If applicable, I have added tests to cover my changes.

[kkieffer]

Just checking in to see if there are any comments/questions on this PR....

[djones6]

@kkieffer This looks and sounds reasonable, though I'm not a subject matter expert. @billabt any thoughts?

[kkieffer]

@billabt would you review?

[CLAassistant]

All committers have signed the CLA.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information