X.509 Certificate Inspector

What it parses

The inspector accepts PEM certificates (the text format with -----BEGIN CERTIFICATE----- headers), binary DER files, and raw Base64-encoded DER without PEM headers.¹ Format detection is per line, so a paste that mixes several PEM blocks with different wrapping is handled gracefully, and DER input is recognised whether or not a PEM header is present. Paste a single certificate or a full chain of multiple PEM blocks and each certificate renders as a separate card ordered leaf-first, letting you inspect a complete trust path in a single view.

For each certificate, the inspector shows the subject and issuer distinguished name fields (CN, O, OU, C, ST, L), serial number, SHA-256 fingerprint, validity dates with an expiry countdown, public key algorithm and size, signature algorithm, Subject Alternative Names, Key Usage flags, Extended Key Usage OIDs, and Basic Constraints.² You can also fetch a live certificate by typing a domain name into the domain field; when the certificate-fetch service is configured, the browser sends only the hostname to that service and renders the returned PEM chain, so no local file is needed to begin an inspection.

A concrete example ties the badges to real fields. Let's Encrypt publishes its ISRG Root X1 certificate openly: subject and issuer both read CN = ISRG Root X1, O = Internet Security Research Group, confirming it as self-signed, its public key is 4096-bit RSA, well above the 2048-bit weak-key threshold, and its validity window runs from June 2015 to June 2035, a 20-year span typical of a root rather than a short-lived leaf certificate. Pasting that PEM into the inspector renders exactly those fields on a single expanded ROOT CERTIFICATE card, with no WEAK KEY or SHA-1 SIGNATURE badge attached, since the key size clears 2048 bits and the signature uses SHA-256.

Why the fingerprint earns its row

The SHA-256 fingerprint row is a digest computed over the certificate's exact DER encoding, which makes it an identity for the certificate itself rather than for the file that carried it. Paste the same certificate twice and the row does not move. Because PEM is only a text wrapper around the same DER bytes, a file saved with -----BEGIN CERTIFICATE----- headers and the same certificate loaded as a raw binary DER file produce the identical digest, so the row answers the same question in every format the input accepts: are these the same bytes?

The digest earns its row in three everyday situations. When you re-download a chain from a vendor portal or re-export it from a server, comparing the fingerprint against your earlier capture confirms the bytes still encode the same certificate before you deploy them. When a CA operates several intermediates with near-identical names, the readable CN rows collide while the digest never does, so the fingerprint pins down exactly which intermediate you hold. And when a renewal lands, a fresh certificate always carries a fresh fingerprint. An unchanged fingerprint after a supposed renewal means the bytes never changed, so the swap you were promised has not happened yet.

How to Check an SSL Certificate

Parsing a certificate tells you what it contains; checking it tells you whether a client will accept it. The guide below turns the parsed fields into seven checks to run in order, from the validity window and SAN coverage to key strength, chain completeness and security flags, explains why the certificate a server sends can differ from the file on disk, and says what to do about each warning badge.

Reading the chain

The leaf certificate is always expanded. Intermediate and root certificates are collapsed by default. Click Expand to view their fields. Between each adjacent pair of cards, a connector line shows which CA issued the certificate above it, making chain relationships visible at a glance. Reading these issuer-to-subject links is how you confirm that each certificate was actually signed by the one card above it, rather than assembled from unrelated sources.

How a well-formed chain is built

A chain is complete only when it terminates at a self-signed root certificate, which is labelled ROOT CERTIFICATE · self-signed. Path validation works by matching the issuer distinguished name of each certificate against the subject name of the next one in the sequence, walking upward until a trust anchor, typically a self-signed root already held in the browser or operating system store, is reached.³ The Basic Constraints extension can also carry a pathLenConstraint, which caps how many non-self-issued intermediate certificates are allowed below a given CA, so an unexpectedly deep chain can indicate a misconfigured issuer.

If the chain ends without a self-signed certificate, the root is absent and the last card is labelled INTERMEDIATE CERTIFICATE, signalling a partial chain.⁴ Browsers trust a chain only when they can build an unbroken path from the leaf to a root in their trusted store, so a partial chain causes TLS handshake failures even when the leaf certificate itself is valid and unexpired. Inspecting the connector line and these labels together tells you whether the server is sending the full bundle or whether an intermediate is simply missing.

Inspecting is not verifying

Inspecting a certificate and verifying it are different jobs, and the boundary matters when a decision rides on the result. The cards here report what the bytes contain: fields parsed, roles labelled, badges raised. A verifying client goes further and does three things this inspector never does. It checks each certificate's signature against the public key of the issuer above it, walks the resulting path to a root it actually holds in its own trust store, and may consult revocation status along the way.³ A chain that renders cleanly here has been parsed, not proven; the clean render tells you the structure is readable, and only a verifier's pass tells you a browser or any other client will trust it.

Revocation sits on the same boundary. Certificate authorities publish the revocation status of the certificates they issue, through signed revocation lists or an online status protocol, and a verifying client consults that status while validating a chain.² This inspector makes no such request: no revocation list is fetched and no status server is contacted, because the inspection reads only the bytes you paste or load. A chain can therefore render perfectly card by card while its leaf sits revoked in the real world, and nothing on any card would say so. When a revocation answer matters to your decision, the check belongs to the verifying client that renders the trust verdict, not to a parser that reads bytes.

Why the same chain can pass in one client and fail in another

Trust has an address. Each operating system and each browser maintains its own list of trusted roots, refreshed by its vendor as roots are added or retired, and a chain verifies on a given client only when it terminates at a root that particular list contains. The inspector labels the self-signed root it finds, but the bytes carry no map of which stores hold it, and no local parse can produce one. That is the quiet reason a complete, current, strong chain can still fail in one client and pass in another: the two clients are consulting different lists, and only one of them contains your root.

Internal certificate authorities make that consequence personal. A private root exists only where someone has installed it, so an internal chain validates on the machine where the root was added and fails on every client that never received it. From the failing client's side, a root it does not hold and an untrusted issuer are the same condition, which is why the error reads as a generic trust failure rather than a missing-root diagnosis. Distributing the internal root to every client that connects, through your management tooling for managed devices and explicit installs elsewhere, is part of deploying an internal CA, not an afterthought you can skip when the first handshake succeeds on the admin's own laptop.

Security flags

The inspector highlights several conditions that deserve attention when you are reviewing a certificate or chain, and it does so with coloured badges that let you scan a card at a glance. These flags cover expiry status, key strength, signature algorithm, and Subject Alternative Name patterns, and they appear on intermediates and roots as well as on the leaf so that a weak spot anywhere in the chain is surfaced immediately.

What each badge means

Each card shows coloured badges for conditions worth attention: EXPIRED (red) for past notAfter dates, EXPIRES IN N DAYS (orange) when fewer than 30 days remain, WEAK KEY (orange) for RSA keys under 2048 bits, SHA-1 SIGNATURE (amber) for the broken SHA-1 algorithm, and WILDCARD SAN (muted) when at least one Subject Alternative Name uses a wildcard. Flags appear on intermediates and roots as well as the leaf, so a weak intermediate key is surfaced immediately rather than hidden behind a strong leaf certificate.

NIST's comparable-strength table lists RSA 2048 at 112 bits and notes that 80-bit asymmetric keys are no longer approved, which is why the inspector flags RSA keys below 2048.⁵ NIST reported the 2017 SHA-1 collision and deprecated SHA-1 for digital signatures, which is why SHA-1-signed certificates are flagged for replacement.⁶ Wildcard SANs matter because RFC 6125 constrains wildcard DNS identifiers to complete left-most labels, so a wildcard that spans multiple labels broadens the set of hosts the certificate incorrectly authorises.⁷

What to check first when a handshake fails

When a TLS handshake fails and you have the chain in hand, work the cards in a fixed order. Start at the expiry countdown, because an expired or hours-from-expiry certificate is both the most common failure and the cheapest to confirm: one glance at the days-left row settles it. Move next to the role labels, where an INTERMEDIATE CERTIFICATE standing where the ROOT CERTIFICATE should be means the server is not sending the full bundle. Then scan for WEAK KEY and SHA-1 SIGNATURE badges, and finish with the names, checking that every hostname the deployment answers on appears in the SAN rows. Each step maps to one element on one card.

The order runs cheapest-to-confirm first, because most handshake failures are boring. Expiry beats everything else on both frequency and confirmation cost, the chain labels follow as the next structural fact, and the key and name checks close out the sequence. Walking from the clock to the chain to the key material to the names also means a hit at any step explains the failure, and the remaining steps stop mattering. The sequence still has a scope limit: it covers what pasted bytes can reveal, and a chain that clears every step can fail on the client side for reasons no paste shows.

What the names must cover

A TLS client decides whether a certificate belongs to the site you asked for by matching your requested hostname against the names in its Subject Alternative Names extension rather than by reading the Common Name.⁷ The Subject CN survives as a display field; current clients treat the SAN entries as the source of the match. Every hostname the deployment answers on must therefore appear in the SAN rows. When one is missing, the handshake stops with a name-mismatch error even though the chain is complete, the validity window is current, and every key clears its threshold, which is why a perfectly healthy-looking certificate can still be the wrong certificate.

On the leaf card, the check reads in seconds. Open the extension panel and read the SAN rows: the hostnames the client will accept are exactly the names printed there, and each row's Copy button moves a name straight into a config file when needed. A deployment serving both the bare domain and its subdomains needs both forms listed, because a wildcard SAN covers exactly one complete left-most label, the same RFC 6125 rule behind the wildcard badge. The badge tells you a wildcard exists; the name rows tell you which hostnames the certificate actually answers for, and the rows are what settle a mismatch question.

Validity windows and renewal timing

Certificates carry a fixed validity window, and planning renewal before expiry is a key operational discipline.⁸ Let's Encrypt currently issues certificates valid for 90 days and is reducing them to 45 days by 2028, a shorter window that limits exposure time if a private key is compromised.⁸ The CA/Browser Forum adopted SC-081v3 in 2025 to reduce the maximum public TLS certificate lifetime from 398 days to 47 days by March 2029, compressing automated renewal cycles further.⁹ Consequently, certificates that once needed annual renewal will require ACME clients or certificate management platforms capable of handling short-lived certs without human intervention.¹⁰ The inspector's expiry countdown tells you exactly how many days remain, letting you verify that your monitoring threshold aligns with your actual renewal schedule.

Internal certificates issued by private CAs may still carry multi-year validity periods, since they are not subject to CA/Browser Forum requirements.⁹ While longer validity is convenient for internal services, a compromised internal certificate stays valid far longer without detection. Checking the notBefore and notAfter fields in the inspector gives you the exact window for every certificate in the chain, including long-lived intermediates that can be forgotten until they expire during a production incident.

Key algorithms and their security implications

The public key algorithm and size determine how hard it is to forge a signature or derive the private key, and the choice has consequences that ripple through the entire chain. RSA 2048 remains the practical baseline for public-facing certificates, while ECDSA offers equivalent security with smaller keys and faster operations. The inspector shows the algorithm and bit length for every certificate in the chain so you can audit intermediates and roots with the same scrutiny you apply to the leaf.

How the algorithm choice affects chain trust

The public key algorithm and size determine how computationally difficult it is to forge a signature or derive the private key. RSA at 2048 bits is the practical baseline for public-facing certificates; Cloudflare requires custom certificates to use at least a 2048-bit RSA key.¹¹ ECDSA (Elliptic Curve Digital Signature Algorithm) is also used for modern certificates, with Cloudflare's CSR tooling offering p256v1 as a NIST P-256 option alongside the default RSA 2048-bit key.¹¹ New deployments can often choose ECDSA where client support and CA policy allow it, rather than defaulting to RSA above 2048 bits.

The inspector shows the key algorithm and bit length for every certificate in the chain. Auditing intermediates and roots matters as much as checking the leaf, because a weak intermediate key undermines the entire chain even when the leaf uses a strong algorithm.⁴ Building on this, post-quantum migration planning also requires knowing which algorithm each certificate uses, so you can track which certificates will need replacement as quantum-resistant algorithms are standardised and adopted by certificate authorities over the coming years.

Certificate transparency and public discoverability

Certificate Transparency (CT) is a public audit mechanism standardised in RFC 6962.¹² Every publicly trusted TLS certificate must be CT-compliant in modern Chrome, and TLS-delivered SCTs must include at least two SCTs from distinct CT log operators.¹³ SCTs can be embedded in the certificate or delivered during the TLS handshake; Chrome formerly accepted SCTs in stapled OCSP responses in older versions.¹³ CT makes it possible to discover certificates issued for your domain, including certificates you did not authorise, and a monitoring service watching CT logs can alert you if a compromised CA issues a rogue certificate before it is deployed in production.¹⁴

Internal or self-signed certificates are not submitted to CT logs and do not appear in public CT search tools.¹² Understanding this distinction matters when you inspect a chain and notice absent SCT extensions: the certificate is not automatically suspicious. It may simply be a legitimate private CA certificate not governed by browser trust requirements. The extension panel on each card has a fixed scope: it lists exactly the Subject Alternative Names, Key Usage, Extended Key Usage, and Basic Constraints groups, and SCT timestamps are not parsed into any card. The panel therefore says nothing about CT compliance either way. A public certificate's CT status is read against the logs described above, which is also where an unauthorised certificate issued for your domain surfaces.