| ID | notBefore | notAfter | Revoked | Issuer | DNS names | Copy |
|---|---|---|---|---|---|---|
| {{ row.id }} | {{ row.not_before_local }} | {{ row.not_after_local }} | {{ row.revoked ? 'Yes' : 'No' }} | {{ row.issuer_friendly || row.issuer_name }} | {{ row.dns_names.join(', ') }} — | |
| No CT entries returned for this certificate fingerprint. | ||||||
Certificate Transparency, or CT, is a public logging system for TLS certificates. Its practical job is visibility: once a certificate is logged, outside parties can search for it, monitor issuance, and investigate certificates that should not exist. This checker takes a certificate, fingerprints it locally, and asks whether matching CT entries appear through the upstream search service.
The workflow is intentionally narrow and concrete. You paste a PEM certificate or a base64 DER certificate, the browser recovers the certificate bytes, computes a SHA-256 fingerprint, and then queries the Cert Spotter issuances API by that fingerprint. The result is summarized as found or not found, with entry counts, validity dates, revocation flags, issuer rollups, DNS-name coverage, and a JSON bundle you can export.
That makes the tool useful when the question is “does this exact certificate appear in CT, and what does the returned footprint look like?” rather than full certificate validation. A security analyst may want to confirm whether an unexpected certificate is visible in transparency logs. An operations engineer may want to copy the SHA-256 fingerprint and compare it against another inventory system before deciding whether both tools are talking about the same certificate bytes.
The package also smooths out messy certificate input. If you paste a PEM block, it extracts and normalizes the certificate body. If you upload or paste a DER-style Base64 blob, it normalizes the alphabet and padding before decoding the bytes. That means the lookup is centered on one recovered byte sequence rather than on the wrapper format the certificate happened to arrive in.
The important limit is scope. A CT hit does not prove the certificate is currently deployed, trustworthy, or correctly configured on a host. A CT miss does not automatically make the certificate suspicious. The package checks CT visibility for one certificate fingerprint and summarizes what the upstream service returned. It does not replace hostname validation, chain analysis, or broader certificate monitoring.
The cleanest input is the certificate itself, not a domain name. If you already have the PEM block, paste it directly. If you have a certificate file, upload it so the package can decide whether it is readable PEM text or binary DER. That avoids the common mistake of copying an incomplete certificate body or hashing the wrong wrapper.
Read the summary strip before diving into the table. The result label tells you whether any entries were returned. Entry count tells you how many. The first and last validity dates show the visible time span across the returned entries. The revoked badge is a warning signal, not a full revocation workflow. If the summary already answers the operational question, the deeper tabs are mostly for attribution, footprint review, and export.
Use CT Log Entries when you care about the returned records individually. The table is best for checking CT IDs, validity windows, revocation flags, issuer names, and DNS names row by row. Use Certificate Footprint when you care more about the overall pattern, such as which issuers dominate the result or which DNS names recur across the entry set. Use JSON when you want the whole result preserved in a structured export.
The SHA-256 copy button is there for cross-system comparison. If another inventory system indexes certificates by fingerprint, copying the value from this checker lets you verify that both tools are referring to the same exact bytes before you compare their findings. That matters because the same certificate can appear in several text wrappers while still representing only one underlying fingerprint.
Treat the CT answer as one piece of evidence. If the result surprises you, confirm that the pasted certificate is the right one first. Then compare the fingerprint and the exported rows elsewhere. CT visibility can support an investigation, but it should not be mistaken for a complete trust decision.
The lookup begins with certificate bytes. PEM input is detected by searching for a BEGIN CERTIFICATE block and stripping whitespace from the body. Non-PEM input is treated as Base64: whitespace is removed, URL-safe characters are normalized back to the standard alphabet, missing padding is restored, and the value is decoded into bytes. If neither path yields bytes, the check stops with an input error instead of sending a malformed lookup upstream.
Once the byte array exists, the browser computes a SHA-256 digest. The package prefers crypto.subtle.digest and falls back to a Forge SHA-256 implementation if needed. That digest becomes the lookup key passed to the Cert Spotter issuances endpoint as cert_sha256. The request also asks for expanded DNS names and issuer details and enforces a 12-second timeout so network stalls surface clearly.
The upstream response is normalized into local rows containing CT log ID, the returned SHA-256 fields, validity times, localized date strings, revocation state, issuer names, and DNS-name arrays. The summary view is then derived from those rows: entry count from the total row set, earliest and latest dates from the validity fields, and the revoked badge from any returned row carrying a revoked flag.
The footprint tab is built from the same entries array. Issuer Rollup groups rows by friendly issuer name, counts occurrences, and records the earliest and latest returned validity dates for each issuer. DNS Name Reach lowercases and counts every DNS name across the result set, then shows the most frequent names. That view is useful when the issue is not one row but the overall certificate footprint represented by the returned entries.
The export paths mirror those result surfaces. The entries table exports CSV and DOCX, row copy is available for individual results, the SHA-256 fingerprint can be copied on its own, and the JSON export preserves the summary, issuer rollup, DNS coverage, and the raw upstream payload together. The package therefore supports both quick lookups and documented follow-up.
| Stage | Package behavior | Why it matters |
|---|---|---|
| Input recovery | Accepts PEM or base64 DER and recovers certificate bytes | Keeps the lookup stable across common wrapper formats |
| Fingerprinting | Computes SHA-256 locally in the browser | Lets you compare the exact same certificate across systems |
| CT query | Calls the Cert Spotter issuances API by cert_sha256 with issuer and DNS expansions |
Retrieves CT entries tied to that fingerprint |
| Normalization | Maps returned fields into entries, issuer rollups, and DNS coverage rows | Makes the result easier to review and export |
| Export | Provides CSV, DOCX, JSON, row copy, and fingerprint copy | Supports handoff into inventory, review, or incident workflows |
| Surface | What it shows | Best use |
|---|---|---|
| CT Log Entries | Individual returned rows with dates, revocation state, issuer, and DNS names | Reviewing or exporting the exact matched entries |
| Certificate Footprint | Issuer rollup and DNS-name frequency coverage | Understanding the overall result pattern |
| JSON | Summary, rollups, DNS coverage, and raw upstream result | Archiving or passing the lookup into another workflow |
| SHA-256 copy | The certificate fingerprint used for the lookup | Cross-checking against other inventory or CT tools |
Found means the upstream service returned at least one issuance record for the locally computed certificate fingerprint. It does not mean the certificate is currently deployed, safe to trust, or valid for a particular hostname. Not found means no entries were returned for that fingerprint through this lookup path at that time.
The footprint views answer different questions from the summary label. Issuer Rollup shows how many returned entries are associated with each issuer and over what date span. DNS Name Reach shows which names recur most often across the result set. Those views are useful when you need context around the returned entries instead of just a yes-or-no CT answer.
The revoked badge deserves care. It reflects the returned CT rows, not a complete revocation workflow. Use it as a warning signal, not as a substitute for dedicated revocation checks or broader certificate validation.
An operations engineer pastes a fresh PEM certificate from an issuance workflow and runs the lookup. The result comes back Found with expected DNS names and recent validity dates. That does not prove deployment, but it does confirm that the certificate fingerprint is visible through this CT search path.
A team only has a DER file exported from a device. They upload it, copy the SHA-256 fingerprint, and compare that value against another inventory tool. Even though the source was not PEM text, both systems can now refer to the same exact certificate bytes.
A security analyst sees several returned entries and wants to understand the set quickly. They switch to Certificate Footprint, review the issuer rollup, and check the DNS-name coverage list before deciding whether deeper investigation is needed.
The package computes the SHA-256 fingerprint locally first and then queries the upstream API by that fingerprint. The certificate text still exists in the browser session while you are using the page, so treat it as sensitive.
The pasted certificate may be wrong, incomplete, or encoded unexpectedly, or the upstream CT search may not return a record for that fingerprint at the moment you query it.
No. It checks CT visibility for one certificate fingerprint and summarizes the returned CT result set.
It lets you compare the exact certificate fingerprint against other inventories, monitors, or CT search tools.