AnyTool
Your files never leave your device. All processing happens locally in your browser.

How do I verify an X.509 certificate or certificate chain online?

Paste one PEM certificate or a full chain (leaf first, then intermediates, then the root) into the Digital Certificate Verifier. It parses each block with a hand-written DER/ASN.1 + X.509 engine and runs the checks in your browser: it flags expired or not-yet-valid certificates, labels self-signed and CA certificates, confirms the chain is in the right order (each Issuer name matching the next Subject), and cryptographically verifies each signature against the issuer’s public key with the Web Crypto API. Add a hostname and it is matched against the leaf’s Subject Alternative Names using RFC 6125 wildcard rules. You get one PASS / WARN / FAIL verdict with a per-check breakdown. Nothing is uploaded.

  • Checks validity dates (notBefore / notAfter) with a days-until-expiry count per certificate
  • Verifies each signature link against the issuer key via Web Crypto (RSASSA-PKCS1-v1_5 & ECDSA P-256/384/521)
  • Confirms chain ORDERING: each cert’s Issuer DN must equal the next cert’s Subject DN (RFC 5280)
  • Optional hostname / SAN match with correct wildcard semantics (RFC 6125)
  • Does NOT check revocation (CRL/OCSP) or your OS/browser trust store — a PASS means internally consistent & in-date

What is

Digital Certificate Verifier

A digital certificate verifier is a tool that checks an X.509 certificate, or an ordered chain of them, against the structural and cryptographic rules of RFC 5280: that each certificate is within its validity period, that the chain is ordered so every certificate’s Issuer distinguished name equals the next certificate’s Subject, and that each signature verifies against the issuer’s public key. It can also match a hostname to the leaf certificate’s Subject Alternative Names under RFC 6125. A client-side verifier performs all of this in the browser with the Web Crypto API. It verifies chain consistency and dates — it does not check revocation or a trusted root store — so a positive result means the chain is internally consistent and in-date, not that it is publicly trusted.

Security & Privacy

Related terms

X.509RFC 5280RFC 6125certificate chainchain of trustSubject Alternative Namecertificate authorityself-signedbasic constraintsECDSARSAWeb Crypto API

Frequently Asked Questions

No. The certificate is parsed and every signature is verified entirely in your browser with the Web Crypto API — nothing is uploaded.

The Digital Certificate Verifier is 100% client-side. Your PEM text is base64-decoded and walked by a local DER/ASN.1 engine written in JavaScript, and each certificate’s signature is checked against its issuer’s public key by your browser’s Web Crypto API (crypto.subtle). There is no backend, upload, database or CDN in the processing path and no analytics. This matters because certificates and chains can expose internal hostnames and infrastructure; here those details never leave your device, the tool works offline once cached, and closing the tab erases everything.

No. A PASS means the chain is internally consistent and in-date. It does not check revocation or your browser’s trusted root store.

This tool verifies structure, dates, hostname matching and the signature links between the certificates you supply. It does not check revocation via CRL or OCSP, and it does not verify the chain against your operating system or browser trust store of root CAs — both need network calls a client-side tool deliberately never makes. So a chain can PASS here and still be revoked, or rooted in a CA that no browser trusts, and a self-signed chain will PASS internal consistency while being untrusted in the real world. Use the verdict to diagnose a chain; for a real trust decision rely on a browser TLS handshake or openssl verify against a trusted CA bundle with revocation enabled.

The hostname is matched against the leaf’s Subject Alternative Names using RFC 6125 rules; a wildcard covers exactly one left-most label.

When you enter a hostname it is compared to the DNS entries in the leaf certificate’s Subject Alternative Name extension. Exact matches pass, and a wildcard such as *.example.com matches a single left-most label — so it matches api.example.com but not a.b.example.com and not the bare example.com. Partial wildcards like w*.example.com are rejected, matching modern browsers. If the leaf has no SANs at all the tool falls back to the deprecated Subject Common Name and tells you it did so. IP-address hosts are matched against IP SANs.

RSASSA-PKCS1-v1_5 (SHA-1/256/384/512) and ECDSA on P-256, P-384 and P-521. RSASSA-PSS, Ed25519, DSA and SHA-224 are shown as unsupported.

Signature linking uses the Web Crypto API, which supports RSASSA-PKCS1-v1_5 and ECDSA. For RSA the signature over the TBSCertificate is checked directly; for ECDSA the DER-encoded r/s value is converted to the raw IEEE P1363 form and verified against the issuer key’s named curve (P-256 / P-384 / P-521). Algorithms the browser cannot verify — RSASSA-PSS (which needs explicit parameters), Ed25519, Ed448, DSA and any SHA-224 variant — are still parsed and reported honestly as unsupported rather than guessed, and the affected link is marked so the overall verdict is a WARN, not a false PASS.

Detailed Explanation

How It Works

What the Digital Certificate Verifier Does

The Digital Certificate Verifier takes one PEM certificate or a whole chain (leaf, then intermediates, then the root) and runs the RFC 5280 / RFC 6125 checks entirely in the browser. For each certificate it reports whether it is within its validity window with a days-to-expiry count, whether it is self-signed and whether it asserts basicConstraints CA:TRUE. Across the chain it confirms the ordering — every certificate’s Issuer distinguished name must equal the next certificate’s Subject — and cryptographically verifies each signature against the issuer’s public key with the Web Crypto API. An optional hostname is matched against the leaf’s Subject Alternative Names. The results roll up into a single PASS / WARN / FAIL verdict with a per-check breakdown.

  • Input: one PEM certificate or several concatenated PEM blocks (a full chain)
  • Per-cert: validity dates + days left, self-signed flag, basicConstraints CA role
  • Chain: Issuer/Subject ordering and issuer-key signature verification
  • Optional hostname / SAN match with RFC 6125 wildcard rules
  • Output: an overall PASS / WARN / FAIL verdict with reasons, fully in-browser
Methodology

How the Chain Is Checked (RFC 5280)

Each PEM block is base64-decoded to DER and walked by a hand-written ASN.1 Tag-Length-Value reader (the shared x509Engine.ts) into the RFC 5280 Certificate structure: tbsCertificate, signatureAlgorithm and signatureValue. A pure verifier engine (certVerifierEngine.ts) then applies the checks. Validity compares notBefore / notAfter against the current time. Ordering compares each certificate’s Issuer distinguished name, rendered from its RDNSequence, to the Subject of the next certificate in the pasted list — catching a reversed or wrong-issuer chain before any crypto runs. The issuing certificate for the signature check is the next certificate in the chain, or the certificate itself when it is self-signed. Roles (leaf, intermediate, root, or single) are inferred from position and the self-signed flag.

  • Certificate ::= SEQUENCE { tbsCertificate, signatureAlgorithm, signatureValue }
  • The exact DER bytes of tbsCertificate are the message the signature covers
  • Ordering: cert[i].Issuer DN must equal cert[i+1].Subject DN (RFC 5280 §6)
  • An issuer that signs another certificate must assert basicConstraints CA:TRUE
  • Reuses the ITU-T X.690 (DER) engine — no ASN.1 library dependency
Technical Details

Signature Linking and Hostname Matching (Web Crypto, RFC 6125)

For every link, the issuer’s SubjectPublicKeyInfo is imported with crypto.subtle.importKey (SPKI format) and the certificate’s signature is checked over its tbsCertificate bytes with crypto.subtle.verify. RSASSA-PKCS1-v1_5 (SHA-1/256/384/512) is verified directly; for ECDSA the DER-encoded r/s signature is converted to the raw IEEE P1363 form and verified against the issuer key’s named curve (P-256 / P-384 / P-521). Hostname matching follows RFC 6125: the requested name is compared to the leaf’s dNSName SANs, where a wildcard replaces exactly one left-most label (*.example.com matches api.example.com, not a.b.example.com, and not the bare example.com); partial wildcards are rejected, and the tool falls back to the deprecated Subject CN only when no SANs exist, and says so.

  • importKey(SPKI) + verify() over the tbsCertificate DER, per link
  • ECDSA r/s DER converted to raw P1363 before verification
  • Supported: RSASSA-PKCS1-v1_5 and ECDSA P-256/384/521
  • Unsupported (marked, not guessed): RSASSA-PSS, Ed25519, Ed448, DSA, SHA-224
  • Wildcard covers a single left-most label; partial wildcards rejected
Limitations

Honest Limitations: Consistent and In-Date, Not Trusted

A PASS means the certificates you supplied form an internally consistent, in-date chain whose signatures verify against the issuers you gave. It does not check revocation via CRL or OCSP, and it does not verify the chain against your operating system or browser trust store of root CAs — both require network calls a client-side tool deliberately never makes. So a chain can PASS here and still be revoked, or rooted in a CA that no browser trusts; a self-signed chain will PASS internal consistency while being untrusted in the real world; and a link signed with an algorithm the Web Crypto API cannot verify (RSASSA-PSS, Ed25519, DSA, SHA-224) is reported as unsupported and downgrades the verdict to WARN rather than a false PASS. For a real trust decision, rely on a browser TLS handshake or openssl verify against a trusted CA bundle with revocation enabled.

  • Does NOT check revocation (CRL / OCSP)
  • Does NOT verify against the OS / browser trusted-root store
  • Self-signed chains pass internal consistency but are not publicly trusted
  • Unsupported signature algorithms produce a WARN, never a fake PASS
  • A PASS is a consistency + expiry result, not a statement of public trust
Privacy & Security

Private by Design

Everything happens on your device. Each PEM block is base64-decoded and parsed by a local ASN.1 engine, and every signature is verified with the Web Crypto API, so the certificate text never touches a server, database, CDN or log. This matters because certificates and full chains can disclose internal hostnames, organisational units and infrastructure topology. Nothing is persisted, the tool works offline once cached, and closing the tab erases everything; the only optional network use anywhere on the site is consent-gated ads that never see your certificates.

  • No upload, server, database, CDN or telemetry in the processing path
  • Certificate subjects, SANs and chain details never leave your device
  • Nothing persisted; works offline once cached
  • Signature math runs in your browser via crypto.subtle
  • Only optional network use is consent-gated ads that never see your input
What this verifier checks vs a full browser TLS validation
CheckThis verifierBrowser TLS / openssl verify
Validity dates (notBefore / notAfter)Yes — locallyYes
Chain ordering (Issuer ↔ Subject)Yes — locallyYes
Signature link to the issuer keyYes — Web Crypto (RSA / ECDSA)Yes
Hostname / SAN match (RFC 6125)Yes — locallyYes
Revocation (CRL / OCSP)NoYes
Trust to an OS / browser root storeNoYes
Sends the certificate to a serverNeverFetches CRL/OCSP over the network

This tool verifies chain consistency, dates, hostname and signature links in the browser; it does not check revocation or a trusted root store. A PASS is not a statement of public trust. As of July 2026.