New iOS 13 and macOS 10.15 TLS Certificate Requirements

So, I recently upgraded my work MacBook Pro to the latest and greatest of the macOS family, Catalina 10.15, because that’s what my compulsive desire to always have the most up to date system demanded. Shortly after though, I started to noticed that a number of our internal CA signed TLS certificates that had been generated over the last few months were no longer being accepted by Safari, Chrome or Brave browsers (Firefox didn't seem to be affected), at all.

With the only hint at what could be causing the issue being Chrome's dreaded NET::ERR_CRT_REVOKED, I headed down the CRL road in an attempt to determine whether the serial number for the certificates in question had somehow made its way onto this list, which itself is extremely unlikely as this is a manual process. Needless to say, it did not. 

Beginning to clutch at straws, I noticed that the serial numbers on the certificates returned by Chrome and Firefox were slightly different with one being hex pairs and the other decimal. Unfortunately this too was just a red herring, as that's exactly what they were - presentational differences of the same value. Just to be sure though, as it would appear I had lost confidence to convert between base 16 and base 10 on the fly, I compared the SHA-256 fingerprints of the two and confirmed they were indeed the exact same certificate. No luck here.

Thinking this was starting to look like it was a bit more involved, I put the issue onto the 'things to investigate when I have more time' pile, as this was only really currently affecting my machine and all other services in production were operating as normal.

Moments later, a colleague who was also looking into the issue popped over and casually queried "What version of macOS are you on?", "Catalina" I reluctantly replied, "Yeah.. it appears Apple have now limited the validity of TLS certificates issued after 1st July 2019.".

The CA/B Forum

It turns out that there’s a magic number, and it’s 825 days, which has come about after Ballot 193 was passed by the CA/B Forum in March 2017 requiring that any certificates issued after 1st March 2018 should not have a validity period greater that this, being taken down from 39 months.

It appears then that in addition to some other restrictions, such as the SHA-1 hash algorithm deprecation, Apple is now taking this one step further and explicitly rejecting any violations flat-out in a move to secure their operating systems. The full list of Apple's requirements can be seen on their website, but essentially:

  • TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS. 
  • TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS. 
  • TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

And from March 2019:

  • TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
  • TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

Crucially, the last line states "Connections to TLS servers violating these new requirements will fail and may cause network failures", and I can confirm that this indeed the case.

Don't get caught out

Today's lesson? Start auditing your certificates and replacing any that may be in violation to the above, as there will come a day when they will break. Get head of the curve whilst you can.

© Andrew Lees 2022