IOS – Why does iOS 13 not trust the own Root CA

iosiphonesafariSecurityssl

No matter what I do, I can't get Safari on the iPhone or iPad to trust a certificate from an internal website. I can look at the certificate and it is shown as "not trusted".

I have imported the Root CA, and I enabled trust for the Root CA. This worked before with iOS 12, but no longer seems to be enough.

The tool "SSL Detective" shows a trusted certificate chain. Safari on the Mac has no issues with the website / certificate (of course, the Root CA had to be imported to the keychain first).

Is this a bug in iOS 13.1.1? Or are there even more hurdles that I don't know of to enable an internal CA?

Best Answer

iOS 13 have increased the security regarding these root certificates. It is thus not a bug, but rather that you have to meet higher requirements in order to get this working.

First of all the process for manually trusted the root certificate has been made slightly more complicated to ensure that users do not unwittingly do this. Before you could import a profile and be done with it, but now you have to also open up Settings > General > About > Certificate Trust Settings, and then toggle "Enable Full Trust for Root Certificates" on for the certificate.

In addition to the above mentioned process change, the requirements for the actual certificate have changed as well:

  • If you're using RSA, the key size must be at least 2048 bites.

  • The hash algorithm must be SHA-2, and not SHA-1.

You can read Apple's explanation of these new requirements here. Note that most of the requirements are only for "server certificates" - you only need to comply with the new requirements for "issuing CAs".

As per your comments, it seemed that your question title was really incorrect and it wasn't the "root CA" trust you had problems with - it was the server certificate that wasn't trusted. In this case, remember that the server certificate should follow all the new requirements listed in the above mentioned link.

These new requirements are, for all server certificates:

  • When used for TLS (as you do in Safari), the DNS name of the server must be in the Subject Alternative Name field

Note that this requirement also means that if you're requesting your web page using an IP-address instead of a name, then the IP address (without port number) should be listed in the SAN field.

And for server certificates issued after the 1st of July 2019, also the following two requirements:

  • When used for TLS, the certificate must contain an ExtendedKeyUsage field with the id-kp-serverAuth OID (i.e. don't use a certificate listed as a client certificate, code signing certificate, email or VPN certificate, etc)

  • When used for TLS, the certificate must be valid for 825 days or fewer

As it turned out your problem was with the validity period of the certificate being more than 825 days. You'll have to reissue the certificate with a shorter validity period.

The reason for the new validity period requirement is that the global CA/B forum (regulates the industry for digital certificates) set new guidelines where CAs must not issue server certificates with a validity period of more than 825 days after the 1st of March 2018. For more information on who was behind the new rule, you can find the voting information here.

Related Question