Parse and inspect SSL certificate details from PEM format
Decoded Certificate
Subject
Issuer
Validity
Not Before
Not After
Key Information
Type
Size
Subject Alternative Names
No SANs
Fingerprints
Serial Number
SHA-256 Fingerprint
Error
About Certificate Decoder
Our free Certificate Decoder parses PEM-encoded SSL/TLS certificates and displays all fields in a human-readable format. Paste any certificate to instantly view its subject, issuer, validity period, key information, SANs, serial number, and SHA-256 fingerprint. Useful for debugging certificate issues and verifying certificate contents before deployment.
How to Use
1Paste your PEM-encoded certificate into the text area.
2Click "Decode Certificate" to parse and display all fields.
3Review the subject, issuer, validity, key info, SANs, and fingerprints.
Use Cases
•Decode and verify certificates received from a CA
•Inspect certificate details before installing on a server
•Verify SANs match your domain names
•Check certificate fingerprints for integrity verification
Rather than guess, the decoder matches your pasted text against a built-in library of real failures and ranks what it finds. It is deliberately conservative: when it cannot identify a cause, it says so instead of inventing one.
1The text is normalised — lowercased and whitespace-collapsed — so line wrapping and capitalisation do not affect matching.
2Every entry in the library is tested against it. Each entry carries several patterns, so an error is recognised whatever wording your particular client used.
3Matches are ranked twice over: most severe first, then most specific. That ordering exists because a specific cause such as “certificate has expired” is almost always wrapped in a generic message like “certificate verify failed”, and only the inner one tells you what to fix.
4Each match returns its cause, concrete fixes and references — and when nothing matches at all, you get a short generic checklist instead of a guess.
The library currently holds 24 entries across eight areas: chain problems, expiry, hostname mismatch, trust, protocol negotiation, keys, revocation and network failures.
Tips & Best Practices
•Always verify the certificate's SANs match all domains you're securing
•Check the issuer to ensure the certificate was issued by a trusted CA
•Compare validity dates to ensure the certificate is currently active
Frequently Asked Questions
Yes, paste the DER content and it is converted and decoded in one step. The practical difficulty is getting binary through a text field intact: a certificate re-encoded as text is no longer the same bytes, so the conversion has to be from an intact base64 representation rather than from something a mail client or clipboard has mangled. If you have the certificate as a file, converting it to PEM with the Certificate Format Converter first is more reliable, and it also tells you immediately whether the file is intact.
A Subject Alternative Name is an extension listing every name a certificate is valid for, stored alongside the subject rather than replacing it. Since 2017 every major browser has ignored the Common Name entirely and validates only against this list, so a certificate with a CN and no SANs is treated as covering nothing. That is why a certificate can be correct in every visible field and still fail, and why the list is the thing to check whenever a hostname does not match.
Usually the input is not a whole certificate. Missing BEGIN and END markers, text truncated when it was copied, or several certificates concatenated into one block all cause it. A binary DER file also needs to be base64 encoded before it can be pasted into a text field at all, and a file saved with Windows line endings can confuse some parsers. Converting the file to PEM with the Certificate Format Converter diagnoses all of these at once, because it will tell you whether the bytes are a valid certificate before anything tries to read the fields.
Because your client reported both. Tools like curl, OpenSSL, Java and browsers routinely wrap a precise cause in a general message: “certificate verify failed” on top of “certificate has expired”. Both are in the library and both are returned, ordered so the specific cause is the primary diagnosis and the generic wrapper sits below it. Read the first result as the cause and the second as the symptom, not the other way round.
You get an honest no-match result and a short generic checklist covering the causes that account for most TLS failures, rather than a confident guess. This is the intended behaviour. Error text varies between clients and versions, and a decoder that matched loosely would produce confident nonsense on unfamiliar input. If nothing matches, the fastest route is usually to check the three things on the checklist — the certificate's validity dates, whether the chain is complete, and whether the hostname is actually covered.
Twenty-four known failures across eight categories: incomplete or unbuildable chains, expired and not-yet-valid certificates, hostname mismatch, self-signed certificates, unsafe renegotiation, rejected client certificates, protocol version mismatches, SNI not recognised, missing key shares, undersized Diffie-Hellman parameters, weak keys or signatures, key and certificate mismatches, wrong passwords, malformed PEM and DER, revocation, and network-level failures including refused connections, timeouts and DNS failures. Each carries the fixes that resolve it in practice.
The text you paste is used to match against the library and to build your result. It is not written to a database, not attached to an account, and not associated with the domain you may also have entered. Worth knowing because error text is often more revealing than people expect: it routinely contains internal hostnames, IP addresses, software versions and absolute file paths from the machine that failed. Treat it as you would treat a log line and redact it before sharing it.
That is a different tool. This page decodes error messages. For a DER-encoded certificate, convert it to PEM first with the Certificate Format Converter, then read it with the SSL Checker or the Certificate Decoder. Keeping the two apart matters because they answer different questions: one tells you what went wrong, the other tells you what a document contains. If you have an error and a certificate in hand, decode both — the error usually names the problem and the certificate usually confirms it.
