SSL certificate errors: what site owners (and visitors) need to know
"Your connection is not private" is the message most visitors see, but the SSL certificate error behind it can be one of several different problems — some caused by the site's own certificate or server configuration, others by the visitor's device. This guide is written for site owners: what each error usually means, what typically causes it, and how to fix it. The exact wording differs by browser, so treat the error codes below (mostly Chrome's) as pointers rather than an exact match for whatever your visitors report seeing.
If you are a visitor seeing this warning on someone else's site: do not enter passwords or payment details, try reloading later or from a different network (a wrong device clock is a common cause), and if the warning persists, treat it as the site's problem rather than clicking through. If you want the fundamentals of how certificates work before going further, see our guide to what SSL/TLS actually does.
Common SSL certificate errors at a glance
Here is a quick map from what you, or a visitor, actually sees to what is usually wrong and what fixes it:
| What you see | Typical cause | Fix |
|---|---|---|
| "Your connection is not private" / NET::ERR_CERT_DATE_INVALID | Certificate expired, or the visitor's device clock is wrong | Renew the certificate; ask the visitor to check their system date and time |
| ERR_CERT_COMMON_NAME_INVALID / SSL_ERROR_BAD_CERT_DOMAIN | The hostname isn't covered by the certificate — a missing SAN or a mismatched CSR | Reissue the certificate with the correct Common Name and SANs |
| NET::ERR_CERT_AUTHORITY_INVALID | Self-signed certificate, untrusted issuer, or a missing intermediate chain | Install the full certificate chain from a publicly trusted CA |
| ERR_SSL_PROTOCOL_ERROR / ERR_SSL_VERSION_OR_CIPHER_MISMATCH | An old TLS version, an unsupported cipher, or a server misconfiguration | Enable TLS 1.2/1.3 and update the server's SSL configuration |
| Padlock with a warning, or a mixed content console warning | HTTP resources loading on an HTTPS page | Serve every resource over HTTPS — see our mixed content guide |
Expired certificates and clock errors (NET::ERR_CERT_DATE_INVALID)
NET::ERR_CERT_DATE_INVALID means the browser thinks the certificate's validity window doesn't cover right now — either because the certificate actually expired, or because the visitor's device clock or date is set incorrectly and the browser is comparing against the wrong "now." Check the certificate's own dates first, in the browser's certificate viewer or with openssl s_client (see below); if the certificate is genuinely expired, the only fix is to renew it.
Public certificate lifetimes are also getting shorter under the CA/Browser Forum's Ballot SC-081 — a maximum of 200 days for certificates issued from March 2026, dropping further after that — so expirations that used to happen once a year will happen more often. Our guide to renewing an SSL certificate covers how to stay ahead of it, including expiry reminder emails.
Name mismatch errors (ERR_CERT_COMMON_NAME_INVALID / SSL_ERROR_BAD_CERT_DOMAIN)
This error means the certificate is valid, but not for the hostname the browser actually requested — the Common Name and SANs don't include it. It's common right after a www/non-www change, a new subdomain, or a certificate ordered for the wrong domain. If the certificate never had the right hostnames to begin with, the fix starts at the request itself — see our guide to what a CSR is and how to generate one before you reissue.
If you regularly add subdomains, or need one certificate to cover several different domains, compare wildcard vs. multi-domain SSL before reissuing — the wrong choice here is exactly what causes this error to keep coming back.
Untrusted or missing chain errors (NET::ERR_CERT_AUTHORITY_INVALID)
This one usually means one of three things: the certificate is self-signed, it was issued by an authority the browser or OS doesn't trust, or — the most common case on a real production site — the server never sent the intermediate certificates that link it to a trusted root. Desktop Chrome can sometimes fetch a missing intermediate on its own, which is why a site can look fine there and fail everywhere else, including mobile browsers, older systems, and API clients. Our SSL installation guide covers building and installing the full certificate chain correctly on Nginx, Apache, and cPanel.
Protocol and cipher errors (ERR_SSL_PROTOCOL_ERROR / ERR_SSL_VERSION_OR_CIPHER_MISMATCH)
These point away from the certificate itself and toward the server's TLS configuration: an old protocol version, a cipher suite the browser no longer accepts, or in some cases a network device intercepting the connection. Major browsers dropped support for TLS 1.0 and 1.1 around 2020, so a server still limited to those protocols will fail to connect for a growing share of visitors. The fix is a server-side configuration change enabling TLS 1.2 and 1.3 with modern cipher suites, not a new certificate.
Mixed content and HSTS: when the padlock still looks wrong
A page can have a perfectly valid certificate and still show a broken or warning padlock if it loads some resources over plain HTTP — this is mixed content, and browsers block active mixed content like scripts outright. It is common enough after a migration to HTTPS that it deserves its own guide; see how to fix mixed content errors for the search-and-replace and CSP-based fixes.
HTTP Strict Transport Security (HSTS) is worth mentioning here too, because it changes how errors behave: once a browser has seen an HSTS header for your domain, it will refuse to let visitors click through certificate warnings on that domain at all. That is good for security once your setup is solid, but it means any of the errors above become impossible to bypass — test thoroughly before enabling HSTS with a long max-age.
How to diagnose an SSL error yourself
Two tools cover most cases. From any machine with OpenSSL installed:
openssl s_client -connect example.com:443 -servername example.comThe -servername flag matters — it enables SNI so you see the certificate actually served for that hostname. Look at the certificate chain, the NotBefore/NotAfter dates, and the Verify return code line at the end; anything other than 0 (ok) tells you which category above you're dealing with.
For a visual check, open the browser's certificate viewer — click the padlock, then look for "Certificate is valid" or similar; the exact steps differ by browser — to see the Common Name, SANs, issuer, and expiry date without touching a terminal at all.
Errors on mobile apps and APIs vs. browsers
A certificate problem doesn't always surface first in a desktop browser. Mobile apps, payment SDKs, and API clients such as curl or a server-to-server integration typically use a stricter TLS stack than Chrome or Firefox: many won't fetch a missing intermediate certificate on their own, offer no "proceed anyway" option, and simply fail the connection outright rather than showing a warning a human can read. That's why a missing chain or a hostname mismatch can go unnoticed on the site owner's own desktop browser for weeks while it quietly breaks a mobile app login or a webhook integration using the same domain. If an error is reported by API users or an app but not by desktop visitors, check the full chain (see the untrusted-chain section above) and the exact hostname coverage first — those two causes account for most of this gap.
A quick troubleshooting checklist
- Confirm the exact hostname that's failing, including whether it's the
wwwor non-wwwversion and which subdomain. - Check the certificate's own
NotBefore/NotAfterdates against today's date, not just the reporting device's clock. - Confirm the Common Name and SANs actually list that hostname.
- Run
openssl s_clientand read theVerify return codeat the end of the output. - Note whether the error only shows up on mobile apps, API clients, or older systems rather than a current desktop browser — that pattern usually points to a missing intermediate chain.
- If everything above checks out, look at the server's supported TLS protocol and cipher suites, and separately check the browser console for mixed content warnings.
Fix the error, then keep it from coming back
Most SSL certificate errors trace back to one of four things: an expired certificate, a hostname the certificate doesn't cover, a missing intermediate chain, or an outdated server configuration. Diagnose with openssl s_client or the browser's certificate viewer, match what you find to the table above, and fix the underlying certificate or server setting rather than just reloading and hoping.
If the real fix is a reissue or a different certificate type altogether, SSLCipher's SSL certificates overview lists DV, OV, EV, Wildcard, and Multi-Domain options so you can order the right one the first time.
Frequently asked questions
01Why does Chrome say my connection is not private?
This message usually means the certificate has expired, does not cover the exact hostname being requested, or the chain of trust back to a trusted root cannot be verified. The specific error code shown underneath, such as NET::ERR_CERT_DATE_INVALID, narrows down which of those it is.
02How do I fix NET::ERR_CERT_DATE_INVALID?
First check whether the certificate itself has actually expired, using the browser certificate viewer or openssl s_client; if it has, renew it. If the certificate is still valid, the problem is usually the visitor’s own device clock or date being set incorrectly.
03Why do I get ERR_CERT_COMMON_NAME_INVALID on a certificate that looks valid?
The certificate is valid, but its Common Name and SANs don't include the exact hostname the browser requested, often after adding a subdomain or switching between www and non-www without updating the certificate. Reissuing the certificate with the correct hostnames included fixes it.
04Is an SSL certificate error always the website’s fault?
No — a wrong device clock or date on the visitor’s side commonly triggers NET::ERR_CERT_DATE_INVALID even when the site’s certificate is perfectly valid. That said, most other error types, like a missing intermediate chain or an uncovered hostname, do need a fix on the server or certificate side.