SSL/TLS error reference

Paste the exact error text into search, find the page, and you get the cause, a visitor-side check and the server-side fix.

Each page here explains one exact error string, such as NET::ERR_CERT_DATE_INVALID or SEC_ERROR_UNKNOWN_ISSUER: what it means, whether the site or your device is at fault, and the fix. Search for the text you see and work through the matching page from top to bottom.

How to use these pages

Start by testing the site, not your computer. Enter the domain into the SSL checker, or run this from any terminal:

curl ssl.sh/example.com

The checker connects from our servers with an up-to-date trust store and reports the certificate, chain, protocol versions and common misconfigurations. That single result splits every problem into two paths:

  • The check fails too. The site is misconfigured: an expired certificate, a missing intermediate, a hostname mismatch or an old TLS setup. If you run the site, follow the "How site owners fix it" section of the error page. If you are only a visitor, there is nothing safe to fix on your side; tell the site owner and wait.
  • The check passes, but your browser still complains. The cause is on your device or network: the clock, antivirus HTTPS scanning, a company proxy, a Wi-Fi login page, or an operating system too old to trust current root certificates. The "Is it the site or your device?" section on each page tells you what to check first.

What each page contains

Each error page lists the causes in order of likelihood, shows how the same failure looks in Chrome, Firefox, Safari, Edge and on phones, and gives copy-paste server configuration for Nginx, Apache and common panels. Related tools such as the chain builder, certificate decoder and TLS config generator are linked where they shorten the fix.

We never recommend clicking through a certificate warning on a site you do not control: it removes the only protection against someone intercepting the connection.

Browser errors

Phones and operating systems

Servers and proxies

Programming languages

Command-line tools

Platforms and DevOps

Mail and other protocols

Issuance and renewal

FAQ

Is an SSL error always the website's fault?

No. Many cases come from the visitor's side: a wrong system clock, antivirus HTTPS scanning, a corporate proxy, public Wi-Fi login pages or an outdated device. Check the site with the SSL checker first; if it passes from our servers, the problem is local to the device or network that shows the error.

Is it safe to click "Proceed anyway" on a certificate warning?

Only on a device or site you control and when you know why the warning appears, such as your own router's admin page with a self-signed certificate. On any site where you log in, pay or type personal data, do not bypass the warning: the browser cannot prove you are talking to the real server, so anything you send could be read or changed.

Why does the same site work in one browser and fail in another?

Browsers use different trust stores and different repair tricks. Chrome and Safari often download a missing intermediate certificate on their own, Firefox relies on a preloaded list of public intermediates, and most command-line tools and apps do neither, so an incomplete chain fails only in some clients. Run curl ssl.sh/example.com or the chain builder to see the chain the server sends.