Certificate Transparency

When you visit a website over HTTPS, it identifies itself with a certificate — a digital credential that proves you’re really talking to the genuine server and not to an attacker. These certificates are issued by organizations called certificate authorities. There are hundreds of them worldwide. Each one could theoretically issue a certificate for any domain whatsoever — even one that doesn’t belong to them at all. Certificate Transparency is a system designed to prevent exactly that: it forces certificate authorities to record every issued certificate in a public, immutable log. Anyone who wants to can inspect this log and check whether unknown certificates exist for their domain.

The cost of forged certificates

A valid but fraudulently obtained certificate is a dangerous weapon. With it, an attacker can run a deceptively authentic copy of a well-known website — and the victim’s browser will still show the green padlock. Such attacks have actually happened in the past: in 2011, the Dutch certificate authority DigiNotar was compromised and unknowingly issued certificates for Google, Mozilla, and others. Users couldn’t detect the fraud because there was no public registry at the time.

Certificate Transparency makes such attacks considerably harder to conceal. Even if a certificate authority issues a fraudulent certificate, it shows up in the log. Website operators can automatically monitor whether new entries appear for their domain. The goal isn’t to make abuse impossible — it’s to ensure it gets detected.

Structure of the log

At the heart of Certificate Transparency is a data structure called a Merkle Tree — a tree in which every entry is mathematically linked to all the others. That sounds abstract, but it has a practical consequence: anyone who deletes or alters an entry afterward destroys the entire checksum of the tree. Tampering is therefore immediately detectable. There isn’t a single global log, but rather many independent ones, operated by various organizations such as Google or Cloudflare.

For a certificate to be recognized as valid by browsers like Chrome or Firefox, it must be recorded in at least two of these logs. As proof, the certificate authority receives what’s called a Signed Certificate Timestamp — SCT for short — a kind of receipt of submission from the log. The website delivers this SCT when establishing a connection, so the browser can verify it without having to look it up in the log itself.

Google made the requirement to include an SCT mandatory for Chrome in 2018. Since then, certificates lacking this proof are classified as untrustworthy — regardless of how reputable the issuing certificate authority is. This was a decisive step, as it effectively made the standard binding for virtually the entire web.

Certificate Transparency in everyday life and in the news

As an ordinary user, you don’t see Certificate Transparency directly — it runs invisibly in the background whenever your browser establishes an HTTPS connection. It becomes more visible to website operators and security researchers. Services like crt.sh make it possible to search the entire public log. Security researchers regularly use this to find newly registered certificates for suspicious domains — often before the corresponding phishing sites are even active.

Certificate Transparency usually comes up in the news when a certificate authority comes under scrutiny. Mozilla and Google maintain public lists of trusted authorities and have, in the past, removed organizations from them when violations became visible in the log — for example, certificates issued without the knowledge of the domain owner. The log serves as evidence in such cases.

A common misconception: Certificate Transparency doesn’t encrypt anything and doesn’t directly protect any data. It’s not a security mechanism that blocks attacks, but rather a transparency and auditing system. Its strength lies in deterrence — anyone who knows that every certificate is publicly visible will think twice before misusing one.