Paste an SSL error message and get the cause plus the fix
What it means
How to fix it
•
References
Other possible matches
•
Diagnostic checklist
•
About the TLS/SSL Error Decoder
TLS error messages are famously terse: certificate verify failed tells you nothing about which of half a dozen things went wrong. This decoder maps the messages produced by OpenSSL, curl, Chrome, Firefox, Java and Python onto a plain-English explanation and a concrete fix. It recognises the most common failures: an incomplete chain (the missing intermediate certificate), expired or not-yet-valid certificates, hostname mismatches, self-signed certificates, no shared cipher suite, weak Diffie-Hellman parameters, revoked certificates, and plain network errors such as connection refused.
How to Use
Copy the complete error message, including anything after the colon.
Paste it into the box above and click Decode error.
Read the cause and work through the fixes in order - the first one is almost always the answer.
Use the diagnostic checklist to confirm the fix.
Use Cases
Deployment triage: a new certificate works in one browser and fails in another - find out why fast.
Support tickets: turn a customer's raw error dump into an actionable answer.
CI failures: explain why a pipeline's HTTPS call started failing after a renewal.
Learning: understand what each layer of the chain check actually reports.
Frequently Asked Questions
"unable to get local issuer certificate" - the server is not sending its intermediate certificates. Browsers often paper over this by fetching the missing intermediate themselves, which is why a server can work in Chrome but fail in curl, Python or a mobile app.
Browsers automatically fetch missing intermediates using the AIA extension. Command-line tools do not, so they fail with a chain error. The fix is always the same: configure the server to send the full chain.
It is matched against a knowledge base on this server and nothing more: not stored, not logged against an account, not sent to any external service. Worth knowing regardless, because error text carries more than people expect. It routinely contains internal hostnames, IP addresses, software versions and absolute file paths from whichever machine failed, so redact it before posting anywhere public even after decoding it.
A certificate that does not cover the hostname requested. It is not a protocol problem at all — the certificate may be perfectly valid, in date and issued by a trusted authority — and it usually means the wrong certificate is being served for that name, commonly behind a proxy or on a host with several virtual hosts. Expecting a certificate error is a normal configuration mistake, not an attack.
Almost always a client old enough to lack the server's modern suites, or one whose configuration has been narrowed too far. It is worth checking the server's actual cipher list rather than assuming, since a configuration that excludes the common suites breaks old clients without anyone noticing until one connects. Fix it by including a broader set on the server rather than by upgrading the client you do not control.
The wording is specific. Unable to get local issuer certificate means a link is missing or the root is unknown; certificate has expired means it is out of date; nothing says the certificate is trusted because the chain could not be completed. If the wording is ambiguous, run the chain checker and read the result — the two problems are fixed in completely different places, on the server and in your lifecycle respectively.
Sometimes, and it is worth knowing when. A client-side exception for an outdated certificate exists in some browsers, and a proxy that re-signs traffic can sidestep a client-side chain problem — though that is a decision to make deliberately rather than a fix. For everything else the server is where the problem is, and the errors here will usually say so.
Different vantage points change what you see: cached intermediates on your machine, a trusted root you have installed, a proxy one of you traverses and the other does not, or a server that negotiates differently for different sources. This is the single most common reason a TLS problem resists debugging — the client is seeing something genuinely different from what you are, and reproducing from a clean environment is what reveals it.
Technical Details
How matching works
A knowledge base of 25 entries covering OpenSSL, curl, Chrome, Firefox, Java and Python messages
Text is lower-cased and whitespace-collapsed first, so line breaks and indentation never matter
Matches are ranked by severity first, then by the longest pattern
That is why certificate verify failed: certificate has expired reports the expired certificate instead of the generic wrapper
What the knowledge base covers
Expiry, hostname mismatch, unknown or self-signed issuer, missing intermediate
Protocol failures: handshake, no shared cipher, legacy renegotiation, unrecognised SNI, DH parameter and key-size limits
Transport failures: connection refused, DNS resolution, timeouts
When nothing matches
A generic checklist runs instead of a specific diagnosis
It walks DNS resolution, the TCP connect, the TLS handshake, certificate dates, chain completeness and hostname validation
You get the failing step rather than a guess
What you get back
The most likely cause, plus any other patterns that also matched
Concrete fixes, including ready-to-paste server configuration
Verification commands to confirm the repair worked
The pasted text is posted here to be decoded and is never written to your certificate store
How Errors Are Resolved
TLS error messages are terse and assume knowledge. This page takes the error and gives you what it means and what to do about it.
1Identify what the error refers to — certificate, protocol negotiation, hostname or the chain — since the same visible symptom has different causes depending on which layer failed. Naming the layer is most of the value.
2Explain why it happens, in terms of the specific condition rather than in generalities. “No shared cipher” and “no shared signature algorithm” both look like negotiation failures and are fixed by entirely different changes.
3Give the concrete next step, including the command that confirms the fix where one exists. A diagnosis without a next action leaves you where the error message did.
Most TLS errors are configuration rather than protocol problems: a missing intermediate, an expired certificate, a name the certificate does not cover. That is worth knowing before assuming anything exotic is wrong.
Tips & Best Practices
•Always paste the text after the colon - it carries the real reason.
•Reproduce with openssl s_client -connect host:443 -showcerts for the clearest output.
•Check the server clock before blaming a certificate for being expired.
•Redirect all HTTP to HTTPS so mixed content and downgrade errors cannot occur.
