Certificate Decoder: Read SSL Certificate Details

An SSL certificate looks like an unreadable block of Base64 text. But inside that encoded data is a precise set of fields that control what domain it covers, who issued it, when it expires, and what cryptographic algorithms it uses. Decoding an SSL certificate lets you verify all of this before installing it on a server — or audit any certificate you encounter on the web.

What Is Certificate Decoding?

SSL certificates are encoded in a format called DER (Distinguished Encoding Rules) and then Base64-encoded for text transport — this format is called PEM (Privacy Enhanced Mail). When you decode a certificate, you convert it from the encoded text back into human-readable fields.

Every SSL certificate is an X.509 certificate — a standard format maintained by the ITU-T. The fields inside follow this standard exactly, which is why any decoder tool (including our Certificate Decoder) can read any certificate issued by any CA worldwide.

Key Fields Inside an SSL Certificate

Version

Modern certificates are X.509 version 3. This version introduced extensions such as Subject Alternative Names, which allow a single certificate to cover multiple domains.

Serial Number

A unique identifier assigned by the CA. Used to track the certificate and can be used to revoke it if compromised. The serial number is part of the Certificate Revocation List (CRL) and OCSP records.

Issuer

Identifies the Certificate Authority that signed and issued the certificate. This includes the CA's Organization name (DigiCert Inc, Let's Encrypt, Sectigo Limited), Country, and Common Name. Browsers verify this against their trust store — if the issuer is not trusted, the certificate is rejected.

Validity Period

Two timestamps: Not Before (issue date) and Not After (expiry date). As of March 2026, Google has enforced a maximum certificate validity of 200 days for publicly trusted certificates. Check this field to know exactly when a certificate expires — crucial for renewal planning.

Subject

The identity the certificate is issued to. For DV certificates, this is just the domain (CN). For OV and EV certificates, this includes the Organization name, Locality, State, and Country. EV certificates previously displayed the organization name in the browser address bar (the "green bar") — browsers removed this display, but the field is still present in the certificate.

Subject Alternative Names (SANs)

The list of all domains and subdomains this certificate is valid for. This is the field browsers actually use to determine if a certificate covers the domain being visited — the Common Name alone is no longer sufficient per modern browser requirements. A certificate for example.com that does not list www.example.com in SANs will show a domain mismatch warning on www.

Public Key

The RSA or ECDSA public key embedded in the certificate. The matching private key must be held by the server. The key size (2048-bit RSA, 4096-bit RSA, P-256 ECDSA, etc.) is shown here. Use the Certificate Key Matcher to verify your server holds the matching private key.

Signature Algorithm

Specifies how the CA digitally signed the certificate. Modern certificates use SHA-256 with RSA (sha256WithRSAEncryption) or SHA-384 with ECDSA. SHA-1 signed certificates are rejected by all modern browsers — if you see SHA-1 here, the certificate is insecure and must be replaced.

Extensions

X.509 version 3 introduced extensions that carry additional information:

• Key Usage — what the public key can be used for (digital signature, key encipherment)
• Extended Key Usage — specific uses such as TLS server authentication
• Basic Constraints — whether this is a CA certificate (can it sign other certificates)
• CRL Distribution Points — where to check if the certificate has been revoked
• Authority Information Access — OCSP endpoint URL and issuer certificate URL

How to Decode a Certificate Using Our Free Tool

1. Open the Certificate Decoder.
2. Paste your certificate text — the full PEM block including -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.
3. Click Decode Certificate.
4. All fields are displayed in a readable table: validity dates, issuer, subject, SANs, key details, and extensions.

To decode via OpenSSL command line:

openssl x509 -in certificate.crt -text -noout

When Should You Decode a Certificate?

• Before installing — verify the CA issued the certificate for the correct domain with the right SANs
• After installation — cross-reference with what the SSL Checker shows live on the server
• When troubleshooting — diagnose domain mismatch, wrong SAN, or expired certificate issues
• Security auditing — inspect any certificate on any domain you are reviewing
• Before converting formats — confirm you have the right certificate file before using the SSL Converter

Certificate Chain: Root, Intermediate, and Leaf Certificates

A complete SSL certificate deployment actually involves three certificates in a chain:

1. Root certificate — issued by the CA and pre-installed in browsers and operating systems
2. Intermediate certificate — issued by the root CA, used to sign end-entity certificates
3. Leaf (end-entity) certificate — your actual domain certificate, signed by the intermediate

When you decode a certificate, you are decoding the leaf certificate. The intermediate and root certificates are part of the trust chain that browsers validate. If the intermediate is missing from your server configuration, browsers cannot verify trust even if the leaf certificate is valid.

Frequently Asked Questions

Can I decode a certificate directly from a live website?

Yes. In any browser, click the padlock icon in the address bar, then select "Certificate" or "Connection is secure → Certificate is valid." This shows the decoded certificate fields directly. Our online tool lets you decode a certificate file you have locally, not from a live URL.

What is the difference between a certificate and a certificate chain?

A certificate is your single end-entity certificate. A certificate chain bundles your certificate together with the intermediate certificate(s) into one PEM file. When installing SSL, servers typically need the full chain, not just the end-entity certificate.

My certificate says it is valid for example.com but not www.example.com — how do I fix this?

You need to reissue the certificate with both example.com and www.example.com listed as Subject Alternative Names. Generate a new CSR with both domains and request a reissue from your CA.

Can I decode a DER format certificate?

DER is the binary format of the same data. Convert it to PEM first: openssl x509 -in certificate.der -inform DER -out certificate.pem -outform PEM. Then paste the PEM into the decoder tool.