The Certificate Transparency Visibility Gap

Certificate Transparency (CT) has been such a success that most people think of it as a mandatory component of the public PKI ecosystem. It's probably because most of us typically only deal with certificates intended for websites and, for those, CT is mandatory… sort of, but actually not necessarily.

The real truth is that CT never made it on the CA/Browser Forum agenda and isn't in Baseline Requirements, which is the main document used to drive certificate issuance. There are several mentions of precertificates (an artifact of CT implementation), but no word on whether CAs should use CT. In theory and often in practice, CT is still optional.

Certificate Transparency is a mechanism designed to impose a level of control over what the trusted certification authorities (CAs) are doing. These CAs are at the core of Web PKI and have the power to issue certificates for any property in the world—unchecked by any technical controls. Historically, that caused a lot of problems.

CT tips the balance by requesting that all issued certificates be logged, meaning published to the public. As part of certificate issuance, CAs submit their certificates to CT logs and embed into them signatures the submissions. Crucially, CT is enforced by user agents, which have the power to reject any certificate for which there isn't sufficient logging proof.

How does this help us? Well, it forces the bad actors out in the open. If someone other than you obtains a certificate for one of your properties, you are now able to observe it in the global stream of public certificates and react. No one just wakes up one day and decides to monitor the CT firehose, but there are companies that offer monitoring as a service. (Red Sift is one of them.)

It's crucial that you have monitoring in place—nothing happens if you don't. For example, a couple of years ago, law enforcement [allegedly] in Germany obtained a certificate for jabber.ru and used it for XMPP traffic interception. It was in the CT logs, but no one was looking, and the interception stayed in place undetected for longer. In another case, FINA, a small CA from Croatia, had repeatedly misissued certificates for the 1.1.1.1 IP address that belongs to Cloudflare, undetected for many months.

On the positive side, even if you're not monitoring CT, you get the benefit of deterrence because misissued certificates stay forever as a matter of public record. Your adversaries may not actually know if you're monitoring or not.

We've already established that CT is not mandatory, technically speaking. But, it so happens that some of the biggest certificate consumers do require it. Apple, Google, Microsoft, and Mozilla all require CT in different places in their products. In practice, if you're publishing a website that's intended to be consumed by a browser, you must use a certificate that's been published to CT.

But not all user agents are browsers, and there is more to the Internet than websites.

One problem inherent in CT is that it's enforced at the client level. Many clients that are not CT aware provide no protection whatsoever. Because of that, your adversaries can skip CT altogether, and you don't get the benefit of its protection.

Modern browsers require CT, and so do the official networking libraries on Apple's platforms and, as of recently, Android. However, there is a whole range of programming languages and TLS libraries out there that don't care. Pretty much anything that's not a browser will ignore CT. Your API servers, even though you may be using CT certificates today, are not actually being protected by CT. Server-to-server communication (e.g., SMTP) is equally at risk. For certain use cases, CT provides no benefit whatsoever.

In the long term, the only solution is that CT is embedded in Baseline Requirements, which will probably happen only if one of the root stores decides to require it.

The situation is complicated by the post-quantum migration. To address the looming threat of a cryptographically-relevant quantum computer, Google is working on a new type of certificate, called Merkle Tree Certificates (MTC). As part of this effort, Certificate Transparency will be rebuilt and combined with certificate issuance. It's possible that we will, in the future, have two types of certificates: MTC and X.509 using post-quantum cryptography. The former will have the benefit of transparency, but it's not clear what will happen in the latter case.

However, there is a way.

Absent any action by you, any CA can issue a certificate for any of your domain names. However, there exists a mechanism that enables you to restrict issuance on a per CA basis, and even on a per CA account basis. It's called Certification Authority Authorization (CAA). CAA can be used to create and distribute issuance policies that all CAs must respect. This mechanism is not foolproof, but it's mandatory for all CAs to support.

To close the CT visibility gap, you only need to choose to do business with CAs who are committed to logging all their certificates to CT. Let's Encrypt, the largest CA by issuance and free, has always logged everything. There are probably other CAs who are doing the same; if you're not sure, ask your CA for an official statement on this matter.

As an example of a positive development, Amazon and DigiCert recently committed to logging everything as well. Their decisions could be related to the changes Chrome recently made in this area. According to the language in version 1.8 of their root policy, logging of precertificates is mandatory, but logging of certificates remains a SHOULD.

If you want to learn more, we have a whitepaper that goes into more detail on how to close the CT visibility gap and utilise CAA to assert control over your public PKI estates: High-Assurance Certificate Transparency Monitoring. This guide can support you to close the CT visibility gap, but also with other aspects of PKI security, including achieving the holy grail of PKI—strong cryptographic validation of certificate issuance.