If you have ever wondered how certificate monitoring tools can discover certificates for your domains without you manually uploading anything — this is the answer. Certificate Transparency, commonly abbreviated CT, is an open framework that requires every publicly trusted TLS certificate to be logged in a publicly accessible, cryptographically verifiable record. The moment a Certificate Authority (CA) issues a certificate for your domain, that certificate is written to a CT log that anyone can read.
This is not a privacy concern — it is a deliberate security mechanism. Understanding how it works helps you understand both the threat model it defends against and how tools like CertControl use it to give you a complete picture of your external certificate inventory.
The problem CT was designed to solve
Before Certificate Transparency existed, the certificate issuance process was essentially a black box. When a CA issued a certificate, only the CA and the certificate holder knew about it. There was no way for a domain owner to find out if a rogue CA — or a compromised one — had issued a certificate for their domain without their knowledge.
This was a real and exploited problem. In 2011, the Dutch CA DigiNotar was compromised, and attackers used it to issue fraudulent certificates for Google, Mozilla, and others. The certificates were used for man-in-the-middle attacks targeting Iranian internet users. DigiNotar was not caught because someone spotted the certificate — it was caught because of suspicious network traffic. By then the damage was done.
Google engineers Ben Laurie and Adam Langley proposed Certificate Transparency in 2012 as a way to make certificate issuance auditable and transparent. The RFC (6962) was published in 2013. By 2018, Chrome required all new certificates to be logged in CT logs or the browser would refuse to trust them.
How CT logs work
A CT log is a publicly accessible, append-only data structure — a Merkle tree — where certificates are stored in a way that makes tampering cryptographically detectable. Here is what happens when a CA issues a certificate:
- The CA submits the certificate to one or more CT logs before or immediately after signing it.
- The log returns a Signed Certificate Timestamp (SCT) — a cryptographic promise that the certificate has been logged. The SCT is embedded in the certificate itself, or delivered via TLS extension or OCSP stapling.
- When your browser connects to a site, it checks that a valid SCT is present. No SCT means the certificate was not properly logged, and modern browsers will reject it.
- The log entry is permanent. Once a certificate is in a CT log, it cannot be removed or altered. Even after the certificate expires, the record remains.
The append-only structure is enforced mathematically. Each new entry in the log is incorporated into a Merkle tree hash. Any attempt to alter an existing entry would change the hash, making it immediately detectable by anyone auditing the log.
Who runs CT logs
CT logs are operated by various organisations — Google runs several (Argon, Xenon), Cloudflare runs Nimbus, DigiCert runs Yeti and Nessie, and several others exist. For a log to be trusted by browsers, it must meet technical and operational requirements set by browser vendors. Google publishes a list of approved logs.
Each CA is required to submit certificates to at least two independent CT logs before issuing. This means that even if one log operator behaves badly, the certificate is still recorded elsewhere and can be audited.
Why this makes your certificates public information
The consequence of CT is straightforward: every certificate issued for a publicly trusted domain is a matter of public record. Anyone can query CT logs and see:
- Which domains and subdomains you have certificates for
- Which Certificate Authority issued each certificate
- The exact validity period (not-before and not-after dates)
- All Subject Alternative Names (SANs) — the full list of domains the certificate covers
- The public key and certificate fingerprint
This information is visible not just to you and your monitoring tools — it is visible to anyone, including security researchers, competitors, and attackers doing reconnaissance. CT log aggregation services like crt.sh make it trivially easy to search for all certificates ever issued for a given domain.
What CT does not cover
It is important to understand the boundaries of what CT logs contain. Only publicly trusted certificates are required to be logged. That means:
- Internal/private CA certificates — certificates issued by your own internal CA are not in CT logs. They are only trusted on devices that have your root CA installed.
- Self-signed certificates — similarly not logged.
- Code signing and email certificates — CT currently covers TLS certificates; other certificate types are handled separately.
This distinction matters for monitoring. CT logs give you excellent coverage of your public-facing certificate inventory, but they do not replace scanning for internal certificates, which requires an agent that can reach internal systems directly.
How CertControl uses CT logs
When you add a domain to CertControl's external scanner, one of the first things the platform does is query CT log aggregation services — primarily crt.sh — to find every certificate ever issued for that domain and all its subdomains. This gives you an immediate inventory of your external certificate footprint without any agent deployment or manual input.
This is how CertControl can surface subdomains you may have forgotten about, certificates issued by CAs you did not authorise, and certificates that are already expired but still visible in the log history. The CT data is combined with active DNS resolution and port scanning to confirm which certificates are currently in use and which represent historical or orphaned issuance.
CT monitoring also enables a specific alert type: new certificate issuance for your domains. If a certificate is issued for your domain by any CA — whether you requested it or not — it will appear in CT logs within minutes. CertControl can alert you to new issuances, which is one of the most effective ways to detect shadow IT, misconfigured automated renewal systems, or in rare cases, mis-issuance by a CA.
What this means for your security posture
Understanding CT changes how you think about certificate management in a few concrete ways:
Your external attack surface is not private. Any subdomain covered by a CT-logged certificate is visible to attackers before they ever probe your infrastructure. If you have staging environments, forgotten services, or test systems with publicly trusted certificates, they are findable. This is a reason to audit your certificate inventory and understand what is externally visible.
Certificate Authority Authorisation (CAA) DNS records matter. CAA records tell Certificate Authorities which CAs are permitted to issue certificates for your domain. CT logs let you verify that those restrictions are being respected. If a certificate appears in CT logs from a CA not listed in your CAA records, something has gone wrong.
Historical certificate data is permanent. Even certificates you no longer use are in the logs. Attackers can use this to understand your infrastructure history, discover services that may still be running under old names, or identify patterns in your certificate management that indicate weak processes.
Automated discovery works in your favour too. The same transparency that exposes your certificates to others lets you monitor your own estate continuously. A good monitoring system will catch new issuances, approaching expiries, and weak configurations before they become problems — using the same data that is publicly available.
Practical steps to take
With the above in mind, here are the things worth doing:
- Search CT logs for your domains now. Go to crt.sh and search for your primary domain. Look at every subdomain that appears. Are they all expected? Are any already expired? Are any issued by CAs you do not recognise?
- Set up CAA records. If you have not already, add DNS CAA records for your domains to restrict which CAs can issue certificates. This is a low-effort, high-value control.
- Monitor for new issuances. Set up monitoring so that any new certificate issued for your domains triggers an alert. This should be part of any external attack surface monitoring programme.
- Audit subdomains with certificates. Every subdomain in CT logs is a potential entry point. Confirm that all of them are intentional, maintained, and not running outdated software or expired certificates.
- Do not assume internal means private. Internal certificates are not in CT logs, but that does not mean they are being properly tracked. An on-premise scanning agent covers the internal inventory that CT cannot reach.
Where CertControl fits in
CertControl uses CT log data as one of several inputs in its external scanner — alongside active DNS resolution, port scanning, and TLS inspection. The result is an up-to-date picture of what is publicly visible and reachable across your domains, with expiry tracking, risk scoring, and alerts built in.
For internal certificates that CT does not cover, CertControl's on-premise agent scans internal networks behind your firewall and feeds the results into the same unified dashboard — so you have one inventory, not two separate tracking problems.