Certificate Decoder
Decodes X.509 certificates and CSRs in your browser, and — the part every other certificate decoder leaves to a separate tool — checks whether a pasted chain actually joins up.
Free · No signup · Nothing leaves your browser
Decodes X.509 certificates and CSRs in your browser. Paste the whole chain and it checks whether it actually joins up — the missing intermediate that makes a site work in Chrome and fail in curl, Java and Go. It will not accept a private key, and does not need one.
2 things worth knowing
- infoWildcard for *.secure.example.com
A wildcard covers one label only: *.example.com matches a.example.com but not b.a.example.com, and not example.com itself unless that is listed separately.
- infoOnly the leaf certificate was pasted
A server has to send its intermediates too. Browsers often paper over a missing one by fetching it, which is exactly why the same site works in Chrome and fails in curl, Java and Go. Paste the full chain to check it.
Certificate
subjectC=DE, O=Tekk GmbH, CN=secure.example.comissuerC=DE, O=Tekk Test CA, CN=Tekk Test Root CAvalid2026-08-17 → 2027-03-05199 days left, issued for 200serial1FA79E884708432920C20AD20E1663EFA964BF40keyRSA 2048-bit · e=65537signatureSHA-256 with RSAused forTLS server authentication
Hostnames it covers
secure.example.com*.secure.example.com
Everything runs in your browser — nothing is uploaded, logged or stored. Certificates are public documents, so that matters less here than elsewhere on this site; a CSR and the hostnames inside it are rather less public, and there is no reason for either to leave your machine to be read.
Tekk is a spec-driven development platform for people building software with AI coding agents — for the part that only breaks once it is deployed.
Works in Chrome, fails in curl
This is the certificate bug. It costs a day, roughly once per engineer per career, and it is almost never the certificate.
A TLS server must send its own certificate and every intermediate above it. Only the root is expected to be already installed on the client. If an intermediate is missing:
- Browsers usually work anyway. They cache intermediates they have seen before, and follow the
Authority Information Accessextension to fetch a missing one. The connection succeeds and nothing is reported. - curl, Java, Go, Python, Node and every CI runner fail. None of them fetch. They verify what was sent, find a gap, and stop.
So the site loads perfectly for the person checking it and breaks for the integration nobody is watching. Then the certificate gets reissued, which changes nothing, because the certificate was never the problem.
Paste the whole chain here and it says which links join and which do not.
Chain order matters too
Leaf first, then each issuer above it. Reversed or shuffled chains are rejected by strict clients even when every individual certificate in the file is valid and unexpired.
A wrong order and a missing certificate produce the same symptom and different fixes, so they are reported differently:
#1 secure.example.com ✗ not issued by the next one
#2 Tekk Test Root CA
Links are compared on the raw DER bytes of one certificate's issuer field against the next one's subject field — not on the printed text. Two names that render identically can be encoded differently, and a verifier treats those as different names even though a checker comparing strings would call them equal.
What gets flagged
| Finding | Why it matters |
|---|---|
| Expired, or expiring within 30 days | With the exact date and the days remaining. If renewal is automated, this is the window in which you discover it is not. |
| Not valid yet | On a freshly issued certificate this is clock skew on the machine doing the checking, not a bad certificate. |
| SHA-1 or MD5 signature | Rejected by every major browser since 2017. No configuration fixes it. |
| RSA key under 2048 bits | Below the floor every public CA and browser enforces. |
| No subject alternative name | Matches no hostname at all. Chrome stopped reading the Common Name as a hostname in 2017. |
| Valid for more than 398 days | Browsers cap publicly trusted certificates there. Fine for an internal CA, rejected in public. |
| Self-signed | Issuer equals subject. Normal locally, never right in production. |
| Wildcard | Covers one label. *.example.com does not match a.b.example.com, or example.com itself. |
CA:TRUE with server authentication |
Basic constraints say authority, extended key usage says web server. Usual with hand-rolled openssl certificates. |
CSRs, before you pay
A certificate signing request is the last point at which a mistake is free. After signing, a typo in a hostname means a reissue and, with some authorities, a wait.
SANs in a CSR live inside an extensionRequest attribute — two levels deeper than the equivalent extension in a certificate. Several decoders do not walk that far and show a CSR with no SANs, which reads as "nothing to see" rather than "not checked".
What it will not do
It will not read a private key. Paste one and it stops and says so. Nothing on this page needs one; a certificate and a CSR are both public documents by design.
It will not verify signatures. That needs the issuer's key, and the answer would only repeat what your own TLS stack already checks on every single connection. Completeness, order, expiry, hostname coverage and key strength all come from the certificates themselves.
It is not a replacement for openssl. If openssl is on the machine, use it. This is for when it is not — and because openssl x509 -text prints every field at once, in DER order, without telling you which of them is the problem.
How it works
- 1
Paste the whole chain, not one certificate
One block gets decoded. Several get decoded and then checked against each other: does certificate 1 name certificate 2 as its issuer, and 2 name 3. This is the check that answers why a site works in a browser and fails in curl, and it is the reason to paste more than you think you need.
- 2
Read the findings
Expired or expiring, not valid yet, SHA-1 signatures, keys under 2048 bits, no subject alternative name, validity longer than the 398 days browsers accept, self-signed, wildcard scope, and CA:TRUE on something that claims to be a web server.
- 3
Check a CSR before you pay for it
A csr decoder is the last chance to catch a typo in a hostname before a certificate authority signs it and charges you. It shows the subject, the key it was generated with, and the SANs — which live two levels deeper in a CSR than in a certificate, and which several tools miss entirely.
Frequently asked questions
- Do you store or send my certificate anywhere?
- No. Decoding happens in the page — there is no server call, nothing logged and no account. Certificates are public documents so this matters less than on some pages, but a CSR and the internal hostnames inside it are not public, and there is no reason for either to leave your machine to be read.
- Will it read my private key?
- No, and it refuses outright if one is pasted. Nothing this certificate decoder does requires a key: a certificate and a CSR are both public by design. If a private key has been pasted somewhere it should not have been, treat it as compromised and reissue rather than hoping.
- My certificate works in Chrome but curl and Java reject it. Why?
- Almost always a missing intermediate. Your server has to send its own certificate and every intermediate above it; only the root is expected to be already trusted. Browsers quietly paper over a gap by fetching the missing certificate themselves, and curl, Java, Go and Python do not. Paste the full chain here and it will tell you whether each certificate is genuinely issued by the next one in the file.
- What order should the chain be in?
- Leaf first, then each issuer above it, root optional. Reversed or shuffled chains are rejected by strict clients even though every certificate in the file is valid. This certificate decoder reports the order you pasted and marks each link as joining up or not, so a wrong order looks different from a missing certificate — they share a symptom and need different fixes.
- How does it decide two certificates are linked?
- By comparing the raw DER bytes of one certificate's issuer field against the next certificate's subject field. Comparing the printed text instead is what makes other checkers wrong on names that render the same but were encoded differently — a PrintableString and a UTF8String of the same characters are not the same name to a verifier.
- Does it verify the signature?
- No. Checking that the issuer's key actually signed the certificate needs the issuer's public key and a signature operation, and a browser can do it but the answer would only repeat what your own TLS stack already checks on every connection. What is worth knowing here — is the chain complete, is it in order, has it expired, does it cover the hostname — comes from the certificates alone.
- Why does it say there is no subject alternative name?
- Because there is not, and that certificate matches no hostname at all. Chrome stopped reading the Common Name as a hostname in 2017 and everything else followed. A certificate with CN=example.com and no SAN looks perfectly correct in an ssl certificate decoder that only prints fields, and fails in every browser that sees it.
- What does a wildcard actually cover?
- One label, and only one. *.example.com matches api.example.com but not v2.api.example.com, and not example.com itself unless the bare name is listed as a separate SAN. Most wildcard certificates in production are missing that second entry and nobody notices until the apex is requested.
- Why flag a certificate valid for more than 398 days?
- Because Apple, then Google and Mozilla, capped publicly trusted certificates at 398 days in 2020, and clients reject longer ones regardless of who signed them. A ten-year certificate from an internal CA is fine and normal; the same certificate offered to a browser is not.
- Can it decode a CSR as well as a certificate?
- Yes. As a csr decoder it shows the subject, the public key it was generated with, the signature algorithm and the SANs from the extensionRequest attribute — which sit two levels deeper than in a certificate, which is why some tools show a CSR with no SANs at all and leave you to find out after issuance.
- Is a csr checker useful before I buy a certificate?
- It is the cheapest check there is. A csr checker catches a mistyped hostname, a missing www, a 1024-bit key or the wrong organisation name while the fix is still free. Afterwards it means a reissue, and with some authorities a wait.
- What formats does it accept?
- PEM — the base64 blocks that begin with -----BEGIN CERTIFICATE----- or -----BEGIN CERTIFICATE REQUEST-----. Multiple blocks in one paste are read as a chain. Binary .der, .cer and .pfx files need converting first, which openssl will do locally in one command.
- Why not just use openssl?
- Use openssl. It is on the machine and it is authoritative. This certificate decoder exists for the times it is not to hand — a laptop without it, a phone, a colleague's screen — and because openssl x509 -text prints everything at once, in DER field order, without saying which of it is a problem.
- Is an ssl certificate decoder the same as an SSL checker?
- No, and the difference is what gets pasted. An SSL checker connects to a live hostname and reports what that server sends, which needs the server to be reachable and public. An ssl certificate decoder reads a file you already have — one that has not been deployed yet, sits behind a VPN, or arrived by email from whoever bought it. Both are useful; only one works before anything is live.
- Why is this free, and what is Tekk?
- Tekk is a spec-driven development platform for people building software with AI coding agents. This page costs nothing to run because nothing runs on our servers, so there is no signup wall, no run limit and no upsell inside the tool.
Want a real spec for what you’re building?
Drop a sentence. Tekk grounds it in your actual code and turns it into an executable plan.
Free to try · Connect GitHub during signup