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.

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.

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.⁷

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. CapyToolkit shows all parsed extensions for every certificate in the chain, so you can check for SCT data whenever its presence or absence is relevant to your security audit.