SSL Certificate Decoder
Paste a PEM-encoded X.509 certificate to decode its subject, issuer, validity dates, and key details. Supports certificate chains.
Certificate details will appear here after decoding.
Paste the same PEM certificate above (in Decode tab) — analysis results display here automatically.
Decode a certificate first to see analysis.
X.509 Certificate Fields
| Field | Description |
|---|---|
| Version | X.509 version (v1, v2, v3). Modern certs are v3. |
| Serial Number | Unique identifier assigned by the CA. Used in CRLs/OCSP. |
| Subject | Distinguished Name (DN) of the certificate owner. Includes CN, O, C, etc. |
| Issuer | Distinguished Name of the CA that signed the certificate. |
| Not Before | Start of validity period. Certificate is not valid before this date. |
| Not After | End of validity period (expiry date). |
| Public Key | The subject's public key and algorithm (RSA, ECDSA, etc.). |
| Signature Algorithm | Algorithm used by the CA to sign the certificate (e.g. SHA256withRSA). |
| SAN | Subject Alternative Names — additional domains/IPs covered by the cert. |
| Key Usage | Permitted uses: Digital Signature, Key Encipherment, Certificate Signing, etc. |
| Extended Key Usage | TLS Web Server Authentication, TLS Web Client Authentication, Code Signing, etc. |
| Basic Constraints | Is CA: whether this cert can sign other certs. Path length constraint. |
How to Use the SSL Certificate Decoder
- Get the PEM certificate — Export it from your web server, certificate manager, or browser (click the padlock, view certificate, export PEM). You can also use OpenSSL:
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -outform PEM - Paste it in the input area — include the
-----BEGIN CERTIFICATE-----and-----END CERTIFICATE-----lines. For a certificate chain, paste all certificates in order. - Review the output — the Decode tab shows all fields parsed from the certificate. The Analyze tab shows a validity check, days until expiry, and a visual timeline.
Understanding X.509 Certificate Structure
An X.509 certificate is a digitally signed document that binds a public key to an identity (a domain name, organisation, or individual). It is encoded using ASN.1 DER (Distinguished Encoding Rules) — a binary format — and then Base64-encoded into PEM for easy storage and transport. The certificate contains three main sections: TBS (to-be-signed) certificate data, the signature algorithm identifier, and the CA's signature over the TBS section.
Certificate Chains and Trust
A single HTTPS connection typically involves a certificate chain: the end-entity certificate (issued for your domain), one or more intermediate CA certificates, and a root CA certificate trusted by browsers. Browsers ship with a built-in list of trusted root CAs. When a browser connects to your server, it verifies that the chain leads to one of these trusted roots without any breaks. If an intermediate certificate is missing, browsers will show a certificate error even if the end-entity certificate itself is valid. This decoder supports pasting a full PEM chain — just concatenate all PEM blocks one after another.
Validity Period and Certificate Lifecycle
As of 2020, the maximum validity period for publicly trusted TLS certificates is 398 days (approximately 13 months). Let's Encrypt issues 90-day certificates to encourage automation via ACME clients like Certbot. When a certificate expires, browsers display a hard error that cannot be bypassed by most users. The Analyze tab in this tool calculates exactly how many days remain before expiry and shows a colour-coded validity bar: green for more than 30 days, amber for under 30 days, and red for expired certificates.
Subject Alternative Names (SANs)
Modern certificates use the Subject Alternative Names (SAN) extension to list all hostnames covered by the certificate. A wildcard SAN like *.example.com covers all immediate subdomains (www.example.com, api.example.com) but not deeper subdomains (sub.api.example.com). Multi-domain (SAN) certificates can cover up to hundreds of domains. Since 2017, major browsers have deprecated the Common Name (CN) field for hostname verification and require at least one SAN entry. Check the CSP Generator to complement your certificate-level security with content-level controls.
How to Read the OID Fields
Many certificate fields reference Object Identifiers (OIDs) — numeric identifiers from an international registry. For example, 2.5.4.3 is the OID for Common Name (CN), 2.5.4.10 for Organisation (O), and 1.3.6.1.5.5.7.3.1 for TLS Web Server Authentication in Extended Key Usage. This decoder translates the most common OIDs into human-readable names automatically.