Certificate Transparency: The CA Accountability Ledger

A Certificate Transparency (CT) log is a public, append-only database that records every SSL/TLS certificate issued by a Certificate Authority (CA), making it impossible for CAs to issue fraudulent certificates without being detected.

Let’s see this in action. Imagine a CA, "BadCA," decides to issue a certificate for google.com without google.com’s knowledge. Normally, this might go unnoticed for a while. But with Certificate Transparency, BadCA must submit this new certificate to a CT log before it can be considered valid by browsers.

# A (hypothetical) submission to a CT log
# This isn't a real command, but illustrates the data
submit_to_ct_log(
    issuer_public_key="...",
    subject_public_key="...",
    not_before="2023-10-27",
    not_after="2024-10-27",
    subject_name="CN=google.com",
    issuer_name="CN=BadCA, O=Malicious Inc.",
    signature="...",
    # ... other certificate fields
)

Once submitted, the CT log returns a signed timestamp (a SCT - Signed Certificate Timestamp). This SCT acts as proof that the certificate was recorded. The CA then embeds this SCT within the certificate itself. When a browser like Chrome or Firefox encounters a certificate, it checks for these SCTs. If the SCT is valid and the certificate is listed in at least one trusted CT log, the browser trusts the certificate. If BadCA tries to issue a fraudulent certificate and doesn’t submit it to a CT log, no SCT will be generated, and browsers will reject the certificate, immediately alerting users to the potential fraud.

The core problem CT logs solve is the trust asymmetry inherent in the public key infrastructure (PKI) for SSL/TLS. Traditionally, browsers (relying parties) implicitly trusted CAs to act honestly. If a CA was compromised or acted maliciously, it could issue fraudulent certificates that browsers would then present as legitimate, enabling man-in-the-middle attacks. CT logs introduce a public, auditable record, shifting from implicit trust to verifiable transparency.

Here’s how it works internally:

1. Certificate Issuance: A CA issues an SSL/TLS certificate.
2. Submission to CT Log: The CA must submit the certificate (or a pre-certificate) to one or more CT logs. This submission is a cryptographically signed data structure.
3. Log Response (SCT): The CT log server receives the submission, verifies its format, adds it to its immutable log, and returns a Signed Certificate Timestamp (SCT) to the CA. The SCT is a cryptographic promise from the log that the certificate has been recorded and will be publicly available.
4. Certificate Embedding: The CA embeds the SCT(s) into the final certificate it issues to the website owner.
5. Browser Verification: When a browser connects to a website, it receives the certificate. It then checks the embedded SCT(s). For each SCT, the browser verifies:
   • The signature on the SCT is valid, proving it came from the specific CT log.
   • The SCT itself has a timestamp that is recent enough to be considered valid.
   • The browser then queries the CT log (or a trusted list of logs) to ensure the certificate is actually present in the log’s history, matching the information in the SCT.
   • Crucially, the browser also checks if the SCT’s timestamp is before the certificate’s not_before date. This prevents CAs from backdating certificates or submitting them after the fact.

This process forces CAs to be honest because any certificate they issue must be publicly logged. If they issue a certificate for evil.com and try to use it to impersonate google.com, that fraudulent certificate will appear in the public logs, and security researchers, domain owners, and automated systems will quickly detect it.

The key levers you control, or rather, that are controlled by the ecosystem, are the set of trusted CT logs. Browsers maintain a list of CT logs they trust. A certificate is only considered valid if it has SCTs from a sufficient number of these trusted logs. CAs must submit their certificates to these trusted logs.

The mechanism of pre-certificates is also important. Instead of submitting the final certificate, a CA can submit a "pre-certificate" to the CT log. This pre-certificate contains all the information for the final certificate but is signed by the CA’s intermediate certificate. Once the pre-certificate is logged and an SCT is received, the CA can then issue the final certificate (signed by the CA’s root or a different intermediate) and embed the SCT from the pre-certificate into it. This allows CAs to get proof of logging before committing to issuing the final certificate.

One thing most people don’t realize is that the CT logs themselves are not necessarily trusted in the same way CAs are. They are trusted to be available and immutable. Their primary role is to provide a public record, not to vouch for the validity of the certificate’s contents (that’s still the CA’s job). The trust in CT comes from the fact that their logs are signed by the log operator and can be independently verified by browsers, and that there are multiple independent logs, making it hard for any single entity to control or censor the logs.

The next concept you’ll encounter is how browsers handle SCT delivery. They can be delivered in multiple ways: embedded directly in the certificate, via the TLS handshake (OCSP Stapling-like), or via the HTTP Public-Key-Pins header (though this is being deprecated).