Troubleshooting the most common SSL errors

A certificate error blocks your visitors immediately, but browser messages don't always make it clear where the problem comes from. Here are the most frequent errors, with their likely cause and the fix to apply.

First, a ten-second diagnosis: run the domain through the SSL checker. It shows the expiration date, the names covered and the issuer.

Expired certificate

Messages: NET::ERR_CERT_DATE_INVALID (Chrome, Edge), SEC_ERROR_EXPIRED_CERTIFICATE (Firefox), "This certificate has expired" (Safari).

Likely causes:

• Automatic renewal failed (Certbot, hosting control panel, CDN).
• The certificate was renewed, but the web server wasn't reloaded and is still serving the old one.
• One of the servers behind the load balancer was forgotten.
• Less often, the visitor's computer clock is wrong.

Fix: renew, reload the service, then check from the outside. The dedicated NET::ERR_CERT_DATE_INVALID guide covers each case in detail.

Name mismatch

Messages: NET::ERR_CERT_COMMON_NAME_INVALID, SSL_ERROR_BAD_CERT_DOMAIN.

The certificate is valid, but not for the requested address. Classic examples:

• The certificate covers example.com but not www.example.com, or the other way around.
• A new subdomain was added without expanding the certificate.
• The server is serving another site's default certificate, because of a wrong server_name or VirtualHost block, or a client too old to send SNI.

Fix: reissue the certificate with every name you need, for example with certbot --nginx -d example.com -d www.example.com, and check your virtual host configuration.

Unrecognized authority or incomplete chain

Messages: NET::ERR_CERT_AUTHORITY_INVALID, SEC_ERROR_UNKNOWN_ISSUER, or in command-line tools unable to get local issuer certificate.

Likely causes:

• The server sends only the certificate, without the intermediates. With Let's Encrypt, it's the classic mistake of using cert.pem instead of fullchain.pem.
• The certificate is self-signed, or issued by a company's internal authority.
• A proxy or antivirus is intercepting traffic on the visitor's machine.

Fix: configure the full chain file, then test:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

The output should list at least two certificates and end with Verify return code: 0 (ok).

The padlock disappears: mixed content

The page is on HTTPS but loads an image, script or font over http://. The browser removes the padlock or blocks the resource. Open the browser console (F12): every offending resource is listed there. Change the URLs to https:// or relative paths. On WordPress, run a search and replace on the database.

Protocol errors

Messages: ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH, SSL_ERROR_NO_CYPHER_OVERLAP.

The browser and the server can't find any protocol or cipher in common. Most often, the server only accepts old protocols, or it's listening on plain HTTP on port 443. Enable TLS 1.2 and 1.3, and check the listen 443 ssl directive and the paths to the certificate files. The SSL security best practices guide provides a reference configuration.

The error only affects some visitors

• Only on mobile or in an app: this is often an incomplete chain. Desktop browsers sometimes fill in missing intermediates themselves; apps and older devices don't.
• Only on a corporate network: a TLS inspection proxy replaces the certificate with its own.
• Only for one visitor: their system date is wrong, or an antivirus is intercepting traffic.
• Only from time to time: one of the servers behind your load balancer is serving a different certificate from the others.

Prevent rather than troubleshoot

Most of these incidents come from a certificate that expires without anyone seeing it coming. Add your domains to SSL Expiration Reminder: the certificate is checked every day, and you're notified before expiry, as well as when a certificate becomes invalid.