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

kkieffer · 2019-12-18T16:35:35Z

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:

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.

…signed (pinned) certificates using the x509 policy. The SSL policy adds hostname validation, and on ios13 additional restrictions in valid dates which aren't applicable when the client already has the server certificate. This modification allows for IP hostnames and self-signed certificates with longer validity before expiration. Also update the README to include using embedded self-signed certs.