Certificate Transparency (CT) is a system of publicly auditable, append-only cryptographic logs that record every TLS certificate issued by publicly trusted Certificate Authorities. CT logs are operated by independent organizations including Google (Argon and Xenon logs), Cloudflare (Nimbus logs), DigiCert (Yeti logs), and others. Before a certificate can be trusted by modern browsers, the issuing CA must submit the certificate to at least two independent CT logs. Each log then issues a Signed Certificate Timestamp (SCT) as a cryptographic receipt proving the certificate was logged. The entire log history is verifiable using Merkle tree cryptography — any modification to historical entries would be mathematically detectable.
The CT log data is publicly accessible, meaning that anyone with internet access can query the logs to see all certificates issued for any domain — including certificates issued without the domain owner's knowledge or authorization. This public visibility is the core security property of Certificate Transparency: unauthorized certificate issuance becomes visible within minutes to hours of issuance, because the certificate must be logged to be accepted by Chrome, Firefox, and Safari. Domain owners who actively monitor CT logs for their domains can detect unauthorized certificates before attackers have an opportunity to deploy them in phishing or man-in-the-middle attacks.
- CT logs are publicly auditable, append-only Merkle tree logs that cannot be silently modified
- Every certificate issued by a publicly trusted CA must be submitted to at least two independent CT logs
- Logs are operated by Google, Cloudflare, DigiCert, and other trusted operators
- SCTs (Signed Certificate Timestamps) prove a certificate was logged before browser acceptance
- Full log history is cryptographically verifiable — tampering with past entries is mathematically detectable
Certificate Transparency was motivated by a series of high-profile CA compromise incidents in the early 2010s, the most damaging of which was the DigiNotar breach of 2011. DigiNotar was a Dutch Certificate Authority that was compromised by an attacker — later attributed to an Iranian state-linked threat actor — who used the access to issue fraudulent TLS certificates for hundreds of high-profile domains including google.com, yahoo.com, and domains belonging to the CIA and Israeli intelligence services. The fraudulent certificates were used to conduct man-in-the-middle attacks against Iranian internet users, intercepting communications with major services.
The DigiNotar breach went undetected for several weeks because there was no mechanism to discover what certificates a CA had issued. Certificate Revocation Lists and OCSP only help after a certificate's existence is known — they cannot help detect the issuance of certificates that their legitimate domain owners do not know exist. Google engineer Adam Langley and Ben Laurie proposed Certificate Transparency in 2012 as a direct response to this gap, and RFC 6962 was published in 2013. Google began enforcing CT for Extended Validation certificates in 2015 and extended CT enforcement to all publicly trusted certificates in Chrome 66 in April 2018. All major browsers followed, making CT a universal requirement for publicly trusted TLS certificates.
- 2011 DigiNotar breach: fraudulent certificates issued for google.com, CIA, and other high-value domains
- Fraudulent certificates used for man-in-the-middle attacks against Iranian internet users for weeks
- The breach went undetected because no mechanism existed to audit what a CA had issued
- CT was proposed in 2012 specifically to make unauthorized certificate issuance publicly visible
- Chrome 66 (April 2018): CT enforcement made universal for all publicly trusted certificates
A Signed Certificate Timestamp (SCT) is a cryptographically signed promise from a CT log operator that the certificate has been (or will be) included in the log's Merkle tree. SCTs serve as the enforcement mechanism for CT compliance: browsers require valid SCTs from at least two independent logs before accepting a certificate. If a certificate lacks the required SCTs, Chrome returns a certificate error regardless of whether the certificate is otherwise valid — proper chain, valid signature, and not revoked.
SCTs can be delivered to browsers through three mechanisms. The most common is embedding SCTs directly in the certificate itself during the issuance process: the CA submits a precertificate (the certificate without the SCT extension) to the required CT logs, collects the SCTs, and embeds them in the final certificate. SCTs can also be delivered via a TLS extension during the TLS handshake, where the web server includes the SCTs in a separate TLS record alongside the certificate chain. The third mechanism uses OCSP stapling: the CA includes SCTs in OCSP responses, and the web server staples the OCSP response to the TLS handshake. Embedded SCTs in the certificate are the most widely deployed approach.
- SCTs are cryptographic promises that a certificate is (or will be) included in a CT log
- Chrome requires SCTs from at least two independent CT logs — missing SCTs cause certificate errors
- Embedded SCTs: CA embeds SCTs in the final certificate during the issuance process (most common)
- TLS extension: web server delivers SCTs in a separate TLS record alongside the certificate chain
- OCSP stapling: CA includes SCTs in OCSP response which the server staples to the handshake
The primary free search interface for Certificate Transparency logs is crt.sh, operated by Sectigo (formerly Comodo CA). The interface at crt.sh allows searching by domain name, organization name, or SHA-256 fingerprint. Searching for %.example.com (using the percent sign as a wildcard) returns all certificates issued for example.com and any subdomain of example.com, displayed in reverse chronological order. Each result shows the certificate's serial number, the issuing CA, the subject's Common Name and Subject Alternative Names, and the issuance date. Clicking a result shows the full certificate details including the public key, extensions, and which CT logs contain the certificate.
Censys.io provides a more powerful query interface for CT data with support for complex boolean queries, filtering by issuer, subject, date ranges, and key properties. Censys is particularly useful for bulk analysis — for example, finding all certificates issued for a domain over the past year, or all certificates issued by a specific CA for a domain. Both crt.sh and Censys index certificates from all publicly trusted CT logs, providing comprehensive coverage of the certificate ecosystem. For security researchers performing competitive intelligence or threat actor infrastructure mapping, CT logs provide an invaluable and constantly updated dataset of internet-facing TLS infrastructure.
- crt.sh: primary free CT search interface; use
%.example.comto find all subdomain certificates - Censys.io: advanced query interface supporting complex filters for bulk certificate analysis
- Search results show: issuing CA, subject name, SANs, issuance date, and CT log inclusion
- CT logs are an excellent source for subdomain enumeration and attack surface mapping
- Monitoring CT logs for your domain reveals certificates issued without your knowledge or authorization
Certification Authority Authorization (CAA) DNS records are a preventive control that restricts which Certificate Authorities are permitted to issue certificates for a domain. Before issuing a certificate, every publicly trusted CA must check the domain's CAA records and refuse to issue a certificate if the CA is not listed as an authorized issuer. CAA records are TXT records published at the domain name being protected. The syntax follows the pattern: a flag (typically 0), a tag (issue, issuewild, or iodef), and a value. For example: 0 issue "letsencrypt.org" permits Let's Encrypt to issue certificates for the domain.
The issuewild tag controls which CAs may issue wildcard certificates — it operates independently from the issue tag. If only an issue record is present with no issuewild record, the issue restriction applies to both regular and wildcard certificate issuance. Publishing a separate issuewild record allows different policies for wildcard certificates. The iodef tag specifies an email address or URL to receive reports when a CA receives a certificate request that violates your CAA policy. For example: 0 iodef "mailto:[email protected]" sends policy violation notifications to your security team, providing an additional alert mechanism alongside CT log monitoring.
0 issue "letsencrypt.org"— permit only Let's Encrypt to issue certificates for the domain0 issue "sectigo.com"— permit only Sectigo; combine multiple records to authorize multiple CAs0 issuewild ";"— prohibit all wildcard certificate issuance from any CA0 iodef "mailto:[email protected]"— receive CA violation reports at your security team- Publishing CAA records does not prevent all misissuance but limits which CAs can issue against your domain
Manual periodic searches of crt.sh are insufficient for effective CT monitoring — new certificates can be detected and misused within hours of issuance, requiring near-real-time alerting. SSLMate's CertSpotter service provides automated CT monitoring with email or webhook alerts when new certificates are detected for monitored domains. CertSpotter monitors all CT logs in real time and sends alerts typically within minutes of a new certificate being logged. Facebook also provides a CT monitoring service that sends alerts for domain names registered with the service. The crt.sh JSON API (https://crt.sh/?q=example.com&output=json) enables organizations to build their own custom monitoring integrations.
When a CT monitoring alert fires for a certificate you did not authorize, the incident response procedure is clear and time-sensitive. First, retrieve the full certificate details from crt.sh to confirm the issuing CA and the certificate's SANs. Second, contact the issuing CA's revocation team immediately — every publicly trusted CA has a published abuse and revocation contact email address. Under CA/Browser Forum Baseline Requirements, CAs are required to revoke misissuances within 24 hours of confirming the certificate was improperly issued. Providing the certificate's serial number and evidence that it was not authorized by the legitimate domain owner is sufficient to initiate the revocation process.
- SSLMate CertSpotter: free automated CT monitoring with real-time email alerts for your domains
- Facebook CT Monitor: alerting service for domains registered with the service
- crt.sh JSON API: programmatic access for custom monitoring integrations
- On detection: retrieve certificate details, contact issuing CA's revocation team immediately
- CA/Browser Forum requirement: CAs must revoke misissuances within 24 hours of confirmed report