Certificate Transparency: How Public Logs Reveal Every SSL Certificate Ever Issued for Your Domain

Every publicly trusted SSL certificate issued since 2018 is recorded in a set of public, append-only logs — and this system exists specifically because certificate authorities have, on occasion, issued certificates they shouldn't have

Certificate Transparency (CT) is a framework requiring newly issued publicly-trusted SSL/TLS certificates to be logged in public, cryptographically verifiable logs — and major browsers now require this logging as a condition for trusting a certificate at all. Understanding CT explains both a layer of web security infrastructure most people never directly interact with, and provides a genuinely useful tool for domain owners: a way to discover every certificate ever issued for their domain, including ones they didn't request.

The problem CT was designed to address

Certificate Authorities (CAs) — the organisations that issue SSL/TLS certificates, after verifying that the requester controls the domain in question — are trusted by browsers and operating systems to only issue certificates to legitimate domain controllers. However, CA failures have occurred historically: instances where a CA issued a certificate for a domain to someone who didn't actually control that domain — whether due to a CA's verification process being flawed, compromised, or (in some documented historical cases) a CA being compromised entirely by an attacker who then issued certificates for arbitrary domains.

A fraudulently issued certificate for, say, accounts.google.com — if trusted by browsers — could enable a sophisticated attacker to impersonate that site convincingly (intercepting traffic that's supposedly protected by HTTPS, in certain attack scenarios involving network-level interception combined with the fraudulent certificate). Several real-world incidents involving specific CAs issuing certificates without proper authorization, for high-profile domains, contributed to the push for a systematic mechanism to detect such occurrences.

How CT logs work

Append-only, cryptographically verifiable logs: CT logs are structured as Merkle trees (the same underlying data structure discussed in a previous article on hash functions and Git) — allowing anyone to cryptographically verify that a specific certificate is included in the log, and that the log hasn't been tampered with (entries can't be secretly removed or modified without detection, given the Merkle tree structure's properties).

Multiple independent logs, operated by multiple organisations: CT isn't a single centralized log — multiple organizations (including major browser vendors, CAs themselves, and other entities) operate CT logs, providing redundancy and reducing the risk of any single log operator being able to suppress or manipulate entries unilaterally.

SCT (Signed Certificate Timestamp): when a CA submits a certificate to a CT log, the log returns an SCT — a cryptographic proof that this certificate has been logged. Browsers, as part of validating a certificate during a TLS handshake, check for the presence of valid SCTs (which can be delivered via several mechanisms — embedded in the certificate itself, via a TLS extension, or via OCSP stapling) as part of determining whether to trust the certificate at all.

The enforcement mechanism: major browsers (Chrome, since 2018, being the most prominent enforcer) will not trust a publicly-issued certificate that lacks valid CT log inclusion — meaning, in practice, CAs must log all issued certificates (or browsers will reject them), making CT logs a genuinely comprehensive record of essentially all publicly-trusted certificates issued since this enforcement began.

What CT logs reveal: a complete certificate history for any domain

Because CT logs are public and queryable, anyone can search for all logged certificates for a given domain — including:

Subdomains you didn't know had certificates: if a certificate was issued for internal-staging.example.com or old-project.example.com — subdomains that might not be actively advertised or linked anywhere, but for which someone (possibly a former employee, a forgotten project, or in concerning cases, an attacker who gained enough access to request a certificate for a subdomain) obtained a certificate — that issuance is recorded in CT logs and discoverable.

Wildcard certificates and their scope: a wildcard certificate (*.example.com) covers all direct subdomains — CT logs show when such certificates were issued, which can be relevant for understanding the scope of what's been certified for a domain.

Certificate issuance patterns over time: the history of certificate issuance for a domain — which CAs have issued certificates, how frequently, for which specific names — is visible, which can be useful for security audits (e.g., "has anyone other than our known CA/process ever issued a certificate for any of our domains?").

Using CT logs for security monitoring

CT log monitoring services allow domain owners to receive alerts when new certificates are logged for their domains (or subdomains) — providing an early-warning mechanism: if a certificate is issued for secure-login.yourcompany.com (a subdomain that doesn't correspond to any service your organisation actually operates), and you receive an alert about this newly logged certificate, this could indicate:

• A legitimate but unannounced internal project (a false alarm from a security perspective, but useful to be aware of for asset-tracking purposes)
• A subdomain that was set up as part of a phishing campaign impersonating your organisation, where the attacker has registered a subdomain (if your DNS allows arbitrary subdomain creation in ways that aren't tightly controlled) and obtained a certificate for it
• In more concerning scenarios, evidence of a compromise that has resulted in unauthorized certificate issuance for your actual domain

This is one of the more directly actionable uses of CT for typical domain owners — even without deep technical engagement with the Merkle tree cryptography underlying CT, simply monitoring CT logs for your domains and being alerted to new issuances provides a practical security signal.

CAA records: a complementary mechanism

CAA (Certification Authority Authorization) DNS records allow a domain owner to specify which CAs are permitted to issue certificates for their domain — a CA is expected to check for CAA records before issuing a certificate, and not issue if a CAA record specifies different (or no) CAs as authorized.

example.com.  CAA  0  issue  "letsencrypt.org"
example.com.  CAA  0  issuewild  ";"

The above example: only Let's Encrypt is authorized to issue certificates for example.com, and no CA is authorized to issue wildcard certificates (issuewild ";" — the semicolon indicating "no CA is authorized" for this specific issuance type).

How CAA and CT relate: CAA is a preventive mechanism (instructing compliant CAs not to issue in violation of the policy) — while CT is a detective mechanism (recording what was issued, regardless of whether it should have been, allowing after-the-fact discovery). A CA that properly checks CAA records and a domain that has appropriately restrictive CAA records reduces the likelihood of unauthorized issuance — while CT monitoring provides a backstop for detecting it if it occurs anyway (whether due to a CA not properly checking CAA, a CAA misconfiguration, or other failure modes).

How to use the SSL Checker on sadiqbd.com

1. Check a certificate's basic validity and chain (the core function covered in previous articles) — verifying the certificate currently in use is valid, correctly chained, and not expired
2. For comprehensive certificate history, dedicated CT log search tools (separate from a standard SSL checker, which typically examines the currently presented certificate for a live connection) provide the historical view across all logged certificates for a domain — worth using as a complementary check, particularly for security audits or when investigating "has anything unexpected been issued for our domain"
3. Verify CAA records as part of a broader certificate security review — confirming that only the CAs your organisation actually uses are authorized, reducing the attack surface for unauthorized issuance

Frequently Asked Questions

If I find a certificate in CT logs for a subdomain I don't recognize, what should I do? First, investigate internally — check with relevant teams whether this corresponds to a legitimate but perhaps undocumented service (a common "false alarm" outcome, particularly in larger organisations where not everyone is aware of every subdomain in use). If it can't be accounted for internally and the subdomain doesn't correspond to anything your organisation operates, this warrants further investigation — including checking your DNS configuration for that subdomain (does it point anywhere, and if so, where), and considering whether this could represent unauthorized access to either your DNS or your CA account, depending on what's discoverable.

Does CT logging mean certificate details (including the domains they cover) are public, even for "private" or internal services? Yes — this is an important consideration: if you obtain a publicly-trusted certificate (from a CA that browsers trust by default) for an internal service (e.g., internal-admin.example.com), the existence of that certificate — and the domain name it covers — becomes publicly visible via CT logs, even if the service itself isn't publicly accessible (e.g., it's only reachable from an internal network). For genuinely internal services where even the hostname should remain non-public, using an internal/private CA (not subject to CT requirements, since CT enforcement applies to publicly trusted certificates) rather than a publicly-trusted CA avoids this exposure — at the cost of needing to distribute that private CA's root certificate to internal systems that need to trust it, rather than relying on the public trust store.

Is the SSL Checker free? Yes — completely free, no sign-up required.

Try the SSL Checker free at sadiqbd.com — verify certificate validity, chain, and expiry for any domain instantly.