How to fix “This Connection is Not Private” error on Apple macOS 11.4 and iOS 14.6
Recently, macOS 11.4 and iOS 14.6 impose some new requirements on publicly-trusted SSL certificates which were issued on or after April 21 2021. In general, as a website owner you don’t need to worry about this change, as it’s your certificate authority’s job to stay abreast of policy changes and provide you certificates which are compliant with web browser policies..
Some certificate authorities, namely GoDaddy, GlobalSign, Certigna, and WidePoint, messed up and issued tens of thousands of non-compliant certificates between April 21 and April 27 that will not work in macOS 11.4 and iOS 14.6 (Safari will say “This Connection is Not Private”). If you got a certificate from one of these CAs during this time frame, you might need to replace your certificate. You can use this Certificate Transparency Policy Analyzer to check if your website is affected.
Table of content:
Background:
Apple and Chrome require certificate authorities to publish information about their certificates in public Certificate Transparency logs so that misbehavior by certificate authorities can be detected. For example, Cert Spotter monitors Certificate Transparency logs and alerts you when a certificate is issued for your website that you didn’t authorize.
Before issuing a certificate, the certificate authority publicly announces its intent to issue the certificate by publishing a precertificate in multiple Certificate Transparency Logs. Precertificates are similar to certificates and contain the same information that will be included in the certificate, such as the domain names that the certificate will be valid for.
Each Certificate Transparency log returns a receipt, called a Signed Certificate Timestamp or SCT, promising to publish the precertificate. The certificate authority embeds the SCTs in the certificate. When Chrome or Safari load a website, they examine the SCTs, and if the certificate lacks a sufficient number of SCTs, they reject the certificate and refuse to load the website.
Estimating the Amount of Non-Compliance
To estimate how many non-compliant certificates have been issued, Rob Stradling of crt.sh searched for precertificates which were issued on or after April 21, are valid for more than 180 days, and which were logged to fewer than three logs. This provides a lower bound on the number of non-compliant certificates, since if a precertificate is in fewer than 3 logs, its corresponding certificate can’t possibly have SCTs from 3 or more logs. However, it’s only a lower bound: a precertificate might be in 3 or more logs, but the corresponding certificate doesn’t necessarily embed SCTs from all of them.
Here’s a summary of the data collected by Rob:
|
Certificate Authority |
# Non-Compliant Precertificates |
|
GoDaddy |
76,376 |
|
GlobalSign |
183 |
|
Certigna |
15 |
|
WidePoint |
5 |
To get an alternative lower bound, SSLMate searched for certificates (not precertificates) issued between April 21 and May 3 which are valid for more than 180 days, embed at least one SCT, and which are not compliant with Apple’s Certificate Transparency policy. (We skipped certificates containing zero SCTs, as such certificates were probably intentionally not logged, which is permissible as long as you don’t need your certificate to work in Safari or Chrome.) Evaluating the certificate, rather than the precertificate, definitively tells us whether or not the certificate is compliant. However, most certificate authorities only log pre-certificates, and their certificates will only be logged if they’re discovered and submitted by a third party, such as Googlebot. Therefore, evaluating certificates doesn’t provide us a full picture of a certificate authority’s compliance.
How Did This Happen?
Looking at the non-compliant certificates, some interesting patterns emerge.
As for GoDaddy, the validity periods of the non-compliant certificates range from 181 to 254 days. None of the certificates has a validity period of a full year, suggesting that only reissued certificates (which have the same expiration dates as the original certificate) were affected. It’s possible that GoDaddy was consulting the issuance date of the original certificate, rather than the reissued certificate, when deciding how many SCTs the reissued certificate needed to have.
Every single one of GlobalSign’s non-compliant certificates has a validity period of 182 days, 14 hours, 54 minutes, and 36 seconds. This happens to be just under the number of days in the six month period between April and October. It appears that GlobalSign thought that Apple’s new policy affected certificates with validity periods greater than six months rather than greater than 180 days.
Resolution:
Fortunately, GoDaddy and Global design have resolved this issue. Customers whose SSL certificates are still affected must generate CSR > Rekey and install SSL certificate again and it should be all good.
