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 (all certificates issued through SSLMate are compliant).

Unfortunately, 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 our Certificate Transparency Policy Analyzer to check if your website is affected. If you're a Cert Spotter customer, Cert Spotter checks for this problem automatically and will alert you if you need to take action.

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.

The number of required SCTs depends on the certificate lifetime. For certificates issued before April 21, 2021, both Chrome and Apple used the following policy:

Lifetime	# of SCTs From Distinct Logs
< 15 months	2
15 - 27 months	3
27 - 39 months	4
> 39 months	5

But for certificates issued on or after April 21, Apple now requires:

Lifetime	# of SCTs From Distinct Logs
180 days or less	2
181 to 398 days	3

This change was communicated to certificate authorities ahead-of-time, and most of them got the memo. Unfortunately, certificate authorities often have a hard time complying with the rules.

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 precertificates, and their certificates will only be logged if they're discovered and submitted by a third party, such as the Googlebot. Therefore, evaluating certificates doesn't provide us a full picture of a certificate authority's compliance.

Here are our results, broken down by issuance date so that we can determine when each CA fixed the problem:

Certificate Authority	Issuance Date	# Non-Compliant Certificates
GlobalSign	2021-04-21	39
GlobalSign	2021-04-22	72
GlobalSign	2021-04-23	31
GlobalSign	2021-04-24	14
GlobalSign	2021-04-25	10
GlobalSign	2021-04-26	338
GoDaddy	2021-04-21	67
GoDaddy	2021-04-22	72
GoDaddy	2021-04-23	50
GoDaddy	2021-04-24	47
GoDaddy	2021-04-25	32
GoDaddy	2021-04-26	74
GoDaddy	2021-04-27	39

Our data increases the lower bound for GlobalSign to 504 non-compliant certificates.

How Did This Happen?

Looking at the non-compliant certificates, some interesting patterns emerge.

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.

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.