Browser SSL errors are deliberately blunt. They have to be — they're the last line of defence between a user and a server that can't be trusted. The downside is that the messages aren't useful for diagnosis: they tell a visitor "something's wrong" without explaining what or how to fix it. This guide unpacks the most common errors, what each one really means, and exactly what to change to make them go away.
If you only have a minute, run the affected domain through SSL Checker first. The tool will tell you instantly whether the certificate is expired, untrusted, missing intermediates, or serving a hostname mismatch — which covers the cause of about 90% of these errors.
NET::ERR_CERT_DATE_INVALID
This is the most common error you'll encounter, and the easiest to diagnose. The certificate is either expired, or the visitor's device clock is wrong. In both cases, the browser refuses to trust the certificate because the validity window doesn't include the current moment.
If you're the site owner: the certificate has expired. Renew it. If you use Let's Encrypt with Certbot, run sudo certbot renew --force-renewal and reload your web server. If you use a hosting provider like Cloudflare, Netlify, or a managed shared host, the renewal is normally automatic — log into the control panel and check whether SSL is enabled and the cert is current. After renewal, run an SSL Checker scan to confirm the new expiry date.
If you're a visitor: check the device's date and time. A misconfigured clock — common on freshly installed devices, devices restored from backup, or devices that have been off for months — will trigger this error on every HTTPS site on the internet, not just one. Set the clock to auto-sync via NTP and the error usually disappears immediately.
NET::ERR_CERT_AUTHORITY_INVALID
The browser doesn't trust the issuer of the certificate. There are three common causes, and the fix depends on which one applies.
Self-signed certificate. Self-signed certificates aren't issued by a recognised certificate authority, so browsers won't trust them by default. They're fine for local development, but on a public site they need to be replaced with a real certificate from a trusted CA. Let's Encrypt is free and takes about 10 minutes to set up.
Missing intermediate certificate. This is the single most common SSL misconfiguration. Your leaf certificate is valid, but the server isn't sending the intermediate certificate that links it back to the trusted root. Most desktop browsers will fetch the missing intermediate automatically (via the AIA extension), but mobile browsers, some older browsers, and many API clients won't — so the site appears to "work in Chrome but not on iPhone." The fix is to install the full certificate chain, not just the leaf. Most CAs provide a "fullchain.pem" or chained certificate file specifically for this purpose. Our SSL Checker shows the chain it received and flags missing intermediates explicitly.
Untrusted root. Less common, but you'll see it if a corporate device is on a network that uses TLS interception (a corporate proxy injecting its own root CA) and that CA isn't installed on the device. This is an IT problem, not a website problem.
NET::ERR_CERT_COMMON_NAME_INVALID
The certificate is valid, but it doesn't cover the hostname the visitor typed. This usually happens when:
- The site uses a wildcard certificate for
*.example.combut the visitor went toexample.com(the bare apex domain isn't covered by the wildcard). - A subdomain like
blog.example.comis being served with a certificate issued only forexample.com. - The server has multiple sites on one IP, and the wrong default certificate is being served because of a missing or misconfigured Server Name Indication (SNI).
The fix is either to reissue the certificate with a Subject Alternative Name (SAN) that covers the missing hostname, or to switch to a cert that covers both apex and wildcard (example.com + *.example.com). Run SSL Checker on the affected hostname to see exactly what names the certificate covers — the SAN list is right in the report.
ERR_SSL_PROTOCOL_ERROR
The TLS handshake itself failed. Unlike the cert errors above, this isn't usually about the certificate — it's about how the server is configured. Common causes:
- Outdated TLS versions. If the server only supports TLS 1.0 or 1.1, modern browsers will refuse to connect. Both versions are deprecated and have been disabled in Chrome, Firefox, Safari, and Edge since 2020. The fix is to enable TLS 1.2 and TLS 1.3 on the server.
- Cipher suite mismatch. The server is configured to require a cipher suite the browser doesn't support. This is most common on old IIS installs and embedded devices. Update to a modern cipher suite list — Mozilla publishes recommended configurations.
- Listening on the wrong port. If your server is responding on port 443 with plain HTTP instead of HTTPS, the browser sees gibberish and gives up. Make sure your TLS listener is bound to port 443, not the HTTP server.
- CDN or proxy misconfiguration. Cloudflare's "Full (strict)" mode requires a valid origin certificate; if your origin only has a self-signed cert, the connection between Cloudflare and your origin will fail and surface as a protocol error to the visitor.
ERR_CERT_REVOKED
The certificate has been explicitly revoked by the CA. This usually happens after a private key compromise — the legitimate owner asks the CA to revoke the cert so an attacker who stole the key can't use it. Occasionally a CA will mass-revoke certificates due to a misissuance event (this happened with several CAs in 2017–2020).
The fix is to issue a new certificate with a fresh keypair. Don't reuse the old private key — that's what got revoked in the first place. After installing the new certificate, run SSL Checker to verify the new expiry date and serial number.
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM
The certificate uses a signature algorithm browsers no longer trust — usually SHA-1, which was deprecated in 2017. Any cert still using SHA-1 today is many years past its issue date and needs to be replaced. Modern certificates use SHA-256 or SHA-384.
Reissue the certificate from your CA. Free Let's Encrypt certificates have always been SHA-256, so if you switch to them you won't see this error again.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Closely related to ERR_SSL_PROTOCOL_ERROR but more specific — the browser explicitly couldn't agree on a TLS version or cipher suite with the server. This is almost always a server configuration problem.
The simplest fix: deploy Mozilla's "intermediate" SSL configuration. The Mozilla SSL Configuration Generator produces ready-to-paste configs for nginx, Apache, HAProxy, AWS ELB, and other common servers. The "intermediate" preset works for every browser released in the last decade while still being secure. Avoid the "modern" preset unless you genuinely don't need to support older clients — it disables TLS 1.2 and rejects a lot of legitimate traffic.
NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
Since 2018, Chrome (and most modern browsers) require certificates to be logged in public Certificate Transparency logs. If your CA didn't log the certificate, or the SCTs (Signed Certificate Timestamps) aren't being delivered correctly, the browser refuses to trust it.
This is rare today because every reputable CA logs to CT by default. If you see it, contact your CA — they'll reissue the certificate with proper SCTs at no extra charge. Let's Encrypt and DigiCert have logged everything to CT for years.
"This site can't provide a secure connection" (generic)
Sometimes Chrome shows this generic message without an error code. The underlying problem is usually one of the above, but Chrome occasionally won't surface the specific code. To see it, open Chrome DevTools, go to the Security tab, and reload the page — the detailed certificate state will be displayed. Or just run the domain through SSL Checker, which will identify the issue without needing to reproduce it in the browser.
Mixed Content Warnings
Not technically an SSL error — the page loaded over HTTPS — but the browser found resources on the page (images, scripts, stylesheets) being loaded over plain HTTP. Modern Chrome will block scripts and stylesheets outright, and show a "Not secure" indicator in the address bar. Images and media are usually upgraded automatically.
The fix is to update every http:// URL in your HTML, CSS, and JavaScript to https:// — or better, use protocol-relative URLs (//example.com/...) so the resource loads over whatever protocol the page itself used. For legacy sites with a lot of hardcoded URLs, a global find-and-replace in your codebase plus a Content-Security-Policy upgrade-insecure-requests directive will handle most cases.
How to Diagnose When Nothing Else Works
If a browser error doesn't fit any of the above patterns, three diagnostic steps usually surface the root cause:
- Run SSL Checker. It connects directly via PHP using a clean TLS implementation — no browser cache, no extensions, no proxy. If we say the cert is fine, the cert is fine, and the problem is elsewhere (browser, network, OS trust store, intercepting proxy).
- Try a different network. If the error appears on a corporate or hotel network but not on your phone's mobile data, it's a TLS-intercepting proxy injecting an untrusted CA. Not a website problem.
- Try a different browser and device. If Safari is happy but Chrome isn't, you've usually got a missing intermediate (Chrome on macOS doesn't auto-fetch intermediates the way Safari does on the same machine). If iPhone fails but desktop succeeds, almost certainly the same issue.
Stopping SSL Errors Before They Happen
Most SSL errors are preventable. The single biggest improvement you can make is automating renewal — manual renewal is the leading cause of unexpected expiry. Beyond that:
- Always install the full certificate chain (fullchain.pem), never just the leaf.
- Disable TLS 1.0 and 1.1, enable TLS 1.2 and 1.3.
- Use Mozilla's intermediate configuration as a baseline — it solves cipher and protocol issues for free.
- Run a monthly check on every certificate you own. SSL Checker is free and takes about 10 seconds per domain.
- Set up alerting — if you manage many domains, ModusOp can monitor SSL and other domain health metrics across your portfolio.
An expired or misconfigured certificate makes your site invisible — and worse, makes it look hostile. The fixes above are short and well-understood, but only if you catch the problem before visitors do. A regular SSL Checker scan is the cheapest insurance you can buy.