Certificate Transparency Checker

Check status

Certificate:

Paste PEM/base64 DER or drop a .pem, .crt, .cer, or .der certificate file.

Reference hostname:

Optional hostname such as www.example.com; blank skips the coverage badge comparison.

Time display:

Choose Local browser time for screenshots or UTC for CA tickets and incident notes.

Coverage list limit:

Accepted range: 5-30 names shown in local and logged coverage lists.

names

Section	Signal	Value / detail
Local certificate identity	{{ row.label }}	{{ row.value }}
CT posture	{{ row.label }}	{{ row.value }}{{ row.detail }}
External lookup	crt.sh fingerprint search	{{ crtShUrl }}
Action note	Note {{ index + 1 }}	{{ note }}

CT ID	Validity window	Issuer	DNS coverage	Revocation	Copy
{{ row.id \|\| 'No ID' }} TBS {{ shortHash(row.tbs_sha256, 14) }}	{{ formatDate(row.not_before) }} to {{ formatDate(row.not_after) }}	{{ row.issuer_friendly \|\| row.issuer_name \|\| 'Unknown issuer' }} {{ row.pubkey_label }}	{{ row.dns_names.length }} name{{ row.dns_names.length === 1 ? '' : 's' }} {{ row.dns_preview }}	{{ row.revoked ? 'Revoked' : 'Clear' }} {{ row.revocation_summary }}
No issuance rows returned The public CT lookup did not return rows for this exact certificate fingerprint.

Area	Signal	Status	Detail	Copy
{{ row.area }}	{{ row.signal }}	{{ row.status }}	{{ row.detail }}

Area	Issuer / signal	Status	Detail	Copy
{{ row.area }}	{{ row.signal }}	{{ row.status }}	{{ row.detail }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A TLS certificate can look normal in a browser while its issuance history still needs review. Certificate Transparency (CT) records publicly trusted TLS certificates and precertificates in public append-only logs so domain owners, certificate authorities, browser vendors, and monitors can notice unexpected issuance and preserve evidence for investigation.

CT is evidence about issuance, not a complete verdict on authorization or deployment. A public log row does not prove that a certificate was requested by the right team, that the private key is safe, or that the certificate is currently served by the host. A missing row does not automatically prove a logging failure either. The pasted object may be an intermediate certificate, an internal PKI certificate, an old leaf, or a certificate outside the returned public data.

Certificate transparency review flow from leaf certificate bytes to fingerprint, public CT rows, hostname coverage, issuer details, and revocation clues.

The most reliable CT review starts with the leaf certificate. The leaf is the certificate presented for the service name, not the intermediate or root certificate in the chain. Its Distinguished Encoding Rules (DER) bytes produce the SHA-256 fingerprint that anchors an exact public lookup. Subject text, serial-looking values, issuer names, and hostname lists are useful clues, but they are not as precise as the fingerprint of the certificate object itself.

Certificate transparency review questions and evidence types
Review question	Best evidence	What can mislead you
Is this exact certificate visible?	SHA-256 fingerprint of the DER leaf certificate.	Comparing only subject, issuer, or serial text.
Which names are covered?	Subject Alternative Name (SAN) DNS entries and CT-reported DNS names.	Assuming a wildcard covers deeper subdomains.
Was a returned row revoked?	Revocation state, reason, and time when the public source returns them.	Expecting revocation to remove the certificate from CT history.
Who should investigate?	Issuer identity, Certificate Authority Authorization (CAA) hints, and reporting instructions.	Treating a friendly issuer label as a permanent compliance identifier.

Hostname coverage needs careful reading. *.example.com can cover api.example.com, but it does not cover v2.api.example.com. CT data can also return related issuance rows, reissues, precertificates, public-key reuse clues, and rows with different issuer detail. A strong review compares fingerprint, SAN coverage, issuer evidence, validity dates, and revocation clues before deciding whether the result is routine renewal evidence or something to escalate.

The practical value is evidence discipline. For a normal renewal, CT visibility supports the handoff by showing that the certificate appears in public issuance data. During an incident, it preserves the certificate identity, names, issuer, public key, revocation posture, and reporting clues before teams compare the live host or contact the certificate authority.

How to Use This Tool:

Start with the leaf certificate you want to investigate. If the pasted text contains several PEM blocks, the first certificate block is used as the lookup target.

Paste PEM text, paste base64 DER text, drop a certificate file, or use Browse file in Certificate. The status line should report detected characters and whether the text looks like PEM or base64 DER.
Enter Reference hostname when one host is under review. Leave it blank if you only need fingerprint, issuer, revocation, and CT visibility evidence without a hostname coverage badge.
Choose Time display. Use UTC for tickets, cross-team notes, and incident records; use Local browser time when everyone reading the output uses the same timezone.
Set Coverage list limit for certificates with many names. The visible range is 5 to 30 names, while structured output keeps the returned data available for handoff.
Click Check CT logs. If the alert says the certificate could not be decoded, replace the input with a PEM certificate block or base64 DER for the leaf certificate.
A lookup timeout means the public CT source did not respond within 12 seconds. Rerun the check or compare the fingerprint in another CT search before treating the empty result as final.
Read CT Brief first. It summarizes local certificate identity, Public CT status, issuer spread, logged DNS names, validity span, revocation posture, and action notes.
Use Issuance Ledger, Issuer Entry Mix, Hostname Coverage, Issuer Response, and JSON when you need row-level evidence, issuer counts, hostname comparison, reporting clues, or a structured incident record.

Interpreting Results:

Read the status as CT evidence. Match found means returned public data included rows for the exact certificate fingerprint. No match means no returned row matched that fingerprint through the public lookup used for the run.

Certificate transparency interpretation patterns
Observed output	What it supports	What to verify next
`Public CT status` shows `Match found`	The exact certificate fingerprint appears in returned public CT data.	Run a live TLS or certificate-chain check if deployment state matters.
`Public CT status` shows `No match`	No matching row came back for that fingerprint.	Confirm the input is the leaf certificate, then compare against a live host or another CT search.
`Reference hostname` shows `No match`	The supplied hostname was not covered by the local names or returned CT DNS names in that comparison.	Check for a different certificate, a missing SAN, or a one-label wildcard boundary.
`Revocation posture` shows a revoked row	At least one returned row carries revocation details.	Read the reason and time before deciding whether issuer reporting is needed.
`Issuer spread` is greater than 1	Returned rows name more than one issuer identity.	Use `Issuance Ledger` to compare issuer, validity window, and public-key evidence row by row.

A CT match can still hide a deployment problem, and a missing match can come from the wrong input. Keep the SHA-256 value as the identity anchor, then compare live-host fingerprints, SAN coverage, issuer details, and revocation values before escalation.

Technical Details:

CT evidence is byte-oriented. Two certificates can share a subject, issuer name, hostname set, or public key while still being different certificate objects. The DER-encoded leaf certificate is hashed to create the SHA-256 fingerprint used for exact public lookup and for comparison against live-host fingerprints.

Public CT rows are append-only evidence of issuance or observation. They can contain certificates and precertificates, issuer details, validity dates, DNS names, public-key hashes, revocation information, CAA hints, and reporting instructions when the data source returns them. The presence of a row does not settle whether the certificate was authorized or currently deployed.

Lookup Core:

Certificate SHA-256 = SHA-256 (DER certificate bytes)

PEM armor is removed before decoding, and base64 DER text is decoded into the same certificate bytes. Whitespace around the PEM body does not change the DER value, but any changed DER byte produces a different fingerprint. After hashing, the lookup asks the Cert Spotter public issuances data for rows tied to that fingerprint and expanded evidence fields.

Certificate transparency evidence fields and review use
Evidence	Meaning	Review use
`SHA-256`	Digest of the exact certificate bytes.	Compare the pasted certificate against CT rows, live hosts, and inventory records.
`TBS SHA-256`	Digest of the signed certificate body reported with an issuance row.	Separate related issuance records when rows are similar but not identical.
`SPKI SHA-256` and `SPKI pin`	Hashes of the Subject Public Key Info value.	Spot key reuse across reissues or parallel certificates.
`Logged DNS names`	DNS names returned with the CT rows.	Compare against local SAN entries and the reference hostname.
`CAA hints`	Issuer-related domain clues returned by the public source.	Use them as investigation clues, not as a full CAA policy audit.
`Problem reporting`	Issuer-specific reporting instructions when available.	Preserve the row before contacting the issuer about unexpected issuance.

Hostname Matching Rules:

Reference host comparison is case-insensitive and trims trailing dots. DNS names from the local certificate and CT rows are normalized before comparison, then the reference hostname is classified as an exact match, wildcard match, or no match.

Hostname matching examples for certificate transparency review
Pattern	Reference host	Result	Reason
`api.example.com`	`api.example.com`	`Exact`	The normalized names are identical.
`*.example.com`	`api.example.com`	`Wildcard`	The wildcard is the complete left-most label and matches one label.
`*.example.com`	`v2.api.example.com`	`No match`	The reference host has two labels before `example.com`.

The Time display setting changes only how timestamps are rendered. Returned not before, not after, revocation, and revocation-check timestamps remain source timestamps. Treat not before as a validity value rather than a perfect issuance time because certificate authorities can predate or postdate certificates.

Issuer Entry Mix groups top issuers by clear and revoked CT entry counts and includes unique DNS-name counts for context. A large bar is not risk by itself; it means the returned rows deserve issuer and row-level review before deciding whether the set is normal renewal noise, key reuse, or unexpected issuance.

Privacy and Accuracy Notes:

The certificate text is decoded and fingerprinted in the browser. The full PEM or DER content is not posted to the public CT data source, but the computed SHA-256 fingerprint is sent for lookup. The reference hostname is used for local comparison against local and returned names.

Use care with private PKI certificates. Even when no public row exists, the fingerprint lookup still contacts a public CT source.
A 12-second timeout, source availability, or public data coverage can produce a lookup failure or empty result that needs a second check.
Revocation details, issuer friendly names, CAA hints, and reporting instructions depend on what the public source returns for the fingerprint.

Advanced Tips:

Use a leaf certificate captured from the service or issuance file. A pasted intermediate certificate can decode successfully while producing the wrong CT question.
Use UTC for incident notes so revocation and validity timestamps compare cleanly across teams.
Enter Reference hostname when a single service name matters. The badge separates local SAN coverage from CT-reported DNS coverage.
Compare the SHA-256 value with a live TLS check before concluding that a logged certificate is currently deployed.
Use Issuer Response only after reviewing the ledger row. Reporting instructions make sense only when the fingerprint, names, and issuer evidence still look suspicious.
Increase Coverage list limit for certificates with many SANs so visible hostname rows match the investigation scope.

Worked Examples:

Pre-deployment renewal check

A team receives a new PEM leaf certificate for api.example.com. After pasting the leaf and entering that reference hostname, Public CT status shows Match found, Logged DNS names includes the host, Revocation posture shows no revoked rows, and Reference hostname reports matching local and CT coverage. That is useful CT evidence for the handoff, while a live TLS check still confirms deployment.

Intermediate pasted by mistake

An incident note contains a PEM chain where the first block is an intermediate CA certificate. The lookup returns No match, and local identity fields do not resemble the service certificate. Replace the input with the actual leaf certificate from the host or issuance file, then rerun the check.

Wildcard boundary surprise

A certificate with *.example.com is checked against v2.api.example.com. Hostname Coverage reports no reference match because the wildcard covers only one left-most label. If the service needs that deeper name, look for a certificate that includes v2.api.example.com directly or uses another valid name pattern.

Unexpected revoked row

A security team investigates a certificate that should never have been issued. The CT result is logged, Revocation posture shows a revoked row, and Issuer Response includes reporting instructions. Preserve the Issuance Ledger, compare the live host fingerprint, and use the issuer reporting path if the certificate still looks unauthorized.

FAQ:

Does the lookup send my whole certificate to the CT data source?

No. The browser computes the certificate SHA-256 fingerprint first. The external lookup uses that fingerprint and requests returned CT evidence fields rather than posting the full PEM text.

Why does certificate decoding fail?

The Certificate field must contain a PEM certificate block or base64 DER certificate. A CSR, private key, broken copy, or unsupported binary paste will trigger the decode error.

Why can a working HTTPS site show no CT match?

The pasted certificate may not be the live leaf certificate, or the certificate may be private-only, old, an intermediate, or absent from the returned public CT data. Compare the live host fingerprint before treating the result as a logging problem.

Does a CT match prove the certificate is currently deployed?

No. CT records issuance history. Use the SHA-256 value from CT Brief and compare it with a live TLS check when current deployment matters.

Why do local names and logged DNS names differ?

CT rows can contain related issuance data, and local parsing may expose SAN entries differently from returned DNS names. Use Hostname Coverage and Issuance Ledger to compare the exact certificate row before deciding which set is more useful.

What should I do with issuer reporting instructions?

Treat them as a starting point for suspicious or unauthorized issuance. Preserve the ledger row, verify the live host and fingerprint, then contact the issuer through the returned reporting path if the certificate still looks wrong.

Glossary:

Certificate Transparency: The public logging system that makes publicly trusted TLS certificate issuance observable and auditable.
Leaf certificate: The certificate presented for the service name, as distinct from intermediate or root CA certificates in the chain.
Precertificate: A certificate-like object submitted to CT before final certificate issuance.
Subject Alternative Name: The X.509 extension that carries DNS names, IP addresses, and related service identities.
SHA-256 fingerprint: A digest of the exact DER certificate bytes used to identify the certificate object.
SPKI pin: A base64 SHA-256 digest of the certificate public-key information.
CAA hint: An issuer-related domain clue that can help compare returned issuer data against domain authorization policy.
Revocation reason: A code or label explaining why a certificate was revoked when that information is available.

References:

RFC 9162: Certificate Transparency Version 2.0, IETF, December 2021.
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile, IETF, May 2008.
RFC 9525: Service Identity in TLS, IETF, November 2023.
Cert Spotter API v1 Reference, SSLMate.
How to debug TLS handshake with cURL, Simplified Guide.