SSL Certificate & CSR Decoder

An SSL certificate decoder turns the block of base64 text between BEGIN and END lines into fields you can actually read. Paste a certificate, a full chain or a certificate signing request (CSR) and this decoder shows the subject and issuer, every Subject Alternative Name, the validity dates with days remaining, the serial number, the signature algorithm, the key type and size, SHA-256 and SHA-1 fingerprints, key usage, OCSP and CRL addresses, and whether the certificate is a leaf, an intermediate or a self-signed root. For bundles it checks that each certificate is really signed by the next one, and it flags common problems such as expiry, SHA-1 signatures, short RSA keys, a Common Name missing from the SAN list and lifetimes longer than public CAs may issue. It works as a CSR decoder too, so you can confirm the hostnames and key before you order. Private keys are refused, and nothing you paste is stored.

How to use the SSL decoder

1. 1 Copy the certificate, chain or CSROpen the .crt, .pem, .cer or .csr file in a text editor, or copy it from your hosting panel or CA email. Include the -----BEGIN and -----END lines. For a chain, paste all certificates one after another.
2. 2 Paste it and select DecodeThe decoder detects the type automatically: a single certificate, a bundle, a PKCS#7 block or a CSR. Base64-encoded DER without headers is accepted too. The limit is 64 KB.
3. 3 Read the warnings firstRed items will break HTTPS (expired, SHA-1, no SAN, broken chain). Amber items are worth fixing soon. A green line means nothing problematic was found in that item.
4. 4 Check names, dates and the keyConfirm every hostname you need is in the SAN list, the validity dates are what you expect, and the key is RSA 2048 bits or more, or an EC P-256 or P-384 key.
5. 5 Copy the details or test the live siteCopy one item or the whole result as plain text for a ticket. To see what visitors actually receive, run the SSL Checker on the live hostname.

What a certificate decoder shows you

A TLS certificate is a signed data structure in the X.509 format. On disk it is usually stored as PEM: the binary DER encoding, converted to base64 and wrapped between header and footer lines. That format is easy to copy and paste, but impossible to read by eye. A decoder parses the structure and lays out each field, so you can answer practical questions in seconds. Is this the right certificate for the domain? When does it run out? Who issued it? Does this bundle contain the intermediate my server is missing?

People reach for a decoder at predictable moments: when a CA emails a certificate and you want to confirm it before installing it, when a hosting panel shows an unexplained error, when you inherit a server and need to know what is on it, or when a colleague sends a CSR and you want to check it before it goes to the CA. Because certificates and CSRs only contain public information, decoding them in a web tool is safe. Private keys are different, which is why this tool refuses them outright.

Every field explained

The subject identifies who the certificate belongs to, and the issuer identifies the certificate authority (CA) that signed it. Both are distinguished names made of short attributes. Domain-validated certificates often carry only a Common Name, while organization-validated and extended-validation certificates add the organization, locality and country.

For websites, the most important field is the Subject Alternative Name (SAN) extension. Browsers match the hostname in the address bar against the SAN list only; the Common Name is ignored for that purpose. A wildcard such as *.example.com covers one label, so it matches www.example.com but not example.com itself or a.b.example.com.

• Valid from and valid until: the window in which the certificate is accepted, shown in UTC with the days remaining.
• Serial number: a unique number chosen by the CA, used in revocation lists and when you contact the CA about a specific certificate.
• Signature algorithm: how the CA signed it, for example sha256WithRSAEncryption or ecdsa-with-SHA256.
• Public key: RSA with its size in bits, or an elliptic-curve (EC) key with its named curve.
• Fingerprints: SHA-256 and SHA-1 hashes of the whole certificate, handy for comparing two copies or pinning in configuration.
• Key usage and extended key usage: what the key may be used for, such as digital signatures and TLS web server authentication.
• Basic constraints: whether the certificate is a CA that may sign other certificates, and any path length limit.
• OCSP, CA Issuers and CRL addresses: where clients can check revocation status and download the issuing certificate.

How to get your certificate or CSR

Most CAs deliver the certificate by email or in their dashboard, often as a ZIP with the leaf certificate and a separate CA bundle. Open the files in a plain text editor; if you see BEGIN CERTIFICATE lines, you can paste the text straight in. A binary .der or .cer file is DER, which you can convert with openssl x509 -inform der -in cert.der -out cert.pem, or paste its base64 encoding.

On a running server, the certificate files are referenced in the web server configuration: SSLCertificateFile in Apache, ssl_certificate in nginx, or the certificate store in IIS. On cPanel you will find installed certificates under SSL/TLS. To grab the chain a live site serves, the openssl s_client example below prints every certificate the server sends.

A CSR is generated together with the private key, either on the server with openssl, in your hosting panel, or by your load balancer or cloud provider. Paste only the part between BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST. The decoder shows the subject, the public key, any SANs requested through the extension request attribute, and whether the CSR signature is still valid, which proves it was not changed after it was created.

Reading a chain and fixing common chain problems

Browsers trust a site certificate because it was signed by an intermediate CA, which was in turn signed by a root that ships with the operating system or browser. Your server must send the leaf certificate first, then each intermediate in order. The root is normally left out, because clients already have it. When you paste a bundle, the decoder checks every link: whether the issuer name of each certificate matches the subject of the next, and whether the next certificate's public key actually verifies the signature. A name match without a valid signature usually means an intermediate from a different generation of the same CA.

The most common faults are a missing intermediate, certificates in the wrong order, an old or unrelated intermediate pasted from a previous installation, a duplicate certificate, and the leaf certificate placed after the intermediates. Desktop browsers sometimes hide a missing intermediate by fetching it themselves or remembering it from another site, so a broken chain can look fine on your laptop while failing on phones, API clients and monitoring tools. When the decoder reports a broken link, download the current intermediate from the CA Issuers address or your CA's documentation and rebuild the file in the order it suggests.

Warnings this decoder raises and what to do

Each warning maps to a concrete fix. An expired or not-yet-valid certificate needs renewing, or the server clock needs correcting. A SHA-1 or MD5 signature on a leaf or intermediate is no longer accepted by modern browsers, so ask the CA to reissue it. RSA keys shorter than 2048 bits fall below the minimum public CAs may issue, so generate a new key and CSR. A missing SAN, or a Common Name that does not appear in the SAN list, means browsers will not match that name. Self-signed leaf certificates are fine for testing or internal tools where you control every device, but not for public websites.

The decoder works from the certificate alone. It does not contact OCSP responders or CRLs, so a revoked certificate can decode cleanly. It does not check Certificate Transparency logs or whether a root is in browser trust stores, and it cannot tell which certificate your server actually sends. The SSL Checker connects to the live site for those checks.

Certificate lifetimes are shrinking

Under CA/Browser Forum ballot SC-081v3, the maximum validity of publicly trusted TLS certificates depends on when they are issued: 398 days before March 15, 2026, 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. The decoder compares a leaf certificate's lifetime with the limit for its issue date and warns when it is longer. Certificates from a private or internal CA are not bound by these rules, so treat that warning as information when the certificate is for internal use.

Shorter lifetimes make manual renewal impractical. Let's Encrypt has also announced its own move to shorter certificates, which our blog covers in detail along with the full CA/Browser Forum schedule. The practical answer is automation: use an ACME client such as Certbot or acme.sh, or let your host, CDN or load balancer issue and renew certificates. Then monitor the certificate each hostname actually serves, because a renewal that succeeds on disk but never reloads the web server still expires in public.

Examples you can copy

openssl x509 -in cert.pem -noout -text

# Just the essentials
openssl x509 -in cert.pem -noout -subject -issuer -dates -ext subjectAltName
openssl x509 -in cert.pem -noout -fingerprint -sha256

openssl req -in request.csr -noout -text -verify

openssl req -new -newkey rsa:2048 -nodes -sha256 \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

# leaf.pem = your certificate, intermediate.pem = CA bundle, root.pem = the root
openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem
# Expected output: leaf.pem: OK

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in private.key -pubout | openssl sha256
openssl req -in request.csr -noout -pubkey | openssl sha256
# Identical hashes = the key belongs to that certificate or CSR

Common mistakes to avoid

Frequently asked questions