Skip to main content
Start free

Free · no signup

Certificate Decoder

Paste a PEM certificate — or a full chain — and read its subject, SANs, validity, key, signature and fingerprint.

Decoded in memory, never stored or logged — but never paste private keys anywhere, including here.

Want us to fetch the certificate from your server instead? Use the SSL Certificate Checker.

What’s actually inside a certificate

A TLS certificate is a small, signed statement: this public key belongs to these names, says this issuer, until this date. Everything the decoder shows above comes from that statement. The subject and SANs are the names the certificate covers — since browsers ignore the CN, the SAN list is the part that actually matters. The validity window says when the promise starts and expires. The public key is what your server proves possession of during the handshake, and the issuer’s signature is what makes anyone believe any of it.

Certificates come in three roles. The leaf is your certificate — the one with your domain in it. It is signed by an intermediate CA, which is in turn signed by a root that ships inside browsers and operating systems. Clients only have the roots, so your server must send the leaf and every intermediate, in order — leaf first, then each certificate that issued the one before it. Forget the intermediate and Chrome on your laptop may quietly repair the chain while a payment provider’s strict client fails hard. Paste your full chain above and the decoder tells you whether each link really signs the previous one — the same check our SSL certificate monitoring guide recommends automating.

The days-remaining chip deserves more respect than it gets. Certificate lifetimes have been shrinking for a decade — from five years, to two, to 398 days, and the industry has now agreed on 47-day certificates. That kills manual renewal for good: at 47 days, a renewal that silently fails eats your entire buffer in a sprint or two. Automation helps but doesn’t absolve you — Let’s Encrypt renewals fail for mundane reasons (moved DNS, broken webroot, firewalled port 80) and nobody notices until browsers do.

The red flags matter too: a SHA-1 or MD5 signature means the certificate can be forged by anyone with enough compute — browsers stopped accepting SHA-1 in 2017 — and an RSA key under 2048 bits is within factoring reach. Neither should exist on anything reachable from the internet in 2026. If you’d rather never think about any of this again, CompleteStatus watches your certificates continuously — expiry countdown, chain validity and weak crypto included — and alerts you weeks before a deadline becomes an outage.

Frequently asked questions

PEM is the text encoding almost every server uses for X.509 certificates: the binary (DER) certificate, base64-encoded between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" lines. Files ending .pem, .crt or .cer usually contain one certificate — or several stacked blocks forming a chain. This decoder reads any of those.

Certificates are public by design — your server hands its certificate to every visitor before encryption even starts, so pasting one reveals nothing new. This tool also decodes entirely in memory and never stores or logs what you paste. Private keys are the opposite: never paste a private key into ANY website, including this one. If you ever have, treat that key as compromised and rotate it.

Run: openssl x509 -in certificate.pem -text -noout — that prints the subject, issuer, validity, SANs, key and signature details in your terminal without anything leaving your machine. This page shows the same fields, just friendlier and with weak-crypto flags.

Servers must send the leaf certificate first, then the intermediate that issued it, then (optionally) the next intermediate up. Many clients tolerate a shuffled chain, but plenty — older Androids, curl builds, strict libraries — do not, and fail with trust errors. Paste your full chain here and the decoder checks that each certificate is really issued by the next one.

A self-signed certificate is signed with its own private key instead of a CA's: its subject and issuer are identical and its signature verifies against its own public key. Root CA certificates are legitimately self-signed; a self-signed certificate on a public website triggers browser warnings because no trusted third party vouches for it.