SSL/TLS certificate decoder

How the decoder works

A PEM certificate is base64 text wrapped between BEGIN and END lines. Inside is a binary structure in DER, the Distinguished Encoding Rules of ASN.1 (ITU-T X.690), laid out as specified in RFC 5280. The decoder removes the wrapper, decodes the base64, and walks the DER one tag-length-value element at a time: the body to be signed (version, serial number, issuer, validity period, subject, public key, extensions), then the signature algorithm and the signature.

Everything is done in JavaScript in this page. The two fingerprints are the SHA-256 and SHA-1 hashes of the DER bytes, computed with the browser's built-in Web Crypto API, so they match what openssl x509 -noout -fingerprint -sha256 prints. The decoder does not verify the signature or build a chain to a trusted root: that needs the issuer's certificate and the operating system's trust store, and is what your browser does on every connection.

What the checks mean

The lifetime limit is shrinking in steps under CA/Browser Forum ballot SC-081: 398 days until 15 March 2026, 200 days from then, 100 days from 15 March 2027 and 47 days from 15 March 2029. Certificates from a private, internal CA are not bound by these rules, so a long lifetime there is a warning, not an error.

A worked example

The pre-loaded certificate was generated for this page (it signs nothing real). Its subject is simply CN=example.com, and its SAN list names three hosts: example.com, www.example.com and *.static.example.com. Checking www.example.com passes on the second entry; img.static.example.com would pass on the wildcard; shop.example.com fails because no entry covers it.

It is valid from 1 September 2026 to 1 March 2027, a lifetime of 181 days, inside the 200-day limit that applies to certificates issued after 15 March 2026. The key is ECDSA on the P-256 curve, and the signature is ecdsa-with-SHA256. Key usage is digital signature only and extended key usage is TLS server authentication, which is exactly right for an ECDSA server certificate. The policy identifier 2.23.140.1.2.1 marks it as domain validated, and the Authority Information Access extension says where a client can fetch the issuer (CA Issuers) and check revocation (OCSP).

Reading the extensions

• Basic Constraints says whether this is a CA. Server certificates must say CA: no.
• Key Usage and Extended Key Usage limit what the key may be used for. A server certificate needs TLS server authentication.
• Subject and Authority Key Identifier link a certificate to its issuer: a leaf's authority key ID equals the intermediate's subject key ID. Use them to check a chain is in the right order.
• Signed Certificate Timestamps are proof the certificate was logged in Certificate Transparency; Chrome and Safari require them for publicly trusted certificates.
• CRL Distribution Points and OCSP are the two revocation mechanisms. The Baseline Requirements made OCSP optional in 2023, and Let's Encrypt stopped putting OCSP URLs in its certificates in 2025, so a new certificate without one is not a fault.

Where this tool stops

It reads what the certificate says; it cannot tell whether the CA really issued it, whether it has been revoked, or whether the server presents it correctly. The validity result uses your device's clock, so a wrong clock gives a wrong answer. Unusual extensions are listed by object identifier and size rather than decoded. Certificate signing requests, private keys and PKCS#12 files are not certificates and are not decoded.