Certificate Transparency Checker

Introduction

Certificate Transparency, usually shortened to CT, is the public logging system that makes publicly trusted TLS certificate issuance visible after the fact. That matters when a renewal looks suspicious, a hostname starts serving an unexpected certificate, or a domain owner needs to know whether a certificate was issued at all instead of relying on a private ticket trail.

CT helps with detection, not prevention. Public logs make it easier for domain owners, monitors, and browser vendors to spot misissuance and challenge it, but the logs do not decide whether a certificate should have been issued in the first place. They create an audit trail that can be searched and investigated later.

A CT match answers one narrow question well: has this exact certificate or a closely related issuance become visible in public log-backed data? It does not tell you whether the certificate is the one a live host is serving right now, whether every edge node is consistent, or whether the hostname you care about is covered the way you expect.

Name coverage has its own traps. Modern certificates usually declare host coverage in the subject alternative name extension, and wildcard certificates only cover one label on the left-most side. A certificate for *.example.com can cover api.example.com, but it does not cover v2.api.example.com.

Revocation is another separate question. A certificate can stay visible in CT after revocation because transparency keeps issuance history instead of erasing it. That is useful for investigations, but it means visibility, hostname coverage, and current trust state must be read as different signals.

Technical Details:

Certificate transparency logs are append-only records of certificates and precertificates submitted by certificate authorities and related systems. Their security value comes from public auditability. If an unexpected certificate appears, domain owners and monitors can notice it, challenge the issuer, and push for revocation or other remediation. The logs themselves do not decide whether issuance was correct.

Several hashes in a CT workflow look similar but answer different questions. A certificate fingerprint identifies the exact DER-encoded certificate or precertificate bytes. A TBSCertificate hash identifies the signed certificate body that underlies an issuance. A Subject Public Key Info hash identifies the public key material, which is why it is useful for key reuse and pinning checks even when certificates are reissued.

Those identifiers are closely related, but they are not interchangeable.

Name comparison is governed by certificate identity rules rather than by CT alone. Subject alternative names carry the main DNS identities for a certificate. Current TLS identity guidance says DNS host checks should use dNSName entries, compare labels case-insensitively, and treat a wildcard as valid only when it is the complete left-most label and only when it matches one label in the reference name.

Revocation data also needs care. Reason codes come from the X.509 revocation profile, but the presence of a revoked row is more important than the elegance of the reason text because certificate authorities do not always choose perfectly descriptive labels. Validity timestamps help place an issuance in time, but they are not exact deployment timestamps.

Everyday Use & Decision Guide:

Start with the leaf certificate you actually care about. The page accepts pasted PEM text, a base64 DER block, or a dropped certificate file, but if you paste a chain it uses only the first certificate block. For a routine CT check that is usually what you want, because the question is whether one end-entity certificate is publicly visible, not whether the intermediate CA exists.

CT Brief is the fastest triage view. It shows whether a public match was found for the exact fingerprint, how many issuance hashes came back, how many issuer identities appear in the returned set, whether any row is marked revoked, and whether the local name set lines up with the public name set. If you are investigating one host, fill in Reference hostname before you run the lookup so the summary can tell you whether the host is covered exactly, by wildcard, or not at all.

• Issuance Ledger is the evidence view for row-level timestamps, issuer identities, DNS coverage previews, and CSV or DOCX export.
• Coverage & Response is the comparison view for local SAN entries, CT-returned DNS names, issuer rollup, reporting paths, and CAA authorization hints.
• JSON is the handoff view when you need the normalized record for an incident note, later diff, or automation step.

The most common misread is to treat Logged as proof that a live host is healthy. It only proves that the pasted certificate fingerprint appears in public CT-backed data. If you get No public match, do not assume the public WebPKI is wrong first. You may have pasted an intermediate certificate, a private-only certificate, the wrong PEM block, or a certificate that has not yet surfaced through the upstream search path.

Pause and verify when the summary shows Revoked row present or when the local and logged name sets differ. In those cases, copy the SHA-256 fingerprint, use the built-in crt.sh lookup, and compare the returned rows against the certificate currently deployed on the host instead of trusting the summary badge alone.

Step-by-Step Guide:

1. Paste one leaf certificate in PEM form or drop a .pem, .crt, .cer, or .der file.
2. If you are checking one host, fill in Reference hostname before running the lookup.
3. Switch Time display to UTC when you need timestamps that line up with CA notes or incident records.
4. Click Check CT logs and wait for the lookup to finish.
5. Read the headline status, recommendation banner, and posture rows in CT Brief.
6. Use Copy SHA-256, Copy SPKI pin, or Open crt.sh when you want an independent cross-check.
7. Open Issuance Ledger for row-level evidence and export CSV or DOCX if the result needs to move into a ticket or incident note.
8. Open Coverage & Response to compare local names with CT names and review issuer reporting paths or CAA hints.
9. Use JSON when you need the normalized result for handoff, later comparison, or automation.

Interpreting Results:

Match found means the exact certificate fingerprint appears in the returned CT search results. That is strong evidence that the certificate or its corresponding precertificate became publicly visible. It does not prove that every endpoint for a hostname is serving that certificate now, and it does not by itself prove that the hostname you meant to investigate is still covered the way you expect.

Name comparison deserves close reading. A local exact match and a CT wildcard match can still be normal because a wildcard entry can legitimately cover one subdomain level. A No match outcome in either column is more serious because it suggests the pasted certificate and the hostname under investigation may not describe the same deployment.

The validity window is also easy to overread. Not before and not after show the certificate's stated lifetime, not the moment it first reached production traffic. Certificate authorities can predate or postdate certificates slightly, so those fields are best used as issuance evidence and expiry context rather than exact deployment timestamps.

If the summary shows several issuance hashes or several issuers, stop reading the page as if it were a one-row yes-or-no lookup. Open the ledger and inspect which rows differ by issuer, validity window, DNS names, or revocation state before you decide whether the result is routine, suspicious, or simply broader than expected.

Worked Examples:

Routine renewal confirmation

A team receives a replacement leaf certificate ahead of a scheduled renewal. Pasting that certificate and setting the production hostname as the reference name returns Match found, no revoked rows, and the same hostname coverage locally and in CT. That is the pattern you want when the question is simply whether the new certificate has become publicly visible before the change record is closed.

Wrong PEM block in the incident ticket

An incident note includes a pasted PEM chain, but the first block is actually an intermediate CA certificate. The lookup shows No public match for the expected hostname, and the local identity details do not resemble the service certificate the team expected. The corrective path is not to distrust CT first. It is to repaste the real end-entity certificate from the host or issuance bundle and rerun the check.

Hostname drift after a rushed deployment

A platform team expects the certificate for shop.example.com to cover only the retail hostname. The CT result comes back with a broader or different DNS set than the local parse, and the reference-host badge no longer agrees between local and logged coverage. That points to certificate mix-up or unintended reuse, so the next step is to compare the live host fingerprint with the pasted certificate and audit which certificate actually reached the edge.

Revoked but still historically visible

A suspicious certificate appears in an inventory export. The lookup returns a public match, but one row is marked revoked with a recorded reason and revocation time. That does not erase the historical CT trail. Instead, it tells the reviewer to preserve the ledger, note the revocation timing, and use the issuer reporting path if the certificate still looks unfamiliar or unauthorized.

FAQ:

Glossary:

Certificate Transparency

The public logging system used to make certificate issuance observable and auditable.

Precertificate

A certificate-like object submitted to CT before the final certificate is issued.

Subject Alternative Name

The extension that carries DNS names, IP addresses, and other identities for which a certificate is valid.

TBSCertificate hash

A SHA-256 hash of the signed certificate body used to track issuance-level history.

SPKI pin

A base64 form of the SHA-256 hash of the certificate's Subject Public Key Info.

CAA domain

A domain that can appear in a CAA record to authorize a certificate issuer.

References:

• RFC 9162: Certificate Transparency Version 2.0, IETF, December 2021.
• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF, May 2008.
• RFC 9525: Service Identity in TLS, IETF, November 2023.
• SSLMate CT Search API v1 Reference, SSLMate.