Certificate Transparency logs — the public, append-only ledgers that record every TLS certificate issued by every trusted certificate authority — turned what used to be an undetectable attack (a CA issuing a fraudulent certificate for a domain it doesn't control) into an auditable, monitorable event that domain owners can watch in near-real time
Certificate Transparency (CT) was proposed by Google engineers in 2013 and became a hard requirement for Chrome in 2018: any TLS certificate not logged in at least two CT logs is now rejected by Chrome with an error, regardless of whether the certificate is cryptographically valid. Understanding CT reveals not just a security mechanism, but a fundamentally different approach to trust infrastructure — one built on public verifiability rather than private assurance.
The problem CT was designed to solve
The traditional CA model has a trust chain problem. There are approximately 150+ certificate authorities trusted by default in major browsers. Any one of them can issue a certificate for any domain — including domains they have no relationship with. This means trust in any individual CA's good behaviour is only as strong as the weakest CA in the entire ecosystem.
Historical incidents that exposed this weakness:
In 2011, DigiNotar (a Dutch CA) was compromised and issued fraudulent certificates for Google.com, used in man-in-the-middle attacks against Iranian users. The attack was only discovered weeks later when a user noticed their browser's certificate fingerprint had changed.
In 2012, Trustwave (a US CA) issued a subordinate CA certificate to a customer for corporate network monitoring — effectively allowing that customer to issue certificates for any domain. This was a deliberate policy decision, not a compromise.
The core problem: there was no public record of what certificates had been issued. Domain owners had no way to monitor whether a CA had issued a certificate for their domain without their knowledge or authorization.
How CT logs work: append-only Merkle trees
Certificate Transparency logs are cryptographic append-only ledgers — once a certificate is added, it cannot be modified or removed without detection. The structure relies on a data structure called a Merkle tree (also used in Git and Bitcoin):
The Signed Certificate Timestamp (SCT): when a CA submits a certificate to a CT log, the log returns an SCT — a cryptographic promise that the certificate has been added (or will be added within a merge delay) to the log. This SCT must be included in the certificate or delivered via TLS handshake for Chrome to accept the certificate.
The Merkle tree audit proof: because all certificates are stored in a cryptographic tree structure, anyone can efficiently verify that a specific certificate is present in the log without downloading the entire log. If the log tries to insert or modify a certificate without updating the tree root, the inconsistency is detectable.
Two CT log operators don't collude independently: the Chrome CT policy requires SCTs from at least two different, independent CT log operators. A certificate is only accepted if it's verifiably logged with two separate parties — meaning both would need to be compromised or colluding to hide a fraudulent certificate.
What CT logs expose for domain owners
Searching CT logs for your domain reveals every certificate ever issued for it — including certificates you didn't request and certificates you didn't know existed.
What domain owners find in CT log searches:
Subdomains they didn't know were externally accessible: a development team may have provisioned staging.example.com with a Let's Encrypt certificate — the CT log records this, making the subdomain discoverable to attackers long before anyone notices it's externally reachable.
Certificates from unexpected CAs: if your corporate policy is to use only certificates from your contracted CA vendor, a CT log alert showing a certificate from Let's Encrypt for your domain could indicate an employee provisioning unauthorised infrastructure or a security gap.
Historical certificate inventory: CT logs preserve records going back to 2013 for participating CAs. Querying crt.sh (a free CT log search interface) for a domain returns a complete certificate issuance history — useful for infrastructure audits, expired certificate identification, and understanding previous subdomain structures.
Monitoring CT logs: proactive versus reactive
Reactive CT log use (looking up certificates after suspicion arises) is useful but misses the point of CT. Proactive monitoring watches for new certificates as they're issued:
Certstream: a free, real-time stream of certificate issuance events from CT logs, available as a WebSocket feed. Development teams use this to watch for new certificates on domains they own — typically receiving notification within minutes of a certificate being issued.
Commercial CT monitoring services: vendors like Sectigo, DigiCert, and various threat intelligence platforms offer CT alerting as a feature — sending notifications when any new certificate is issued for your domain or its subdomains.
The attack surface this monitoring reveals: a phishing domain registered as secure-login-example.com that obtains a TLS certificate appears in CT logs immediately, giving the target organisation a window to investigate and potentially act before the phishing campaign fully launches.
Certificate Transparency and wildcard certificates
Wildcard certificates (*.example.com) cover all first-level subdomains under a domain. They're logged in CT just like standard certificates, but they reveal less specific information about subdomains — *.example.com in a CT log tells an observer that subdomains exist but not which specific subdomains are active.
Multi-SAN certificates (covering multiple specific Subject Alternative Names) log each covered name explicitly — api.example.com, auth.example.com, admin.example.com each appear in the certificate and therefore in CT logs. This gives a more detailed picture of infrastructure to anyone monitoring CT logs, which is a consideration when deciding between wildcard and multi-SAN certificates for internal services.
How to use the SSL Checker on sadiqbd.com
- Verify CT inclusion on your certificates: check that your certificate includes SCTs (Signed Certificate Timestamps) — the SSL Checker displays certificate details including SCT presence, which is required for Chrome acceptance
- Audit unexpected subdomains: visit crt.sh and search for your domain to see the complete CT log history, then compare discovered subdomains against your known infrastructure inventory
- Chain validation alongside CT: use the SSL Checker to confirm the complete certificate chain is valid and complete — a chain with missing intermediate certificates fails in some clients even with valid leaf certificate CT logging
Frequently Asked Questions
If CT logs are public, doesn't that help attackers discover subdomains they could target? Yes — this is a real and acknowledged trade-off. Security researchers call this the "subdomain discovery problem": CT logs make subdomain enumeration significantly easier because attackers can look up every certificate ever issued for a domain rather than having to brute-force guess subdomains or rely on DNS zone transfers. The security consensus is that this trade-off is worth making — the benefit of detecting fraudulent certificates and monitoring for malicious lookalike domains outweighs the cost of making legitimate subdomain enumeration easier. The correct response is not to rely on subdomain obscurity as a security control — any subdomain that has a publicly accessible TLS certificate should be treated as publicly discoverable regardless of whether it's listed in CT logs.
Is the SSL Checker free? Yes — completely free, no sign-up required.
Try the SSL Checker free at sadiqbd.com — verify any domain's SSL certificate validity, expiry, and chain in seconds.
