Skip to main content
Examples

PEM, base64 or hex DER, or a PKCS #7 bundle. Several blocks are read as a chain.

PEM or DER. Its content appears in the field above.

Paste a PEM certificate, CSR, or public key, or open a certificate file. Several blocks at once are read as a chain.

What Is a Certificate Decoder?

The certificate decoder reads X.509 certificates, certificate signing requests (CSRs), and public keys in PEM, DER, or PKCS #7 form and shows every field: subject, issuer, SANs, validity, serial number, key, signature algorithm, extensions, signed certificate timestamps, and fingerprints. Paste a whole chain and it puts the certificates in order from the leaf, checks each signature with your browser's Web Crypto API, and names any issuer that is missing. Each warning cites the RFC or CA/Browser Forum rule it applies.

How to Use the Certificate Decoder

  1. Paste one or more PEM blocks, or open a certificate file (.pem, .crt, .cer, .der, .csr, .p7b).
  2. When the input holds more than one object, pick the one to show under Show.
  3. Read the warnings first, then the fields.
  4. Copy the fingerprint, the PEM, or the public key, or copy a link that reopens the certificates. A CSR is never put in a link.

How It Works

RFC 5280 profiles X.509 certificates for use in the internet. The signature of a certificate is computed over the DER encoding of its to-be-signed part, which holds the version, serial number, issuer, validity, subject, public key, and extensions. The decoder checks each signature over exactly those bytes with the Web Crypto API in your browser.

A certificate signing request (CSR, RFC 2986) has three parts: the request information, a signature algorithm identifier, and a signature over the request information made with the subject's private key. A CSR carries requested names in the extensionRequest attribute. A challengePassword attribute holds a password for revocation requests, so the decoder says that one is present and never shows its value.

PEM text (RFC 7468) is base64 between a -----BEGIN line and an -----END line, and the END line carries the same label as the BEGIN line. One file may hold several certificates, and text outside the lines is allowed, so a chain bundle or a pasted log excerpt decodes as it is. The decoder also reads DER files, bare base64 or hex, and PKCS #7 bundles (.p7b). A block labeled as a private key stops the decoding.

Validity dates through 2049 are encoded as UTCTime with a two-digit year, and dates from 2050 on as GeneralizedTime. A two-digit year of 50 or more means 19YY, and one below 50 means 20YY. The validity period runs from notBefore through notAfter inclusive, and the CA/Browser Forum Baseline Requirements count any part of a day as a whole day.

In TLS the server's own certificate comes first, and each following certificate should directly certify the one before it (RFC 8446 section 4.4.2). The decoder finds the leaf, follows each issuer by name and key identifier, verifies every link, and shows the expected order. A server may leave out the root certificate when clients already have it. When an issuer is missing, the decoder shows the CA Issuers URL from the authority information access extension, which points to certificates issued to that issuer.

A Certificate Transparency log answers a submission with a signed certificate timestamp (SCT). The SCT is the log's promise to add the certificate to its Merkle tree within the maximum merge delay. SCTs are carried in certificate extension 1.3.6.1.4.1.11129.2.4.2. The decoder lists each SCT's log ID, the SHA-256 hash of the log's public key, and its timestamp in milliseconds. It does not verify SCT signatures.

Warnings for publicly trusted TLS certificates follow version 2.3.1 of the CA/Browser Forum Baseline Requirements: at most 398 days of validity for certificates issued before 2026-03-15, 200 days until 2027-03-15, 100 days until 2029-03-15, and 47 days after that; RSA keys of at least 2048 bits; serial numbers with at least 64 bits of CSPRNG output; a common name taken from the SAN extension; and no SHA-1 from 2026-09-15.

OpenSSL Equivalents

TaskCommand
Print every field of a certificateopenssl x509 -in cert.pem -noout -text
SHA-256 fingerprint of the DER encodingopenssl x509 -sha256 -in cert.pem -noout -fingerprint
The certificate's public key as PEMopenssl x509 -in cert.pem -noout -pubkey
Print a CSR and verify its self-signatureopenssl req -in req.pem -text -verify -noout
The public key of a private keyopenssl pkey -in key.pem -pubout
Verify a chain with untrusted intermediatesopenssl verify -CAfile root.pem -untrusted int.pem leaf.pem
Certificates in a PKCS #7 bundle as PEMopenssl pkcs7 -in bundle.p7b -print_certs
Convert a certificate from PEM to DERopenssl x509 -in cert.pem -inform pem -out cert.der -outform der

Checks and Their Rules

CheckRuleSource
RSA key under 2048 bitsThe Baseline Requirements require an RSA modulus of at least 2048 bits.CA/Browser Forum Baseline Requirements 2.3.1, section 6.1.5
SHA-1 signatureThe Baseline Requirements sunset all remaining use of SHA-1 in certificates and CRLs on 2026-09-15.CA/Browser Forum Baseline Requirements 2.3.1, section 7.1.3.2.1
Serial number zero, negative, or over 20 octetsRFC 5280 requires the serial number to be a positive integer of at most 20 octets.RFC 5280 section 4.1.2.2
Serial number under 64 bitsThe serial number has fewer than 64 bits. The Baseline Requirements require at least 64 bits of CSPRNG output in the serial number of a publicly trusted certificate.CA/Browser Forum Baseline Requirements 2.3.1, section 7.1
Unrecognized critical extensionRFC 5280 says a certificate-using system must reject a certificate with a critical extension it does not recognize.RFC 5280 section 4.2
keyCertSign without the cA flagRFC 5280 does not allow the keyCertSign bit when the cA flag in basic constraints is not set.RFC 5280 section 4.2.1.9
Signature algorithm fields differRFC 5280 requires the outer signatureAlgorithm field to hold the same algorithm identifier as the signature field inside the certificate.RFC 5280 section 4.1.1.2
Common name not among the SANsThe Baseline Requirements say that a common name, if present, must contain a value taken from the subject alternative name extension.CA/Browser Forum Baseline Requirements 2.3.1, section 7.1.4.3
Country not two lettersRFC 5280 defines countryName as a PrintableString of exactly two characters.RFC 5280 appendix A.1
Wrong time type for a validity dateA validity date uses the wrong time type. RFC 5280 requires UTCTime for dates through 2049 and GeneralizedTime for dates in 2050 or later.RFC 5280 section 4.1.2.5
Chain not in path orderIn TLS the server's own certificate comes first, and each following certificate should directly certify the one before it.RFC 8446 section 4.4.2
Issuer not marked as a CARFC 5280 uses the cA flag in basic constraints to say whether a public key may be used to verify certificate signatures.RFC 5280 section 4.2.1.9
Issuer key usage without keyCertSignRFC 5280 sets keyCertSign when the public key is used to verify signatures on certificates.RFC 5280 section 4.2.1.3
Path longer than the issuer allowsThe path length constraint is the maximum number of intermediate certificates that may follow a CA certificate in a valid path; self-issued certificates do not count.RFC 5280 section 4.2.1.9
CSR signature does not verifyA CSR is signed with the subject's private key. A signature that does not verify means the request was changed after signing or is damaged.RFC 2986 section 3
PrecertificateThis is a precertificate. It carries the critical poison extension from RFC 6962, which keeps a standard X.509 client from validating it.RFC 6962 section 3.1

Standards

Scope

What It Checks

  • +Decodes PEM, DER, and PKCS #7 bundles holding certificates, CSRs, and public keys.
  • +Shows subject, issuer, SANs, validity, serial number, key type and size, signature algorithm, and SHA-1 and SHA-256 fingerprints.
  • +Decodes key usage, extended key usage, basic constraints, key identifiers, AIA, CRL distribution points, certificate policies, TLS feature, and SCTs.
  • +Checks certificate and CSR signatures with Web Crypto (RSA, RSA-PSS, ECDSA, Ed25519).
  • +Orders a chain from the leaf, checks each link, and names a missing issuer.
  • +Compares the public key of a certificate with a CSR or public key.
  • +Flags expiry, validity over the CA/Browser Forum limit, small RSA keys, SHA-1 signatures, and RFC 5280 encoding problems.

What It Does Not Check

  • -It does not check trust against any browser or operating system root store.
  • -It does not check revocation (OCSP or CRL) or fetch anything from the network.
  • -It does not verify SCT signatures or name Certificate Transparency logs.
  • -It does not accept private keys or PFX/PKCS #12 files.
  • -It does not decode CRLs.

Defensive Use

Certificate Transparency logs do not detect misissued certificates on their own; domain owners and other interested parties monitor the logs and act when a certificate was issued wrongly (RFC 6962). Decoding a certificate found in a log or on a server shows its names, issuer, and validity, so they can be compared with what the organization requested. RFC 5280 requires software to reject a certificate with a critical extension it does not recognize, and the CA/Browser Forum Baseline Requirements cap validity periods and set a minimum RSA key size, so the same checks find certificates that clients may refuse, before those certificates are deployed.

Frequently Asked Questions

What is a Certificate Decoder?→

The certificate decoder reads X.509 certificates, certificate signing requests (CSRs), and public keys in PEM, DER, or PKCS #7 form and shows every field: subject, issuer, SANs, validity, serial number, key, signature algorithm, extensions, signed certificate timestamps, and fingerprints. Paste a whole chain and it puts the certificates in order from the leaf, checks each signature with your browser's Web Crypto API, and names any issuer that is missing. Each warning cites the RFC or CA/Browser Forum rule it applies.

What is the Certificate Decoder used for?→

Checking a certificate or CSR before it goes to a CA or a server: confirming the names, key size, and expiry date, matching a certificate to its CSR or public key, and finding out why a TLS chain is incomplete or in the wrong order.

Is my data sent anywhere?→

No. The Certificate Decoder runs in your browser. What you enter stays on this page and is not sent to ImmunitySec or anyone else.

How is the Certificate Decoder used defensively?→

Certificate Transparency logs do not detect misissued certificates on their own; domain owners and other interested parties monitor the logs and act when a certificate was issued wrongly (RFC 6962). Decoding a certificate found in a log or on a server shows its names, issuer, and validity, so they can be compared with what the organization requested. RFC 5280 requires software to reject a certificate with a critical extension it does not recognize, and the CA/Browser Forum Baseline Requirements cap validity periods and set a minimum RSA key size, so the same checks find certificates that clients may refuse, before those certificates are deployed.

What is the difference between PEM and DER?→

DER is the binary encoding of a certificate. PEM carries the same data as base64 text between a -----BEGIN CERTIFICATE----- line and an -----END CERTIFICATE----- line (RFC 7468), so it can be pasted into a form or an email. The file name extension does not decide the form. The decoder reads the content of the file.

How do I decode a certificate with OpenSSL?→

openssl x509 -in cert.pem -noout -text prints the certificate in text form. openssl x509 -sha256 -in cert.pem -noout -fingerprint prints the SHA-256 digest of the DER encoding of the whole certificate, which OpenSSL calls the fingerprint. For a CSR, openssl req -in req.pem -text -verify -noout prints the request and verifies its self-signature.

Is it safe to paste a certificate into a website?→

A certificate holds no secret. Certificate Transparency logs are public. Anyone can submit certificate chains to them, and anyone can audit them (RFC 6962). This decoder runs in your browser and sends nothing. Never paste a private key into any website.

Why does my certificate chain fail?→

Paste the full chain the server sends. TLS expects the server's certificate first, and each following certificate should directly certify the one before it (RFC 8446). The decoder shows whether the order is right, whether each link's signature verifies, and the CA Issuers URL of an issuer that is missing. It does not check trust in a root store or revocation.

How long can a TLS certificate be valid?→

Under the CA/Browser Forum Baseline Requirements, publicly trusted TLS certificates issued on or after 2026-03-15 and before 2027-03-15 must not be valid for more than 200 days. The limit is 100 days from 2027-03-15 and 47 days from 2029-03-15. Before 2026-03-15 the limit was 398 days.

What is an SCT in a certificate?→

A signed certificate timestamp (SCT) is a Certificate Transparency log's promise to add a certificate to its Merkle tree within a fixed time, the maximum merge delay (RFC 6962). Each SCT names its log by the log ID, the SHA-256 hash of the log's public key.

Can I check a private key against a certificate here?→

Not with the private key itself. Derive the public key on your own machine with openssl pkey -in key.pem -pubout, which outputs only the public components, and paste it next to the certificate. The decoder then says whether the two public keys are the same.

What is the challenge password in a CSR?→

RFC 2985 defines challengePassword as a password with which an entity may request revocation of its certificate. Its meaning is left to certificate issuers. The decoder reports that the attribute is present and never shows or copies its value.