SSL Certificate Decoder
Decode any SSL/TLS certificate PEM file to view all technical details, SANs, and cryptographic information.
What is SSL Certificate Decoder?
SSL/TLS certificates are encoded in formats like PEM (Privacy Enhanced Mail, the Base64-encoded format starting with -----BEGIN CERTIFICATE-----) or DER (Distinguished Encoding Rules, the binary format). While the SSL checker verifies a live website's certificate, the SSL decoder is for inspecting a certificate file directly — such as a certificate you have just generated, received from a CA (Certificate Authority), or exported from a server for inspection or transfer. Decoding a certificate reveals all its embedded information: the subject (who the certificate was issued for), the issuer (which CA signed it), validity dates (not before/not after), Subject Alternative Names (all domains the certificate covers), key algorithm and size (RSA 2048-bit, ECDSA 256-bit), signature algorithm, and whether it is a root, intermediate, or leaf certificate. This information is essential for certificate troubleshooting, CSR verification, and certificate chain analysis.
How to Use SSL Certificate Decoder
- 1
Paste the Certificate
Paste a PEM-encoded certificate (the text starting with -----BEGIN CERTIFICATE----- and ending with -----END CERTIFICATE-----). The tool decodes and parses all fields.
- 2
View All Certificate Fields
See the fully parsed certificate: subject, issuer, validity period, public key algorithm and size, signature algorithm, all SANs, key usage, and extended key usage.
- 3
Inspect Certificate Chain
Paste multiple certificates (leaf → intermediate → root) to analyse the full chain and verify proper ordering and signing relationships.
Use Cases
Certificate Installation Verification
After installing an SSL certificate on a server, paste the installed certificate to verify it matches what was ordered (correct domains in SANs), hasn't expired, and was issued by the expected CA. Certificate/key mismatches are a common SSL configuration error this tool diagnoses immediately.
Certificate Chain Troubleshooting
SSL errors citing "incomplete certificate chain" or "unknown issuer" are caused by missing intermediate certificates. Paste the certificate and its chain to verify all intermediate certificates are present, correctly ordered, and properly sign each other.
CSR Verification Before Submission
Before submitting a Certificate Signing Request to a CA, decode it to verify the subject information is correct (organisation name, country, common name) and the SANs include all required domains — preventing resubmission costs if the CSR contains errors.
Features
Full Certificate Parsing
Decodes all X.509 certificate fields: subject DN, issuer DN, serial number, validity dates, public key info, key usage, extended key usage, SANs, and all extensions.
SAN List Display
Lists all Subject Alternative Names (the domains and IPs the certificate is valid for) in a clear, readable format — quickly verifying that all required domains are covered.
Chain Validation
When multiple certificates are pasted, validates that they form a proper chain: each certificate's issuer matches the next certificate's subject.
CSR and Key Matching
Verifies that a certificate matches its corresponding CSR or private key by comparing public key fingerprints — preventing certificate/key mismatch errors that cause SSL installation failures.
Frequently Asked Questions
PEM (Privacy Enhanced Mail) is a Base64-encoded container format for cryptographic objects including certificates, private keys, and certificate chains. It is the most common format for SSL certificates on Linux/Unix servers. A PEM certificate begins with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----. The text between these markers is Base64-encoded DER (the binary certificate format). PEM files can contain multiple certificates (certificate chain) by including multiple BEGIN/END blocks.
A root certificate is self-signed and belongs to a trusted Certificate Authority (CA) — it is pre-installed in operating systems and browsers as a trust anchor. An intermediate certificate is signed by the root CA and signs leaf certificates — CAs use intermediates as a security buffer (if an intermediate is compromised, only that intermediate's certificates need revocation, not all root-signed certificates). A leaf certificate is the end-entity certificate issued for your specific domain — it is signed by an intermediate CA. A proper SSL installation includes the leaf certificate plus all intermediate certificates; the root is trusted by the browser and doesn't need to be served.
SANs are the list of domain names and IP addresses that a certificate is valid for. Modern SSL certificates use SANs rather than (or in addition to) the Common Name (CN) field to specify covered domains. A single certificate can cover multiple domains: example.com, www.example.com, blog.example.com, and api.example.com can all be in the SAN list of one certificate — called a multi-domain or SAN certificate. Wildcard certificates use SANs like *.example.com to cover all single-level subdomains. Browsers verify that the domain in the URL matches a SAN entry before accepting the certificate as valid.
Need a Professional Website?
JAIDOO EMPIRE builds fast, SEO-optimised websites for businesses worldwide. All free tools are built and maintained by our team.
Start Your Project
