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)

Google Chrome established a policy requiring CT support for all certificates issued after 30 April 2018, and it began enforcing this verification starting with Chrome 68, released in July 2018. When you make an HTTPS connection with a certificate that has no SCT attached, Chrome displays a security warning. This decision accelerated the adoption of CT, and public certificate authorities have to treat CT log registration as a prerequisite for issuing certificates. 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 2015 the CT logs revealed that a certificate authority under Symantec had issued test certificates for Google's domains without authorization. Further improper issuances by the company subsequently came to light, and ultimately, in 2017, Symantec's certificate authority business was 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.