🔐

SSL Certificate Decoder

Paste a PEM-encoded SSL/TLS certificate to decode issuer, subject, validity dates, SANs, signature algorithm, and key details — entirely in your browser.

About SSL Certificate Decoder — X.509 Certificate Reader Online

SSL/TLS certificates are stored as binary ASN.1 data, typically base64-encoded into the PEM text format. Reading certificate details normally requires command-line tools like OpenSSL. This decoder parses PEM-encoded X.509 certificates in your browser using the ASN.1 and PKI.js libraries, extracting every meaningful field: subject, issuer, validity dates, Subject Alternative Names (SANs), public key algorithm and size, signature algorithm, and serial number. Nothing is transmitted to any server — the certificate bytes never leave your browser.

Practical uses include verifying that a newly issued certificate covers the correct domains in its SAN list, confirming that the issuing CA matches what you requested, checking the expiration date during deployment or renewal planning, and debugging certificate chain issues by inspecting the issuer fields of each certificate in the chain. Developers configuring NGINX, Apache, or application servers regularly need to confirm certificate details without spinning up an OpenSSL command — pasting the PEM into a browser-based decoder is faster and available on any machine.

How to Use SSL Certificate Decoder

  1. Obtain the certificate in PEM format — it should begin with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----. See below for how to get the PEM from different sources.
  2. Paste the full PEM block into the text area, including the header and footer lines.
  3. Click Decode Certificate. The decoder parses the ASN.1 structure and displays all fields.
  4. Review the subject and issuer fields to confirm the certificate identity and CA, check the validity dates for the expiry, and inspect the Subject Alternative Names to verify domain coverage.
  5. If decoding fails, check that the PEM block is complete and not truncated — a partial base64 block will fail to parse.

Certificate Fields Explained

Each field in a decoded certificate provides specific information about the certificate's identity, validity, and cryptographic properties.

  • Subject: The entity the certificate was issued to. For domain certificates, this typically contains the Common Name (CN) which is the primary domain. The Subject has largely been superseded by SANs for domain matching, but it's still present for compatibility.
  • Issuer: The Certificate Authority (CA) that signed and issued this certificate. For publicly trusted certificates, the issuer traces back to a root CA trusted by major browsers. For self-signed certificates, the issuer and subject are the same.
  • Validity period: The Not Before and Not After dates. A certificate used outside this window will produce a security error in browsers. Not After is the expiration date — plan renewals at least 30 days before this date to avoid downtime.
  • Subject Alternative Names (SANs): The list of domains and IP addresses this certificate is valid for. This is the field browsers actually check against the requested hostname. A certificate with CN=example.com but no SANs will fail in modern browsers — SANs are required. Verify that your primary domain, www subdomain, and any other required subdomains are all present here.
  • Public Key: The algorithm and key size of the certificate's public key. RSA 2048-bit is the current minimum; RSA 4096 or ECDSA P-256 are common for higher security requirements. ECDSA keys are smaller and faster for the same security level as RSA.
  • Signature Algorithm: The algorithm used by the CA to sign the certificate — typically SHA-256 with RSA or ECDSA. SHA-1 signatures are no longer accepted by modern browsers; any certificate showing SHA1 in the signature algorithm needs immediate replacement.

Tips for Working with SSL Certificates

A few things to check every time you decode a certificate, particularly after issuance or renewal.

  • Check SANs before deployment: Certificates are often issued covering fewer domains than requested due to validation failures or configuration errors. Verify every domain and subdomain you need is in the SAN list before deploying. A missing subdomain won't be caught until users hit a security error in their browser.
  • Confirm the issuer chain: The issuer field shows the CA that signed this certificate, but modern deployments use intermediate CAs rather than the root directly. If the issuer is an intermediate CA, confirm your server is configured to serve the full chain (intermediate + leaf) — missing intermediates cause trust errors on some clients even if the root is trusted.
  • Check the validity period after automated renewal: If you use certbot or another ACME client, renewals should be automatic, but occasionally fail silently. Decode the active certificate and check Not After to confirm the renewal succeeded and you're not running an expired certificate.
  • Get the PEM from a running server with OpenSSL: Run openssl s_client -connect yourdomain.com:443 -showcerts to retrieve the certificate chain from a live server. The output contains PEM blocks you can paste directly here to inspect what certificate is actually being served.
  • Decode the full chain to verify each certificate: When troubleshooting chain issues, copy and paste each certificate in the chain separately. The decoder reads one certificate at a time — the subject of each intermediate should match the issuer of the certificate below it in the chain.

Why Use an SSL Certificate Decoder Online

The traditional way to decode a certificate is OpenSSL on the command line: openssl x509 -in cert.pem -text -noout. This works but requires OpenSSL to be installed, produces dense raw output that takes time to read, and isn't available on Windows machines without additional tools. A browser-based decoder shows the same information formatted as a readable table, is available immediately on any device, and requires no installation.

DevOps engineers verifying certificates during deployment benefit from the faster workflow. Security auditors reviewing certificate configurations benefit from not needing to install tools on client machines. Developers working on TLS configuration for the first time benefit from the readable field labels rather than the raw ASN.1 output that OpenSSL produces. Anyone who receives a certificate file from a CA and needs to verify it before installing it will find the decoder faster than setting up a command-line environment for a single check.

Frequently Asked Questions about SSL Certificate Decoder

Yes. All decoding happens in your browser using the ASN.1 and PKI.js libraries. Your certificate is never uploaded or transmitted to any server. Certificates contain only public information — the public key, domain names, and issuer details — so there is no private data in a certificate file. The private key is a separate file and is never part of the certificate itself.

The tool accepts PEM format — base64-encoded certificate data wrapped in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- headers. If you have a DER binary file (.der, .cer, .crt), use the SSL Certificate Format Converter to convert it to PEM first. If the certificate was issued by a CA as a chain file, each certificate in the chain is a separate PEM block — paste one at a time to decode each individually.

In Chrome: click the padlock icon in the address bar → Connection is secure → Certificate is valid → Details tab → Export. This downloads the certificate as a .crt file. Open it in a text editor — if it starts with -----BEGIN CERTIFICATE-----, it's already PEM format and can be pasted here. Alternatively, use the OpenSSL command: openssl s_client -connect yourdomain.com:443 < /dev/null | openssl x509 -out cert.pem.

Modern browsers require Subject Alternative Names for domain validation. A certificate with no SANs will fail in Chrome, Firefox, and Safari even if the Common Name matches the domain. CA/Browser Forum rules (effective 2017) require all publicly trusted certificates to include SANs. If you see a certificate with no SANs, it was either issued before 2017 or is self-signed — it won't be trusted by modern browsers without manual installation.

A leaf certificate (also called an end-entity certificate) is issued directly to a domain and is what browsers verify. An intermediate certificate is issued by a root CA to another CA, which then issues leaf certificates — it's part of the trust chain but not the certificate your domain is using directly. When you decode a certificate, the issuer field tells you which entity signed it. Leaf certificates have an issuer that's typically an intermediate CA; intermediate certificates have an issuer that's either another intermediate or the root CA.

Yes, completely free. No account, no sign-up, and no usage limits. You can decode as many certificates as you need. Because the decoder runs entirely in your browser using open-source ASN.1 and PKI.js libraries, there are no API costs and no premium tier.