Certificate & PEM decoder

What this tool does

A certificate arrives as a block of Base64 between two lines of dashes, and there is no way to tell anything about it by looking. This decodes it: who it was issued to and by, when it expires, which hostnames it covers, what kind of key it holds, and every extension it carries. Paste a whole chain and each certificate is checked against the next one.

It runs entirely in your browser. That matters more here than for most tools — the alternative is usually pasting a production certificate into someone else’s server, or remembering the openssl invocation, which almost nobody does.

PEM is only the wrapper

The dashes and the Base64 are packaging. Inside is DER, a binary encoding of a structure called ASN.1, and the label between the dashes says which structure to expect:

CERTIFICATE           an issued X.509 certificate
CERTIFICATE REQUEST   a CSR: what you asked a CA for
PUBLIC KEY            a bare key with no identity attached
PRIVATE KEY           the secret half, refused here

The same certificate can also arrive as raw DER in a .cer or .crt file, with no dashes and no Base64. If a file opens as binary noise rather than text, that is what it is; Base64 it first, or export it as PEM.

What is actually in a certificate

The core fields are the same in every certificate ever issued:

• Subject — who the certificate is about. For a website this is now usually just a common name, and often nothing more.
• Issuer — the certificate authority that signed it. Its subject name appears verbatim as the issuer of everything it signs, which is what makes chain checking possible.
• Validity — two absolute instants, always in UTC. This tool shows both and works out how long is left in your browser, since the build machine that generated this page has no idea when you are reading it.
• Serial number — unique per issuer, and the identifier used when a certificate is revoked.
• Signature algorithm — what the issuer signed with, for example SHA-256 with ECDSA.
• Public key — the type, and the size. For RSA that is the bit length of the modulus; for EC it is a property of the named curve, so P-256 is always 256 bits.

One field people expect and no longer find: the subject common name is not what browsers check. It has been ignored for hostname matching for years. What matters is the subject alternative name extension, below.

The extensions that decide whether it works

A certificate can carry any number of extensions. Five of them determine whether it will actually be accepted, and this tool decodes those in full:

• Subject Alternative Name — the hostnames, IP addresses or email addresses the certificate is valid for. This is the field browsers check, and a certificate whose SAN does not list the name you typed will be rejected however correct everything else is.
• Basic Constraints — whether this is a certificate authority, and how many intermediates may sit below it. A leaf certificate marked as a CA, or the reverse, breaks the chain.
• Key Usage — what the key may be used for at all: signing, key encipherment, certificate signing. Marked critical almost always, which means software must reject the certificate rather than ignore a usage it does not understand.
• Extended Key Usage — the purpose: TLS server, TLS client, code signing, email. A certificate without TLS server authentication will not serve a website, and this is a common surprise on certificates issued for something else.
• Subject and Authority Key Identifier — short hashes that let software match a certificate to its issuer quickly when several share a name.

Every other extension is listed with its name where one is known, its OID, and whether it is marked critical. Nothing is silently dropped: an extension this tool does not decode still appears, so you can see that it is there.

Chains, and what "linked" means here

A server almost never sends one certificate. It sends its own plus the intermediates needed to reach a root the client already trusts. The order matters and the file is usually called fullchain.pem:

block 1   leaf          subject: example.com     issuer: Example CA R3
block 2   intermediate  subject: Example CA R3   issuer: Example Root
block 3   root          often omitted, since clients have it already

Each certificate names its issuer, and the next certificate down should have exactly that name as its subject. This tool compares those two names byte for byte and says whether they match. That is the only relationship checkable offline, and it catches the two failures that account for most chain problems: an intermediate left out, and blocks pasted in the wrong order.

Those failures have a characteristic symptom. Desktop browsers often paper over a missing intermediate by fetching it themselves, so the site looks fine on your laptop and fails on a phone, in a mobile app, or from curl. If that describes what you are debugging, paste the full chain here first.

What this tool does not tell you

It does not verify signatures, and it cannot. Checking that a certificate was really signed by its issuer needs the issuer’s public key; deciding whether that issuer should be believed needs a trust store. A pasted file supplies neither. Nor can it check revocation, which requires a network request to the CA.

So "the chain is continuous" here means the names line up, not that the chain is valid. A chain of forged certificates would link perfectly. What the check is good for is finding structural mistakes in your own configuration, which is what people are actually looking at when they paste a chain into a decoder.

Fingerprints, and private keys

The SHA-256 fingerprint is a hash of the whole certificate, and it is what you compare against a value someone quoted you, or against a pin. Note what it identifies: the certificate, not the key inside it. Renewing a certificate for the same key produces a different fingerprint, which is the usual reason a pin breaks at renewal. The SHA-1 fingerprint is shown too because older tools and consoles still print it — for identification only; SHA-1 has no business signing anything.

Private keys are recognised and refused. Nothing pasted here leaves your browser, so the refusal is not about this page: it is that pasting a private key into a web form is a habit worth not forming, and the next site that asks may not be running locally. If you need to check that a key and a certificate belong together, compare the public key from the certificate against the one derived from the key, locally.