SSL Certificate Decoder
Paste a certificate, a chain or a CSR: every field decoded, every problem explained.
Certificate, chain or CSR
One certificate, a whole chain, a PKCS#7 bundle or a CSR — decoded as you paste. A private key pasted by mistake is skipped, never read.
Checks that the certificate — or the CSR — covers this name or IP address, wildcards included.
Decoded
Paste a certificate, or choose a file, to see:
- who it is for, who issued it, and every name it covers;
- when it expires, its key, signature and fingerprints;
- every extension, decoded — and its Certificate Transparency SCTs;
- whether the chain is complete, in order and correctly signed.
Nothing is uploaded: the decoding and every check run in this page.
Chain
About the SSL Certificate Decoder
Paste a certificate — or a whole chain, a PKCS#7 bundle (.p7b) or a certificate signing request — and see everything in it: subject and issuer, every Subject Alternative Name, the validity dates and days left, the key type and size, the signature algorithm, SHA-256 and SHA-1 fingerprints, and each extension decoded (key usage, extended key usage, basic constraints, CA Issuers and OCSP addresses, CRL distribution points, certificate policies, name constraints and more).
It then checks what can go wrong: expired or not-yet-valid certificates, weak keys and SHA-1 or MD5 signatures, names browsers will not accept, a chain in the wrong order or missing its intermediate, and certificates whose signatures do not verify — each finding says which rule it comes from (RFC 5280, the CA/Browser Forum Baseline Requirements) and how to fix it. Embedded Certificate Transparency SCTs are matched to their logs and their signatures verified (RFC 6962). Everything runs in your browser; nothing is uploaded.
How to use it
- Paste the certificate text (from
-----BEGIN CERTIFICATE-----to-----END CERTIFICATE-----), several of them for a chain, or a CSR — or choose a.pem,.crt,.cer,.der,.p7bor.csrfile. Results appear as you paste. - Optionally type the host name the certificate is for (for example
www.example.com) to check that it covers it, wildcards included. - Read the summary, then the findings: Problem and Warning items say what to change; Note and OK items explain what was checked.
- Open each certificate for its full details and extensions. Copy or download it as PEM or DER, and, for a chain, download it in the correct order.
- Press Copy report to paste everything into a support ticket or chat.
Examples
intermediate.pem, then server.pem, then root.pem
WARNING Certificates are out of order — the server certificate must come first NOTE The root certificate is included → Download the chain in the right order (leaf, intermediate, root)
nginx needs the server certificate first in the ssl_certificate file, followed by its intermediates; in the wrong order it refuses to start with “key values mismatch” (nginx documentation). The root can be left out.
Host name: shop.example.com · certificate for *.example.com and example.com
Covered by DNS:*.example.com
A wildcard covers exactly one level: shop.example.com yes, example.com and a.shop.example.com no.
-----BEGIN CERTIFICATE REQUEST----- …
OK Signature valid NOTE Organizational unit (OU) requested — public CAs no longer include it NOTE Challenge password present — stored in plain text
Common uses
- Finding out when a certificate expires and which names it covers before renewing it.
- Fixing “incomplete chain” and “unable to get local issuer certificate” errors by checking the order and completeness of fullchain.pem.
- Checking a CSR from a server or a colleague before submitting it to a certificate authority.
- Comparing fingerprints and public-key pins to match a certificate with a key, a pin or a monitoring alert.
- Reading certificates from Kubernetes secrets, JSON configs and .p7b downloads, which are pasted here as they are.
What the main fields mean
- Subject / Issuer: who the certificate is for, and which certificate authority signed it. The issuer of one certificate is the subject of the next one up the chain.
- Subject Alternative Names (SANs): the host names and IP addresses the certificate is valid for. Clients look only here, not at the common name (CN) (RFC 9525).
- Validity: the first and last moment it may be used, in UTC. The period counts both ends, as the Baseline Requirements do.
- Public key: the type and size of the key — RSA 2048-bit or ECDSA P-256 are the usual ones.
- Fingerprints: the SHA-256 (and older SHA-1) hash of the whole certificate — what browsers show as its fingerprint and what you compare to identify it.
- Public key SHA-256 and pin: the hash of the public key alone, in hex and in the Base64 form used for public-key pinning. It stays the same when a certificate is renewed with the same key, and it is how you match a certificate with its CSR and private key.
- Key usage / extended key usage: what the key may do (sign, encrypt) and what the certificate is for (TLS server, client, code or email).
- Basic constraints: whether it belongs to a certificate authority, and how many CAs may follow below it.
- Authority Information Access and CRL distribution points: where clients download the issuer’s certificate and check revocation.
How the chain is checked
The decoder works out which certificate issued which: the issuer name must match the issuer’s subject (byte for byte in public PKI, BR §7.1.4.1), the key identifiers must agree, and the signature must verify with the issuer’s public key (checked with your browser’s Web Crypto). Then it checks that each issuer is a CA allowed to sign certificates, that path-length limits hold, and that the certificates come in the order TLS requires: the server certificate first, then each issuer in turn (RFC 5246 §7.4.2; TLS 1.3 clients are more tolerant, RFC 8446 §4.4.2). The root may be left out, since clients have their own copy.
When the order is wrong or the paste contains unrelated certificates, the chain is offered in the correct order for download. Whether the root is one that browsers trust cannot be checked here: that depends on each browser’s and operating system’s trust store.
Validity periods and key rules for public certificates
Publicly trusted TLS certificates must follow the CA/Browser Forum Baseline Requirements. The longest allowed validity depends on the issue date (§6.3.2):
- issued before 15 March 2026: up to 398 days
- from 15 March 2026: up to 200 days
- from 15 March 2027: up to 100 days
- from 15 March 2029: up to 47 days
RSA keys must be at least 2048 bits and ECDSA keys must use P-256, P-384 or P-521 (§6.1.5); signatures use SHA-256, SHA-384 or SHA-512 (§7.1.3.2). Chrome stopped trusting SHA-1 certificates (Google’s announcement). Certificates from a private (company) CA may differ — the decoder says so instead of calling them wrong.
Certificate Transparency (SCTs)
Public CAs log every certificate in Certificate Transparency logs and embed the logs’ signed receipts, SCTs, in the certificate. The decoder names each log from the lists Chrome and Apple publish, and — when you paste the issuing CA’s certificate too — verifies each SCT’s signature against the log’s key, as RFC 6962 §3.2 describes.
Chrome’s and Apple’s CT policies need SCTs from at least two distinct logs for a certificate valid up to 180 days and three for longer ones, from at least two log operators; Apple also needs at least one of them from a log that follows RFC 6962 rather than the newer static CT API. The decoder checks these counts, leaving out SCTs whose signature fails and those from test or monitoring-only logs, which browsers do not trust. Both policies also require the logs to be trusted at the time of the check, which changes as logs retire; that part is not checked here.
The same checks with OpenSSL
- Show a certificate:
openssl x509 -in cert.pem -noout -text - Fingerprint:
openssl x509 -in cert.pem -noout -fingerprint -sha256 - Get a server’s chain:
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null - Verify a chain:
openssl verify -untrusted intermediate.pem server.pem - Show a CSR:
openssl req -in request.csr -noout -text -verify - Convert DER to PEM:
openssl x509 -inform der -in cert.cer -out cert.pem
Limitations
- Trust is not checked: the decoder cannot tell whether a root is in a browser’s or operating system’s trust store, so a valid-looking chain may still end at an untrusted root.
- Revocation is not checked: OCSP and CRL lookups need the network, and this tool never sends your certificates anywhere. Use the addresses it shows with
openssl ocspor a revocation checker. - Name constraints are decoded and shown but not enforced on the certificates below them.
- PKCS#12 files (.pfx, .p12) are password-protected: export their certificates first with
openssl pkcs12 -in file.pfx -nokeys -out chain.pem. CRLs and bare public keys are not decoded. - Signatures made with algorithms browsers do not support (MD5, SHA-224, DSA, GOST, post-quantum ML-DSA) are reported as not checked, never as valid. Ed25519 signatures need a recent browser.
- The lists of Certificate Transparency logs are a snapshot: a log newer than the snapshot is shown by its ID only.
Privacy
Certificates are decoded by this page in your browser; nothing you paste or choose is uploaded or stored. If you paste a private key by mistake, the decoder skips it without reading it — a private key never needs to be shared.
Frequently asked questions
How do I find out when my SSL certificate expires?
Paste it here: the summary shows how many days are left and the exact expiry time in UTC, and the decoder warns when renewal is due. For the certificate a live server presents, fetch it with openssl s_client -connect example.com:443 -servername example.com </dev/null and paste the output, or use the SSL Certificate Checker.
What is the difference between PEM, DER, CRT and CER files?
PEM is text: Base64 between -----BEGIN CERTIFICATE----- lines, and one file can hold a whole chain. DER is the same certificate in binary. .crt and .cer are just names — either file can be PEM or DER. The decoder reads both and lets you download each certificate in either form.
In what order should the certificates be in my chain file?
Your server’s certificate first, then the intermediate that issued it, then the next one up, if any. The root is usually left out. Paste the file here: if the order is wrong, the decoder offers the corrected chain for download.
Is it safe to paste a certificate into a website?
Certificates are public — servers send them to every visitor — and this page decodes them locally without uploading anything. The private key is the secret part: never paste or send it. If one is pasted here by mistake, it is skipped and not read.
Why does a certificate’s signature show as not checked?
Either its issuer’s certificate is not in what you pasted — add it to check the signature — or the algorithm is one browsers cannot verify, such as MD5 or DSA. A self-signed root is checked against its own key.
How do I check that a certificate matches my private key?
Compare the public keys, on the machine that holds the key: openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256 and openssl pkey -in key.pem -pubout -outform DER | openssl sha256 must print the same hash — the Public key SHA-256 this page shows for the certificate. Keep the key itself off websites.