Blog

Update (17 March 2022): A year later, Chrome is about to deploy the next iteration of its CT policy. With this change, which will become active on 15 April 2022, Apple's and Chrome's policies will again be the same. Read more about this change in our new blog post.

Certificate Transparency is a global and collaborative effort to continuously release new public certificates to the public and provide transparency of the inner workings of the public PKI infrastructure. Although technically CAs are not required to publish certificates to CT, relying parties (such as browsers) can require it as a condition to accept certificates as valid. Chrome was the first to enforce this requirement in May 2018. Because Chrome accounts for a very large portion of the browser market, their policy makes CT effectively required for all website certificates.

In October 2018, Apple joined Chrome as the second big relying party to require CT. Their participation also had a significant impact because their ecosystem is not just the browser, but a variety of libraries and applications running on iOS and macOS.

Apple's New CT Policy

Apple's initial CT policy was very similar to Chrome's, but earlier this month, on 21 April 2021, their updated CT policy brought several important changes as well as a divergence in CT requirements for public certificates. Apple first announced the changes came in September 2020, just before CT Days 2020, in a posting to the ct-policy mailing list where Certificate Transparency is discussed. The official confirmation followed in February 2021.

The now-active policy makes three important changes:

• Switch to defining days as periods of 86,400 seconds, which is a very welcome change that simplifies the calculations and minimises the potential for ambiguities. Historically speaking, measuring and understanding certificate lifetime against various requirements was a non-trivial task that often involved rule of thumb determination. Chrome's CT policy (which Apple also adopted for their first iteration) still relies on a complicated approach that's best understood via analysis of Chrome's source code. The current certificate lifetime limit of 398 days (which Apple also instigated) uses the same definition of day. [https://www.hardenize.com/blog/certificate-lifetimes-reduced-to-one-year]
• Additional SCT required for certificates valid for more than 180 days; when CT originally came into effect, certificates were allowed to last much longer. As a result, Chrome required anywhere from two to five SCTs, depending on the lifetime. In September 2020, the certificate lifetime was reduced to just 398 days, for which Chrome requires only 2 SCTs. With Apple's additional new requirement, certificates that fall in the second half of the validity period need to be backed by another SCT.
• New requirement for operator diversity is another welcome change that ensures that SCTs are produced by different entities. Chrome's CT policy already calls for diversity, albeit via the requirement that at least one SCT comes from Google directly. Apple didn't include this requirement in their first policy, but they're adding an explicit operator diversity requirement now. According to the new policy, at SCTs from two different entities are required.

Transition Hiccups

When changes to the PKI ecosystem are made, more often than not there is a transition period when things are not running quite smoothly. At Hardenize, we implemented checks for Apple's new CT policy in March and ran them in parallel with the existing policies. Because this is not something we can test ahead of time, we usually delay full activation of the checks until a couple of weeks later. In the meantime, we monitor the violations and verify them with spot checks. Despite announcing their planned changes months in advance, since April 21 our error tracking picked a number of certificates in violation of the new policy.

We noticed two types of changes. One, where a CA seemingly ignored the new requirements and continued to issue certificates against the old policy. It's not clear if this was a case of not being aware of the new requirements or not being able to deploy them on time. In this situation, we are seeing certificates valid for more than 180 days with only 2 SCTs. GoDaddy leads in this category.

The other problem appears to arise when determining if the additional SCT is needed. It seems that some developers took "180 days" to mean "6 calendar months", thus generating certificates valid for more than 180 86,400-second days with only 2 SCTs. GlobalSign is one notable CA in this category.

We didn't track violations across all certificates this time, but Rob Stradling from Sectigo run some back of the envelope calculations based on the data in crt.sh, which you can find here and in the screenshot below.

Apple is currently not enforcing the new policy, but according to the Apple engineer Bailey Basile, that will happen with iOS 14.6 and macOS 11.4. It is at that point that these certificates will start to fail—if they're used to interact with the Apple ecosystem.

Validating Apple CT Compliance

If you need to verify if your certificates are compliant with Apple's new CT policy, our assessments have been updated and show compliance with Apple's and Chrome's policies separately.

Do note that not having sufficient SCTs in a certificate is not a compliance violation in itself. Although this is rare, it is possible to achieve compliance by transporting SCTs using OCSP or TLS extensions. That's why we show lack of embedded SCTs only as warnings. When you test on our web site, we perform a number of TLS connections to the server. That's where issues [if they are present] will be marked as errors.

What's Next for CT in 2021?

Apple's new CT policy introduced several important improvements, but it also diverged from the original policy framework established by Google. We're now in a situation where we have two different policies, making compliance more difficult. It's not only that the policies are different, the approved CT logs are as well. For now the situation is still manageable, but perhaps this is one area where we can look for improvements in the future? Does it make sense to have a unified policy that all relying parties will use? In their plans for 2021 and with the deployment of SCT auditing Chrome said they would remove the "one-Google CT log" requirement, which means that they will have to update their policy as well. Perhaps that will be an opportunity to close the gap in the requirements.