Certificate decoder: read PEM and DER certificate fields

Inspect certificate subject, issuer, validity, SANs and extensions, and distinguish a decoded certificate file from a trusted live HTTPS connection.

Web & TLS

Open Certificate Decoder →

Choose the certificate you want to inspect

Paste one PEM certificate or select a supported PEM/DER file in Certificate Decoder. Decode each certificate separately if you have a chain bundle. The result describes the supplied certificate and does not confirm that a website currently uses it. Keep the filename or source with your notes so a later comparison does not accidentally mix an old certificate with a new deployment.

Read identity, names and dates together

The subject describes the certificate identity and the issuer identifies the signing issuer by name. Subject alternative names indicate the names or addresses represented in that extension. Validity dates give a time window, but being inside that window is not proof of trust. Check all fields relevant to the intended service; a certificate can be current and still be inappropriate for the hostname.

Distinguish different identifiers

The serial number identifies a certificate within the issuer’s scope. A certificate fingerprint identifies the encoded certificate, while a SHA-256 public-key pin identifies the SubjectPublicKeyInfo encoding. Certificates renewed with the same key can therefore have different certificate fingerprints while retaining the same public-key pin. Use the identifier appropriate to the comparison instead of assuming that every hash means the same thing.

Review extensions and then validate the deployment

Inspect key usage, extended key usage, basic constraints and other available extensions in context. Unknown extension values can appear as encoded hex; a decoded value is not automatically a policy assessment. This tool does not check signatures, chain trust or revocation. Use SSL Certificate for a live endpoint and an appropriate trust-validation workflow when those questions matter. Never treat the decoder’s readable output as a certificate approval.

Worked example

Illustrative example — not a live test
Certificate file: within validity dates
Live website: still presents the previous certificate
Conclusion: the file inspection passed no deployment test; check the live endpoint.

What to check next

  1. Decode one certificate and record its source.
  2. Compare SANs, validity, public key and intended usage.
  3. Check the live endpoint after installing or renewing a certificate.

Common questions

Does a valid date range mean the certificate is trusted?

No. Hostname suitability, signatures, chain trust and other validation checks are separate.

Why does the website show a different certificate?

A different proxy, CDN edge, server or address family may serve the connection, or the new file may not have been deployed.

References

X.509 certificate profile: RFC 5280

OpenSSL certificate inspection