Common SSL Errors and How to Fix Them

The short answer: five typical errors

The exact messages differ between browsers, but the causes are the same.

Start by checking what the server actually serves:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

It shows which names the certificate covers, who issued it and when it expires.

1. Expired certificate

How to tell: the notAfter date in the output above is in the past.

Fix:

• renew the certificate (for Let's Encrypt, sudo certbot renew);
• reload the web server — a common situation is a new file on disk while the server keeps serving the old one from memory;
• set up automatic renewal and external expiry monitoring.

If only one user sees the error, check the date and time on their device: a wrong clock produces the same message.

2. Name mismatch

How to tell: the subjectAltName list does not include the name the visitor opened. Classic case: the certificate is for example.com, but people visit www.example.com.

Fix:

• reissue the certificate with every name you need: -d example.com -d www.example.com;
• remember that a wildcard *.example.com covers neither example.com itself nor nested names like a.b.example.com;
• if several sites share an IP, make sure each server_name has its own certificate: on a mismatch the server falls back to the default site's certificate.

3. Incomplete certificate chain

How to tell: the site works in a desktop browser but fails on some phones, in curl or in integrations with errors like "unable to get local issuer certificate". Browsers sometimes complete the chain themselves; other clients do not.

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

If the output shows only one certificate, the intermediate is missing.

Fix: point your config at the full-chain file. For Let's Encrypt that is fullchain.pem. For a paid certificate, concatenate your certificate and the CA's intermediate into one file — yours first, then the intermediate.

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

4. Mixed content

How to tell: the certificate is fine, but the browser flags the page and the developer console shows Mixed Content warnings. An HTTPS page loads images, scripts or styles over http://.

Fix:

• change links to https:// or relative paths;
• in a CMS, update the site address in settings and replace old URLs stored in the database;
• as a temporary safety net, add this header:

add_header Content-Security-Policy "upgrade-insecure-requests";

It asks the browser to load resources over HTTPS, but a resource that is not available over HTTPS will still fail.

5. Redirect loops

How to tell: ERR_TOO_MANY_REDIRECTS. Trace the chain:

curl -sIL http://example.com | grep -i -E "^(HTTP|location)"

Typical causes:

• A CDN or proxy in "Flexible" mode (for example, in Cloudflare): the visitor arrives over HTTPS, the proxy talks to your server over HTTP, the server redirects to HTTPS — and round it goes. Fix: install a certificate on the server and switch to Full (strict).
• An app behind a proxy doesn't see HTTPS. Pass the X-Forwarded-Proto header and configure the app to trust it.
• Redirects configured in two places — the web server and a CMS or plugin — that contradict each other (for example, www versus non-www). Keep one rule.