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?

3 Answers 3


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.

  • 1
    Thank you for the link. The only requirement that I am not sure about is „TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID“. I don‘t understand what this means, so it‘s likely that I did not do this correctly. Everything else I did according to the guideline. I did enable the trust: This was also necessary with iOS 12.
    – user89124
    Oct 7, 2019 at 5:38
  • 1
    Ah, read the link again: The certificate (server cert, not root or intermediate) is simply valid for too long! I made it for 10 years, but it can only be valid for two years or less. This must be it.
    – user89124
    Oct 7, 2019 at 5:43
  • 1
    The id-kp-serverAuth OID means that when you make the certificate, it is written in ExtendedKeyUsage what the certificate is "for". I.e. it can be marked as being a client certificate, code signing certificate, email certificate, VPN certificate, etc. You need it to be marked as a server certificate to be accepted by for example Safari for TLS.
    – jksoegaard
    Oct 8, 2019 at 20:25
  • And yes, the validity period of 10 years is definitely a problem. The CA certificate is usually long lived, but the trend the last few years have been to limit the validity period of server certificates quite a lot. For iOS 13 it needs to be max 825 days (i.e. 2.25 years). You'll see that often you want even shorter validity periods - for example the very popular Let's Encrypt certificate have a validity period of just 90 days.
    – jksoegaard
    Oct 8, 2019 at 20:27
  • To confirm: It was the duration that caused the error. After upgrading the Mac to Catalina I got the same error as on iOS 13. I then replaced the certificate with one that was valid 825 days, and both the Mac (Safari and Chrome) and the iOS 13 devices are happy now.
    – user89124
    Oct 13, 2019 at 10:39

I myself am working on this for days now. 2 whole weekends without any luck. So right now I try to get faith again. (to get iOS 13 and iPadOS to accept a certificates descendent from a self-signed root-ca)

My conclusion after wasting 2 full weekends was right. The pki-tree and certificates were right.

The main reason that the certificateson iOS were not accepted was because Apple decided to add an additional security option for that in a completely different area! ( I'm pissed off by Apple in my 10+ years using Apple-Devices ). That's somthing I would expect from Win10 not iOS13 and iPadOS.

For others that are stuck with this.

  • Step1) Upload your root-ca to you iOS/iPadOS-device (by Airdrop, email, ...)
  • Step2) Airdrop asks for Installation else open in Files-App
  • Step3) Goto Settings > General > Profiles and install the proposed cert & enter you passcode (not finished yet)
  • Step4) Goto Settings > Info > "Certificate-Settings"
  • Step5) activate the open certificate

The new splitted menus are a bit of a pain and not really intuitive. That's that.

  • Thanks so much, I was missing step 5. Note that, at least in iOS 16, the path is Settings > General > Info > Certificate Settings.
    – not2savvy
    Jan 7, 2023 at 12:03
  • Apple changed it again, in the latest version its now: Settings > General > About > Certificate Trust Settings
    – ZaxLofful
    May 7, 2023 at 5:15

In iOS 13, which had been released on September 19, 2019, Apple has chosen to retroactively invalidate certain certificates that have been issued after July 1, 2019.

In particular, a certificate is affected if it has a validity period of more than 825 days.

If you have such a certificate, it will no longer work after the update to iOS 13.

In this case I would call it a bug in iOS 13.

  • Your answer is just a copy of some of the information from my previous answer? - Your opinion about this being a bug and highlighting of it being "retroactively" is really odd. It's not a bug - it is completely intentional, and it's not just some arbitrary decision that Apple made. It's an industry-wide change.
    – jksoegaard
    Oct 13, 2019 at 20:14
  • Can you give a pointer for the claim that it is an industry-wide change? I did not find one. Also, Android, and Desktop OSs seem not to show the same behavior. Probably because it has severe implications in private networks.
    – aventurin
    Oct 13, 2019 at 20:18
  • I have supplemented my answer with the explanation of why it's an industry wide change. Basically, ordinary CAs are no longer allowed to issue certificates with a validity period of more than 825 days. Private CAs used on internal networks are ofcourse not bound by these new rules - but the rules have been changed for a reason, so it makes sense for Apple (and eventually others) to implement the same restriction. Regarding desktop OSes - the same requirement is in macOS Catalina.
    – jksoegaard
    Oct 13, 2019 at 20:22
  • I have just linked to more information about the change, you'll see that multiple browser vendors voted to implement this change - Apple, Microsoft, Google, Opera and Qihoo. Mozilla (behind Firefox) choose not to vote. Also note that the guy behind the actual proposal is a lead engineer on Google Chrome. His original proposal was to limit the validity period to 540 days - so 825 is a compromise.
    – jksoegaard
    Oct 13, 2019 at 20:25
  • Thank you for the link! In my point of view this change should only apply to "Publicly-Trusted Certificates", and "Extended Validation Certificates", but neither to certificates that are signed by a private CA nor to self-signed certificates.
    – aventurin
    Oct 13, 2019 at 20:55

You must log in to answer this question.