Certificate Transparency - Public Logging of TLS Certificates

About 2 min read

Certificate Transparency (CT) is a framework that records every issuance of SSL/TLS certificates in public logs so that anyone can audit them. Its goal is to allow domain owners and browser vendors to quickly detect when a certificate authority (CA) issues a fraudulent certificate. Google engineers Ben Laurie and Adam Langley proposed it as RFC 6962 in 2013, and today major browsers led by Chrome require CT support.

The DigiNotar Incident and the Origins of CT

The direct catalyst for CT was the 2011 breach of the Dutch certificate authority DigiNotar. Attackers penetrated DigiNotar's systems and issued more than 500 fraudulent certificates, including ones for google.com. These certificates were used in man-in-the-middle attacks against users in Iran, and Gmail communications are said to have been intercepted.

This incident exposed a fundamental weakness of PKI (public key infrastructure): any certificate authority could issue a certificate for any domain, and domain owners had no way of knowing about it. DigiNotar lost trust and was forced out of business, but CT was designed as a technical mechanism to prevent similar incidents from recurring.

How CT Logs Work - Merkle Trees

CT logs are managed using a Merkle tree (hash tree), a cryptographic data structure. Each time a new certificate is added to the log, the tree is updated, and tampering with a past entry causes a hash value mismatch that can be detected immediately.

CT logs are operated by multiple independent organizations (such as Google, Cloudflare, and DigiCert), and a certificate authority must register a certificate in at least two logs when issuing it. Unless the log operators collude, concealing a fraudulent certificate is extremely difficult.

Verifying the SCT (Signed Certificate Timestamp)

When a certificate authority registers a certificate in a CT log, the log server returns an SCT (Signed Certificate Timestamp). The SCT is cryptographic proof that "this certificate was recorded in the log," and the browser verifies the SCT during the TLS handshake.

There are three ways to deliver an SCT: embedding the SCT in the certificate itself (an X.509 v3 extension), sending it via a TLS handshake extension, and sending it via OCSP stapling. Major certificate authorities led by Let's Encrypt adopt the certificate-embedding method.

Chrome Makes CT Mandatory (2018)

Since April 2018 (Chrome 68), Google Chrome has required CT support for all newly issued certificates. When you make an HTTPS connection with a certificate that has no SCT attached, Chrome displays a security warning. This decision decisively accelerated the adoption of CT, and today virtually every public certificate authority has built CT log registration into its standard process. CT has become indispensable as the foundation that underpins the trustworthiness of digital certificates.

Detecting Fraudulent Certificates and Practical Use

Anyone can search CT logs using crt.sh or Google's Certificate Transparency Search. By monitoring certificate issuance for their own domains, domain administrators can detect the issuance of fraudulent certificates early. In fact, in 2017 the CT logs revealed that a certificate authority under Symantec had issued fraudulent test certificates for Google's domains, which ultimately led to Symantec's certificate authority business being sold to DigiCert.

Monitoring CT logs is an important mechanism that complements the trust model of PKI based on public-key cryptography. See also our articles on the basics of encryption, phishing protection, and browser password safety.

cryptography books on Amazon offer more to explore.