Certificate decoder

What you see when you decode a certificate

Paste the text that starts with -----BEGIN CERTIFICATE-----, or several certificates one after another, and press Decode. The first thing on the page is a plain answer: how long the certificate has left, who it was issued to and by whom, and whether it is a CA. Below it are the names it covers, the dates, the key and its strength, and the subject and issuer with the code of each part beside its name.

Tabs under the answer hold the details people go looking for. Fingerprints are the SHA-256 and SHA-1 hashes of the whole certificate, plus the serial number and the SHA-256 of the public key, which is the value you use to pin a key. Extensions are listed one by one with a sentence in plain English before the raw value. Checks lists the problems we found, each with the rule it comes from.

Checking a chain

A server should send its own certificate first, then each intermediate that signed the one before it. Paste them all and the page draws the chain, leaf first, with the validity of each link. If the certificates came in another order, it says so and shows the right one. If the last certificate names an issuer that is not in your paste, a dashed box marks the gap: that is normal for a root, because browsers already have it.

Chains are linked by name and, when both sides carry them, by key identifier. We do not check that each signature is mathematically valid, and we do not decide whether a root is trusted. To see what a live server sends, use the SSL checker.

What the checks look for

• Validity longer than the CA/Browser Forum allows for the date it was issued (398 days, then 200 from March 2026, and shorter later).
• A common name that is missing from the subject alternative names, or no subject alternative names at all.
• An RSA key under 2048 bits, an unusual curve, or a key that matches the ROCA fingerprint (CVE-2017-15361).
• A SHA-1 or MD5 signature, a very short serial number, a missing extended key usage, or no embedded log receipts.

Your paste stays with you, and never paste a private key

With JavaScript on, the certificate is decoded by your browser and nothing you paste is sent to us. Without JavaScript the form cannot decode it for you, so it sends the text to our server in the address of the request, the server decodes it and keeps no copy. Certificates are public by design, so that is rarely a problem, but use the JavaScript version for anything you would rather keep private.

A certificate never contains a private key. If a PRIVATE KEY block is in the box, we clear it, read nothing and tell you to replace the key if it was ever shared. To check a certificate, paste the certificate only.

The same thing in a terminal

Every result shows the matching command, so you can confirm what you see with a tool you already trust. For a single certificate it is:

openssl x509 -in cert.pem -noout -text
openssl x509 -in cert.pem -noout -fingerprint -sha256