X.509 Certificate Decoder
Decode the details of an X.509 SSL/TLS certificate in PEM format.
Reviewed by the ToolNestr Editorial Team — July 2026
How X.509 certificates work
An X.509 certificate binds a cryptographic public key to an identity — typically a domain name, organization, or individual. The certificate is signed by a trusted Certificate Authority (CA), creating a verifiable link between the public key and the identity it represents. The structure above shows the two main sections: the TBSCertificate (the data being certified) and the Signature (the CA's cryptographic proof).
When a browser connects to an HTTPS website, the server presents its certificate during the TLS handshake. The browser verifies the signature using the CA's public key, checks the validity period, confirms the hostname matches a SAN entry, and ensures the certificate hasn't been revoked. This verification process establishes the secure connection.
The certificate verification process
Parse and validate
The browser parses the PEM certificate, checks the signature algorithm, validity dates, and ensures the certificate structure conforms to X.509 standards.
Verify chain of trust
Each certificate in the chain is verified against the next, ending at a trusted root CA stored in the browser's trust store. The signature of each parent must validate the child certificate.
Check hostname and expiry
The browser confirms the requested hostname matches a SAN entry, the current date falls within the validity period, and the certificate hasn't been revoked via CRL or OCSP.
PKI and the chain of trust
The chain of trust (or certification path) is a hierarchical model where each certificate is signed by the private key of the next certificate in the chain. At the top is the Root CA — a self-signed certificate that is inherently trusted. Root CAs issue certificates to Intermediate CAs, which in turn issue end-entity (leaf) certificates to websites and services.
Browsers and operating systems ship with a list of approximately 150 trusted Root CA certificates. When verifying a server certificate, the browser constructs the chain from the server certificate up to a trusted root. Each signature is verified using the public key of the parent certificate. If any link in the chain fails verification, the browser displays a security warning.
Common use cases
Debugging SSL issues
When a website shows certificate errors, decoding the PEM certificate reveals the issuer, validity dates, and SANs. You can quickly identify expired certificates, mismatched hostnames, or untrusted issuers without using OpenSSL on the command line.
Verifying certificate details
Before deploying a new certificate to production, decode it to verify the subject name, SAN entries, key size, and signature algorithm match what was requested from the CA. Catching misconfigurations before deployment prevents downtime.
Expiry checking
Monitor certificate expiry dates to avoid unexpected outages. Decode certificates to see exact notAfter timestamps. Many organizations automate expiry monitoring, but manual spot-checks provide an additional safety layer.
Certificate fingerprint verification
Compare the SHA-256 fingerprint of a certificate against known values to ensure you have the correct certificate. This is particularly useful for certificate pinning and verifying certificates obtained through different channels.
Tips for working with certificates
Always check the expiry date
Certificate expiry is the most common cause of SSL errors. Modern certificates are typically valid for 90 days to 1 year (Apple and Google have pushed for 90-day max validity). Set up calendar reminders or automated monitoring to renew certificates well before expiry.
Verify the chain of trust
A certificate is only as trustworthy as the chain it belongs to. Ensure that your server sends the full certificate chain including all intermediate CA certificates. Missing intermediates cause trust errors on clients that don't have the intermediate cached.
Wildcard certificates cover only one level
A wildcard certificate for *.example.com covers www.example.com and mail.example.com, but does NOT cover example.com (the bare domain) or sub.www.example.com (multiple levels). You need separate SAN entries for each level you need to cover.
Use strong key algorithms
RSA 2048-bit is the current minimum standard. For better security and performance, consider ECDSA with P-256 or P-384 curves. ECDSA keys are smaller and require less CPU for the same security level. Some CAs now offer ECDSA certificates as a standard option.
Related tools
Frequently asked questions
What is an X.509 certificate?
An X.509 certificate is a digital document that binds a public key to an identity (such as a domain name or organization). It is signed by a Certificate Authority (CA) to establish trust. X.509 is the standard format for SSL/TLS certificates used by HTTPS websites.
What is PEM format?
PEM (Privacy-Enhanced Mail) is a Base64-encoded representation of the binary DER certificate data, wrapped with "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" header/footer lines. It is the most common format for distributing certificates.
Can I decode a certificate from a website?
This tool only decodes certificates you paste. To get a website's certificate, click the padlock icon in your browser's address bar, view the certificate details, and export it in PEM format.
Does this tool send my certificate anywhere?
No — all decoding happens entirely in your browser using JavaScript and the Web Crypto API. The certificate data never leaves your device.
What is a certificate fingerprint?
The fingerprint is a SHA-256 hash of the entire DER-encoded certificate. It uniquely identifies the certificate and is used for pinning and verification purposes.
What is the chain of trust?
The chain of trust is a hierarchical model where each certificate is signed by the next higher authority, starting from the server certificate, through intermediate CAs, up to a trusted root CA. Browsers ship with a list of trusted root CA certificates.
What do SANs (Subject Alternative Names) do?
SANs list all the domain names and IP addresses that a certificate is valid for. Modern browsers require that the hostname matches one of the SAN entries. Wildcard certificates use *.domain.com to cover all subdomains.
What does the expiry date tell me?
The certificate's validity period (notBefore and notAfter) defines when the certificate is considered valid. Browsers will show security warnings for expired certificates. Always check the notAfter date to ensure a certificate is still current.