All free tools Decoded in memory, never stored

SSL Certificate Decoder

Paste a certificate, a whole chain or a certificate signing request and read every field that matters: names, issuer, dates, key, signature and fingerprints, with a check that the chain is in the right order.

PEM DECODER

Decode a certificate or CSR

.pem .crt .csr
Paste up to 64 KB: one certificate, a fullchain.pem (up to eight certificates) or a CSR. Include the -----BEGIN and -----END lines.
The file is read in your browser and placed in the box above (64 KB maximum). Binary DER files are not supported; convert them with openssl x509 -inform der -in cert.der.

Never paste a private key. A certificate and a CSR are public, but the privkey.pem or .key file is not. If the text contains a private key, this page stops before sending anything.

Decoded on the VPSLake server, in memory only. The text is parsed with OpenSSL for this request and the result is returned to you. Nothing is saved or logged by the tool.

HOW TO USE IT

Decode in three steps

Useful before installing a certificate on a server, when a CA sends you files with unclear names, or to confirm a CSR asks for the right domains.

  1. 1

    Get the PEM text

    On a server with certbot, run sudo cat /etc/letsencrypt/live/example.com/fullchain.pem. For a CSR, open the .csr file you generated. Paste it, or load the file.

  2. 2

    Select Decode

    Each block is read separately. Certificates show their names, issuer, validity, key and fingerprints; CSRs show the subject, requested names and whether the signature checks out.

  3. 3

    Check the details

    Confirm the names cover every host you serve, the dates are right, and in a chain each certificate is signed by the one below it. Copy the result as text for a ticket or your notes.

Which file is which

Certbot keeps four files under /etc/letsencrypt/live/your-domain/. cert.pem is your certificate alone, chain.pem is the intermediate, fullchain.pem is both together, and privkey.pem is the secret key that never leaves the server.

Commercial CAs often send a .crt plus a .ca-bundle. Paste both here to see which is the leaf and whether the bundle actually matches it.

Checking chain order

A chain file should start with your server certificate, followed by the intermediate that signed it, and so on toward the root. When you paste several certificates, the decoder checks each one's signature against the next one's public key and flags any break.

A wrong order or a mismatched intermediate is a common reason a freshly installed certificate shows as untrusted. After fixing the file, test the live server with the SSL Checker.

Reviewing a CSR before you submit it

Generate a CSR on your server with openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr, and keep the key on the server. Before sending the CSR to a CA, check that the common name and subject alternative names list every host you need.

A CSR whose self-signature fails was damaged when it was copied, usually by a missing line or extra characters.

Fingerprints and serial numbers

The SHA-256 fingerprint identifies one exact certificate. Compare it with the output of openssl x509 -in cert.pem -noout -fingerprint -sha256 on your server to confirm the file you installed is the one you expected.

The serial number is what a CA asks for when you want a certificate revoked or reissued.

Keep private keys off the web

A private key lets anyone impersonate your site. Do not paste it into any online tool, chat or ticket. If a key was exposed, issue a new certificate with a new key and revoke the old one, for example with sudo certbot revoke --cert-name example.com followed by a fresh certbot run. This decoder reads certificates and CSRs only and does not check revocation status.

FREQUENTLY ASKED QUESTIONS

SSL Decoder FAQ

Yes. A certificate is public by design: every visitor's browser receives it on every HTTPS connection. The text is decoded in memory on the VPSLake server for this one request and is not saved. The private key is the only part that must stay secret, and the page refuses to send text that contains one.
PEM text: blocks that start with -----BEGIN CERTIFICATE----- or -----BEGIN CERTIFICATE REQUEST-----. A bare Base64 certificate body without the header lines also works. Binary DER, PKCS#7 (.p7b) and PKCS#12 (.pfx) files need converting with openssl first.
Do it on the server so the key never leaves it. Compare openssl x509 -in cert.pem -noout -pubkey | openssl sha256 with openssl pkey -in privkey.pem -pubout | openssl sha256. If the two hashes are identical, the certificate and key belong together.
Either the certificates are in the wrong order, or the intermediate in the file is not the one that issued your certificate, for example an old bundle left over from a previous CA. Put your server certificate first and use the intermediate your CA supplied with this certificate.
They describe how the CA checked the request. Domain Validated (DV) proves control of the domain only; Let's Encrypt certificates are DV. Organization Validated (OV) and Extended Validation (EV) also verify the company behind it. Browsers encrypt all three the same way. The decoder reads the level from the certificate's policy identifiers when the CA includes them.
Use the SSL Checker for that: it connects to the site and shows the certificate and chain it serves. To copy the PEM text yourself, run openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null.