Certificate Transparency - The Public Audit System Behind HTTPS Trust
Even if communication is encrypted with HTTPS, if the TLS certificate presented by the server was fraudulently issued, the encryption is meaningless. If an attacker compromises a Certificate Authority (CA) and obtains a fake certificate, they can impersonate a legitimate domain and intercept communications.
Certificate Transparency (CT) is Google's solution to this problem. By recording the issuance of all TLS certificates in public logs that anyone can audit, it enables rapid detection of fraudulently issued certificates. Since April 2018, Chrome no longer trusts certificates that are not registered in CT logs.
Why Certificate Transparency Became Necessary
CT was born from structural problems inherent in the CA trust model.
Vulnerabilities in the CA Trust Model
Browsers register hundreds of CAs as "trusted root CAs." Any of these CAs has the authority to issue certificates for any domain. This means that if just one CA is compromised, the trust of HTTPS across the entire Internet could collapse.
Real-World Fraudulent Issuance Incidents
- DigiNotar incident (2011): The Dutch CA DigiNotar was compromised, and fraudulent certificates were issued for over 500 domains including google.com. They were reportedly used by the Iranian government to intercept Gmail users' communications, underscoring the importance of email security beyond just encryption. DigiNotar lost trust and went bankrupt
- Symantec mis-issuance (2015-2017): CAs under Symantec were found to have issued numerous test certificates without domain owner approval. Google gradually revoked trust in Symantec certificates
- CNNIC incident (2015): China's CNNIC improperly delegated an intermediate CA certificate, and that intermediate CA issued fraudulent certificates for Google domains
These incidents demonstrated that simply "trusting" CAs is insufficient, and a mechanism for continuously monitoring issued certificates is necessary.
How CT Works Technically
CT consists of three components.
1. CT Log Servers
CT logs are append-only data structures that chronologically record all issued certificates. They use Merkle hash trees, making it computationally infeasible to tamper with recorded entries.
When a CA issues a certificate, it submits the certificate to at least two independent CT log servers. The log server records the certificate and returns an SCT (Signed Certificate Timestamp) - a signed timestamp that proves "this certificate has been recorded in the CT log."
2. Monitors
Monitors are systems that periodically scan CT logs to detect suspicious certificate issuances. Domain owners can use monitors to watch for certificates issued for their domains.
For example, if you own example.com, you can monitor CT logs to immediately detect if a certificate for example.com is issued without your authorization.
3. Auditors
Auditors verify that CT log servers are operating correctly. They cryptographically verify log consistency (that past entries haven't been tampered with) and that entries corresponding to SCTs actually exist in the log. Browsers can also serve as auditors.
Browser Enforcement of CT
CT's effectiveness is ensured by browsers enforcing CT log registration.
- Chrome: Certificates issued after April 30, 2018 are not trusted unless registered in CT logs. Depending on the certificate's validity period, 2-3 SCTs are required
- Safari: Apple has also established its own CT policy and enforces CT in Safari
- Firefox: CT enforcement is being gradually introduced
If you access a site with a certificate not registered in CT logs, the browser displays a warning like "Your connection is not private" and blocks the connection.
Using CT Logs - What Domain Owners Can Do
CT logs are public and searchable by anyone. Domain owners can monitor certificate issuance for their domains using the following tools.
- crt.sh: A CT log search engine operated by Sectigo. Search by domain name to list all certificates issued for that domain
- Google Certificate Transparency Search: A CT log search tool provided by Google
- Certspotter: A CT monitoring service by SSLMate that sends email notifications when new certificates are issued
We recommend periodically checking your domain's certificate issuance status and verifying that no unauthorized certificates have been issued. If you discover a fraudulent certificate, request revocation from the issuing CA.
CT and Privacy Trade-offs
Since CT logs are public information, there are also privacy concerns.
- Domain names included in certificates (including subdomains) are made public. Internal system subdomains (e.g., staging.internal.example.com) may be exposed externally
- Attackers could monitor CT logs to discover new subdomains and target them for attacks
- Using wildcard certificates (*.example.com) can prevent exposure of individual subdomain names
This trade-off requires weighing the security benefits of CT's transparency against the risk of subdomain name exposure. In most cases, the ability to detect fraudulent certificates is more important than keeping subdomain names secret.
Combining with CAA Records
In conjunction with CT, setting DNS CAA (Certification Authority Authorization) records can further reduce the risk of fraudulent certificate issuance.
CAA records restrict which CAs can issue certificates for a domain at the DNS level. For example, to allow only Let's Encrypt to issue certificates:
example.com. IN CAA 0 issue "letsencrypt.org"
With CAA records in place, CAs other than the specified ones cannot issue certificates (per RFC 8659, CAs are obligated to check CAA records before issuance). Combining CT logs for post-hoc detection with CAA records for pre-emptive restriction achieves defense in depth.
Summary
Certificate Transparency is critical infrastructure supporting the trust foundation of HTTPS. Designed with the assumption that CAs may be compromised, it enables rapid detection of fraudulent certificates by recording all certificate issuances in public logs.
Domain owners are encouraged to periodically monitor their domain's certificate issuance status using tools like crt.sh and to set CAA records to restrict which CAs can issue certificates. Use IP Check-san to verify that your connection is protected by HTTPS, and combined with proper security header configuration, comprehensively strengthen the security of your web communications.