Certificate Transparency logs are a distributed system that makes it impossible for a Certificate Authority (CA) to issue a fraudulent SSL/TLS certificate without the public knowing.
Let’s see it in action. Imagine you’re a browser, and you just received an SSL certificate for example.com. Before you trust it, you need to verify a few things. One of those is checking if this certificate was logged in a Certificate Transparency (CT) log. Your browser will look at the certificate’s extensions, find the SignedCertificateTimestamp (SCT) list, and then query the CT logs that issued those SCTs. If the log can’t produce a valid SCT for that certificate, or if the certificate isn’t found in the log it claims to be from, your browser will flag the site as untrusted.
Here’s how it works: When a CA wants to issue a certificate for a domain, they first submit a "pre-certificate" to one or more CT logs. The CT log, which is a public, append-only data structure, signs this pre-certificate and returns a Signed Certificate Timestamp (SCT). The CA then embeds this SCT into the final SSL/TLS certificate it issues to the website owner. The browser, upon receiving the certificate, checks for these SCTs and verifies them against the CT logs. This entire process ensures that every issued certificate is publicly recorded and auditable.
The fundamental problem CT logs solve is the inherent trust placed in Certificate Authorities. Historically, if a CA was compromised or acted maliciously, it could issue certificates for any domain, allowing attackers to impersonate legitimate websites and conduct man-in-the-middle attacks. Browsers and operating systems would blindly trust these fraudulent certificates because they were signed by a trusted CA. Certificate Transparency aims to eliminate this single point of failure by making the issuance of certificates a public, verifiable process.
The system has three main components:
- Monitors: These are independent entities that scan the CT logs for new certificates, looking for suspicious activity, misconfigurations, or policy violations. They act as an independent audit.
- Reporters: These are typically domain owners or security researchers who actively monitor CT logs for certificates issued for domains they care about. If they find an unauthorized certificate, they can alert the domain owner or the CA.
- Auditors: These are entities that periodically verify the integrity of the CT logs themselves, ensuring they are append-only and haven’t been tampered with.
The exact levers you control as a website operator are minimal, but crucial: when you obtain an SSL certificate, ensure your Certificate Authority is submitting pre-certificates to CT logs and embedding the resulting SCTs into your final certificate. Most modern CAs handle this automatically. However, if you’re using a less common CA or have a highly customized setup, you might need to explicitly configure your CA to participate in CT logging.
The surprising part is how the structure of the CT log itself enforces immutability. Each entry in a CT log is a hash of the previous entry, forming a Merkle Tree. Any attempt to alter a past entry would invalidate the hashes of all subsequent entries, making tampering immediately obvious to anyone auditing the log. This cryptographic chaining is the core of the log’s integrity guarantee.
The next concept to understand is how browsers use this logged data to enforce trust and the implications for certificate revocation.