SSL Certificate Decoder

About SSL Certificate Decoder

What the Decoder Shows

Paste a PEM certificate (the block between BEGIN CERTIFICATE and END CERTIFICATE) and the tool extracts all key fields defined in RFC 5280, the IETF X.509 profile for internet PKI:

Field	What It Contains	Example
Version	X.509 version (almost always v3)	v3
Serial Number	Unique identifier assigned by the CA	04:E3:5C:7F:... (hex)
Signature Algorithm	Algorithm used to sign the certificate	SHA256withRSA, SHA384withECDSA
Issuer	The Certificate Authority that issued it	CN=Let's Encrypt R3, O=Let's Encrypt
Subject	Who the certificate was issued to	CN=example.com
Not Before	When the certificate became valid	2025-01-15T00:00:00Z
Not After	When the certificate expires	2025-04-15T23:59:59Z
Public Key	Key type, size, and algorithm	RSA 2048-bit, EC P-256
SHA-256 Fingerprint	Hash of the entire certificate (DER form)	A1:B2:C3:D4:... (hex)

A colour-coded banner shows whether the certificate is currently valid (green), expired (red), or not yet valid (amber). A visual timeline bar shows where today falls between the issue and expiry dates. When the subject Common Name equals the issuer Common Name, a "Self-signed" pill is displayed.

How the Decoder Works Internally

The decoding process happens entirely in your browser using JavaScript and the Web Crypto API:

Step	What Happens
1. Strip PEM headers	Remove the BEGIN/END CERTIFICATE lines and any whitespace
2. Base64 decode	Convert the Base64 string to raw binary bytes (DER format)
3. Parse ASN.1	Walk the DER-encoded ASN.1 structure (TLV - Tag, Length, Value)
4. Extract fields	Read each field from the TBSCertificate sequence
5. Map OIDs	Convert numeric OIDs to human-readable names (e.g., 2.5.4.3 = Common Name)
6. Compute fingerprint	Hash the raw DER bytes with SHA-256 using Web Crypto API

Common Certificate Types

Type	Validation Level	What the CA Verifies	Visual Indicator
DV (Domain Validated)	Basic	Applicant controls the domain (via DNS or HTTP challenge)	Padlock only
OV (Organisation Validated)	Medium	Domain control + organisation identity verified	Padlock, org name in certificate details
EV (Extended Validation)	High	Domain + org + legal entity verified through rigorous process	Padlock, org name visible in some browsers
Wildcard	Varies (usually DV)	Same as base type, covers *.example.com	Same as base type
Multi-domain (SAN)	Varies	Multiple domains listed in Subject Alternative Names	Same as base type

Certificate Validity Periods

Maximum public TLS certificate validity drops from 398 days to 200 days on 15 March 2026, to 100 days on 15 March 2027, and to 47 days on 15 March 2029 under CA/Browser Forum Ballot SC-081v3 (passed April 2025). Shorter lifespans mean compromised certificates expire faster and certificate revocation becomes less critical, but they also make automation essential.

Certificate Source	Validity as of April 2026	Renewal Method
Let's Encrypt (classic ACME)	90 days (switching to 64 days on 10 Feb 2027)	Automated via ACME (certbot, acme.sh, Caddy)
Let's Encrypt (tlsserver profile)	45 days from 13 May 2026 (opt-in)	Automated ACME
Let's Encrypt (short-lived profile)	6 days (opt-in, launched Feb 2025)	Automated ACME
Commercial CA (DV/OV, public)	200 days max from 15 March 2026	Manual or automated renewal
Self-signed	Custom (often 1-10 years)	Manual regeneration via OpenSSL
Internal / Private CA	Custom (not bound by CA/B Forum)	Depends on organisation policy

The previous cap of 398 days was set in September 2020. The 47-day target pairs with a 10-day maximum for domain-validation reuse, which collapses the window between issuance and fresh revalidation from today's 825 days to a matter of weeks. Any organisation still renewing certificates by hand will have to automate before 2027 to avoid outages.

Signature Algorithms

The signature algorithm determines how the certificate's integrity is verified. Modern certificates use one of these algorithms:

Algorithm	Key Type	Common Key Sizes	Status
SHA256withRSA	RSA	2048, 4096 bits	Current standard, widely supported
SHA384withRSA	RSA	3072, 4096 bits	Higher security, slightly slower
SHA256withECDSA	EC (P-256)	256 bits (equivalent to RSA 3072)	Modern, faster, smaller certificates
SHA384withECDSA	EC (P-384)	384 bits	High security, used by some government CAs
SHA1withRSA	RSA	Various	Deprecated - browsers reject SHA-1 certificates

ECDSA certificates are gaining popularity because they offer equivalent or better security than RSA with much smaller key sizes, resulting in faster TLS handshakes. Let's Encrypt now offers ECDSA certificates by default.

How to Get a Certificate for Decoding

If you want to decode a certificate from a live website, you can extract it using the command line:

Method	Command / Steps
OpenSSL (command line)	openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -outform PEM
Browser (Chrome/Firefox)	Click the padlock icon, then Connection is secure, then Certificate is valid, then Details tab, then Export/Copy
From a file	Open the .pem or .crt file in a text editor and copy the entire block including BEGIN/END lines

For decoding Base64 strings outside of certificates, try the Base64 encoder and decoder. If you need to verify data integrity with hashes, the hash generator supports SHA-256 and other algorithms. All processing happens in your browser - your certificate data never leaves your device.

Why Are Certificate Lifetimes Getting Shorter?

Shorter-lived certificates close the gap between a private-key compromise and the moment attackers can no longer use the stolen certificate. The Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs) have a patchy track record - Apple deprecated OCSP Stapling in macOS Big Sur (2020), Chrome relies on CRLSets that only cover selected revocations, and Mozilla announced the end of client-side OCSP checking in Firefox 136 (March 2025). If revocation cannot be trusted, expiry becomes the only reliable kill switch.

Worked example: a 398-day certificate issued on 1 January 2025 remains usable until 3 February 2026. If the private key leaks on 15 February 2025 and revocation fails to propagate, attackers have 354 days of window. The same leak against a 47-day certificate issued on 1 February 2029 exposes at most 33 days, an 11x reduction. This is the core case made by Apple (WebPKI thread, 2023) and Google's "Moving Forward, Together" roadmap (2023) for aggressive lifetime cuts.

What Are X.509 Extensions?

X.509 v3 added the concept of extensions - optional fields that carry information beyond the core identity and key. Modern browsers rely heavily on these. This decoder focuses on the core TBSCertificate fields; the most common extensions you will see on a real website certificate are listed below.

Extension	Purpose	Example Value
Subject Alternative Name (SAN)	Lists all domains the certificate is valid for. Browsers IGNORE the CN for SNI matching.	DNS:example.com, DNS:*.example.com
Key Usage	What the key is allowed to do	Digital Signature, Key Encipherment
Extended Key Usage (EKU)	Higher-level purpose (TLS server, TLS client, code signing)	serverAuth, clientAuth
Authority Key Identifier	Links the certificate to its issuing CA certificate	keyid:AB:CD:EF:...
CRL Distribution Points	URL where the revocation list can be fetched	http://crl.example-ca.com/root.crl
Authority Information Access	URLs for OCSP responders and issuing CA certificate	OCSP - http://ocsp.example-ca.com
Certificate Transparency SCTs	Signed receipts proving the cert was logged to public CT logs	3 SCTs from Google Argon, Cloudflare Nimbus, DigiCert Yeti

Since 30 April 2018, Chrome requires every publicly-trusted TLS certificate to be logged to at least two Certificate Transparency logs. The logs are append-only Merkle trees that anyone can audit, which is how researchers discovered Symantec's misissuances in 2015-2017 and why Symantec's CA business was eventually distrusted by Chrome and Mozilla.

How Do You Verify a Certificate Chain?

A single PEM block only contains the end-entity (leaf) certificate. Real TLS deployments need the full chain - leaf, one or more intermediates, and an implicit root that the browser already trusts. The chain is validated in four steps per RFC 5280 section 6:

1. Signature check: each certificate's signature must verify against the next certificate's public key, up to the root.
2. Validity check: the current date must fall within every certificate's notBefore/notAfter window.
3. Name constraints and policy check: SAN DNS names must match the site being visited, and any nameConstraints on intermediates must be honoured.
4. Revocation check: OCSP/CRL are consulted where available (many browsers soft-fail if the responder is unreachable).

Common chain errors seen in production: missing intermediate ("incomplete chain"), expired intermediate, AIA pointing at a 404, OCSP responder returning 500s, or the host presenting certificates in the wrong order (most servers expect leaf-first, then intermediates). The openssl s_client output labelled "Verify return code: 0 (ok)" confirms the chain built successfully from the host's local trust store.

Common Certificate Decoding Mistakes

• Confusing CN with SAN. Modern browsers match only against Subject Alternative Names. A certificate with CN=example.com but no SAN will fail in Chrome (since 2017) and Firefox.
• Copying only part of the PEM block. The BEGIN/END CERTIFICATE lines are required; without them Base64 decoding still succeeds but ASN.1 parsing will fail on a truncated tail.
• Mixing up fingerprint algorithms. SHA-1 fingerprints (40 hex chars) are still widely shown by openssl and browsers for pinning purposes. The certificate's signature algorithm is unrelated to the fingerprint algorithm - a SHA256withRSA certificate still has a SHA-1 fingerprint if you ask for one.
• Trusting a self-signed certificate in production. The "Self-signed" pill shown by this decoder means issuer equals subject - fine for internal or test environments, never acceptable for a public website.
• Treating notAfter as renewal deadline. Renew at least 1/3 of the validity period before expiry to absorb DNS, ACME challenge, or CA outages. With 47-day certs, that means automated renewal at day 30 and alerting at day 40.
• Assuming wildcards work for multi-level subdomains. *.example.com matches a.example.com but NOT a.b.example.com. RFC 6125 limits wildcard substitution to a single label.

Sources

• IETF RFC 5280 - Internet X.509 Public Key Infrastructure Certificate Profile
• CA/Browser Forum Ballot SC-081v3 - Reducing Validity Schedule
• CA/Browser Forum - Baseline Requirements for TLS Server Certificates
• Let's Encrypt - Decreasing Certificate Lifetimes to 45 Days
• Let's Encrypt - Upcoming Features Roadmap
• IETF RFC 6962 - Certificate Transparency
• IETF RFC 6125 - Domain-Based Application Service Identity