Request a trial
Menu
Products
Solutions
ERP
Authentication
Apps
LearnDocsWhy SSOGENRequest a trial

SSOGEN / Free tools / Certificate Decoder: Read an X.509 Certificate in Your Browser

Free tool

Certificate Decoder: Read an X.509 Certificate in Your Browser

This free certificate decoder reads an X.509 certificate (a TLS server certificate, a SAML signing certificate or a token-signing certificate) and shows who it is for, when it expires, which key it holds and its SHA-256 and SHA-1 fingerprints, with nothing uploaded.

Plan a trial

Decode an X.509 certificate here

Paste one certificate, or several in sequence, as PEM (the text between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----) or as plain base64.

For a SAML signing certificate, paste the value of the X509Certificate element from the metadata; the BEGIN and END lines are not needed.

  • Load an Acme chain. It shows a leaf, an issuing CA and a root.
  • Load the chain in the wrong order. It shows what a broken bundle looks like.

PEM (-----BEGIN CERTIFICATE----- or BEGIN CERTIFICATE REQUEST) or plain base64. Paste several certificates one after another to check a whole chain.

Private by design. Decoding happens in this page and nothing is uploaded. A certificate and a CSR hold only public information, but never paste a private key into any web page: this tool refuses it.

Free, in your browser. No sign-up, no limit, nothing uploaded.

A certificate contains only public information. If you paste a private key by mistake, the tool refuses it, but never paste one into a web page.

If you hold a certificate signing request instead, use the CSR decoder to check it before you send it to a certificate authority. This page is for a certificate that has already been issued.

What an X.509 certificate holds

An X.509 certificate binds a name to a public key and is signed by the party that vouches for that binding.

A certificate decoder (also called an SSL or TLS certificate decoder, an X.509 decoder or a PEM decoder) turns the base64 blob into readable fields. With those fields you can confirm three things:

  • that this is the right certificate
  • when it expires
  • whether the systems that depend on it will keep working

This decoder is free, runs in your browser and makes no network request when you decode.

Reading a certificate field by field

Work through the output from the top. The middle column of the table says what to check; the last column names the mistake that field most often exposes.

Field What to check The mistake it exposes
Subject Organization and common name match the owner you expect. A renewed certificate issued to the wrong team or environment.
Issuer The signer is the CA you expect. A test or old CA left in place after a migration.
Valid from, valid until Today falls inside the window; days left is comfortable. An expiry that nobody owns.
Serial number Unique per issuer; useful to tell two certificates with one name apart. Replacing a certificate and not noticing it is the old one.
Public key Type and size: RSA 2048 or more, or EC P-256 and up. A 1024-bit key from an old generator.
Signature algorithm SHA-256 or stronger. SHA-1 or MD5, which many clients refuse.
Names (SAN) The hostnames or identifiers it covers. Name mismatch; a wildcard used at the wrong depth.
Key usage What the key may do, such as digital signature. A key not allowed to do what you are asking of it.
Extended key usage The purposes it is limited to, such as server authentication. A certificate with the wrong purpose on a server.
CA flag and path length Whether it may sign other certificates. A leaf that is secretly a CA, or a CA that cannot issue your intermediate.
Key identifiers The key’s own ID and its issuer’s key ID. Matching a certificate to its issuer when two share a name.
SHA-256 and SHA-1 fingerprints A hash of the whole certificate. Two people comparing different files.

RFC 5280 (read 2026-10-09) defines these fields.

Section 4.1.2.2 says a serial number must be a positive integer of no more than 20 octets, unique for each certificate a given CA issues.

For that reason the decoder shows the serial in hexadecimal with colons, not as a short number.

Fingerprint and thumbprint

A fingerprint is a hash of the certificate’s complete DER encoding.

  • Definition. OpenSSL’s documentation (read 2026-10-09) describes it as the digest of the DER-encoded version of the entire certificate, with SHA-1 as the default digest for the -fingerprint option.
  • Sensitivity. Changing one byte changes the value.
  • Comparison. To confirm that two parties hold the same certificate, compare the SHA-256 fingerprint, not the subject.
  • Thumbprint. The word is used loosely. Many tools use it for the SHA-1 fingerprint, and a thumbprint pasted with no hash named could be either one, so confirm the algorithm on both sides before comparing.
  • JWK thumbprint. As shown by the JWKS inspector, it is a hash of a public key, not of a certificate, and does not match a certificate fingerprint even for the same key.

The decoder shows both SHA-256 and SHA-1. Use SHA-256 for new comparisons and SHA-1 only for systems that still require it.

As a fingerprint, SHA-1 is only an identifier for matching; the real concern is SHA-1 as a signature algorithm, covered below.

SAML signing certificates: why expiry breaks sign-in

In SAML, the identity provider signs each assertion with its private key. The application verifies the signature with the public certificate it took from the identity provider’s metadata.

It usually trusts that certificate directly rather than through a public CA, so the expiry date inside the certificate is the deadline.

After that date, a correctly configured application can reject every assertion. Users get a sign-in error although nothing else changed. For the message format, see what is SAML and the SAML assertion explainer.

Most failures happen during rollover. Replacing the signing certificate affects both sides.

Once the identity provider signs with the new key, every application must already hold the new certificate. Any application that does not will fail.

The safe order:

  1. Publish the new certificate beside the old one.
  2. Wait until every application has picked it up.
  3. Only then sign with the new key.

Before you start, decode both certificates and record the old and new SHA-256 fingerprints. During the change you can then tell which one each application holds.

Three tools help:

Token-signing certificates in other protocols behave the same way. A relying party that pins or caches a signing certificate fails on the day it expires.

Put the expiry date in a calendar owned by a named person.

TLS certificates: names, usage and chain order

For a web server, three checks matter: the SAN, the extended key usage and the chain. Browsers match the host against the SAN, so the hostname users type must be listed. A wildcard like *.apps.acme.example covers exactly one label:

  • finance.apps.acme.example matches.
  • a.b.apps.acme.example and apps.acme.example do not.

Type a hostname in the box under the text area and the decoder applies that rule.

A certificate on a web server should list server authentication in its extended key usage. If the extension is present but names only other purposes, a client may refuse the certificate.

Chain order and the missing intermediate

A server should send its own certificate first, then the intermediate that signed it, and so on up the chain, without the root. These failures are common:

What you see Cause Fix
Works in one client, fails in another The server sent the leaf only, and the client has no other source for the intermediate. Send the intermediate with the leaf.
“Incomplete chain” or “unable to get local issuer certificate” The bundle has a gap, or the intermediate is not the one that signed the leaf. Decode each certificate and compare the issuer of one to the subject of the next.
Chain verification fails though all certificates are present The bundle is in the wrong order, for example root first. Reorder: leaf, then issuing CA, then any higher intermediate.
Leaf and intermediate have the same subject name Two CAs with one name, from a CA key rollover. Compare the key identifiers: the leaf’s authority key ID must equal the issuer’s subject key ID.

Paste the whole bundle and the decoder checks each adjacent pair:

  • whether certificate 1 was issued by certificate 2
  • whether the signature verifies under that key
  • whether the last certificate is a root

A gap appears as “not issued by certificate 2”. The decoder checks order and gaps. It cannot check whether a client trusts the final issuer, because it does not know your trust store.

Key size, SHA-1 and SHA-256

Key size and signature hash are separate choices.

  • Key. RSA 2048 bits or more, or an EC curve such as P-256. It is what the certificate carries.
  • Signature algorithm. For example sha256WithRSAEncryption. It is how the issuer signed the certificate.
  • Warnings. The decoder warns on an RSA key under 2048 bits and on a SHA-1 or MD5 signature, because many clients refuse those.
  • Scope. Check the signature on the leaf and on each intermediate.
  • EC keys. An EC key shows its curve instead of a bit length: P-256 is 256 bits, P-384 is 384 bits.

EC and RSA sizes are not comparable number for number, so a 256 beside an RSA 2048 does not indicate a weak key.

PEM, DER and base64

All three hold the same certificate:

  • DER is the binary form.
  • PEM is the DER bytes as base64, wrapped between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. This is the form you can paste into a page.
  • Plain base64, like the value inside a SAML X509Certificate element, is the PEM body without the wrapper lines.

The decoder reads PEM and plain base64.

A binary .cer or .crt file is DER. Convert it first with openssl x509 -inform DER -in cert.cer -out cert.pem.

A .pfx or .p12 file also contains a private key, so do not paste it anywhere; extract only the certificate, on your own machine.

Decode a certificate with OpenSSL

The same checks work offline. These options come from the OpenSSL manual pages (read 2026-10-09). The file names are placeholders.

Task Command
Print every field openssl x509 -in cert.pem -noout -text
Subject, issuer, serial openssl x509 -in cert.pem -noout -subject -issuer -serial
Start and expiry dates openssl x509 -in cert.pem -noout -dates
SHA-256 fingerprint openssl x509 -in cert.pem -noout -fingerprint -sha256
SHA-1 fingerprint openssl x509 -in cert.pem -noout -fingerprint -sha1
Names (SAN) only openssl x509 -in cert.pem -noout -ext subjectAltName
Fails if it expires within 30 days openssl x509 -in cert.pem -noout -checkend 2592000
Read a DER file openssl x509 -inform DER -in cert.cer -noout -text
See what a server sends, in order openssl s_client -connect gateway.acme.example:443 -servername gateway.acme.example -showcerts
Verify a leaf through an intermediate openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem

Two notes from the manuals:

  • -checkend takes a value in seconds and exits nonzero if the certificate will have expired by then. 2592000 is 30 days.
  • For -showcerts, OpenSSL says the list is exactly what the server sent, in the order sent, and not a verified chain. That makes it useful for spotting a missing intermediate.

Sources, read 2026-10-09: openssl-x509 and openssl-s_client.

We tested the decoder on a self-signed Acme certificate made with OpenSSL. The SHA-256 and SHA-1 fingerprints, serial, SANs, key usage and extended key usage matched OpenSSL’s output exactly.

Questions about certificate decoders

What is a certificate decoder?
A tool that reads the fields inside an X.509 certificate and shows them in plain form: subject, issuer, validity dates, names, key, signature algorithm, usage and fingerprints. For a quick check, you do not need to read the base64 or run OpenSSL.
How do I decode an X.509 certificate?
Paste the PEM text, or the base64 value, into the box above and select Decode. On your own machine, openssl x509 -in cert.pem -noout -text prints the same fields.
What is the difference between a fingerprint and a thumbprint?
A fingerprint is a hash of the whole DER-encoded certificate. “Thumbprint” often means the SHA-1 fingerprint, but check which hash a tool means before comparing. Prefer SHA-256 for new comparisons.
Why did SAML sign-in stop when a certificate expired?
Applications check assertion signatures against the identity provider’s signing certificate. If it expires, or the provider starts signing with a new key the application does not have yet, the signature check fails and sign-in is rejected. Publish the new certificate beside the old one before switching.
How do I check the SSL certificate chain order?
The server should send the leaf first, then each intermediate in turn. Paste the bundle into the decoder and it reports where one certificate is not issued by the next. With OpenSSL, openssl s_client -connect host:443 -showcerts lists the certificates in the order the server sent them.
Should I use the certificate decoder or the CSR decoder?
Use this page if you hold a certificate. It covers dates, fingerprints, SAML signing certificates and chain order. Use the CSR decoder if you hold a certificate signing request you have not yet sent to a certificate authority.
Can I decode a PEM, .cer or .crt file?
Paste PEM text or plain base64 straight in. A binary .cer or .crt file is DER, so convert it first with openssl x509 -inform DER -in cert.cer -out cert.pem, then paste the result. Do not paste a .pfx or .p12 file, which also contains a private key.
Is it safe to paste a certificate into a web page?
A certificate is public information, and this page decodes it in your browser without sending it anywhere. Never paste a private key. The tool refuses one.

Where to go next