SSL Certificate Errors Explained: Causes and Fixes

An SSL certificate error means the browser could not establish a secure connection it trusts, so it stops and shows a warning instead of your site. The most common causes are an expired certificate (NET::ERR_CERT_DATE_INVALID), a certificate that does not cover the domain name (ERR_CERT_COMMON_NAME_INVALID), a certificate the browser does not trust (ERR_CERT_AUTHORITY_INVALID) and a server that sends an incomplete certificate chain or uses outdated TLS settings. Almost all of them are fixed on the server, and the most common one, expiry, is entirely preventable.

This guide walks through the errors visitors actually see, what causes each one and how to fix it, with commands you can run to check your own site.

Why browsers block the page

When a browser connects over HTTPS, the server presents a certificate. The browser checks three things before it sends anything: that the certificate is within its validity dates, that it was issued for the exact hostname in the address bar, and that it chains back to a certificate authority the browser trusts. If any check fails, the browser shows a full-page warning such as “Your connection is not private”. Most visitors leave at that point. API clients and apps do not show a warning at all; they refuse the connection and your integration breaks.

Browsers name the same problems differently. Here is how the common errors map across them:

Problem	Chrome and Edge	Firefox
Expired or not yet valid	NET::ERR_CERT_DATE_INVALID	SEC_ERROR_EXPIRED_CERTIFICATE
Wrong hostname	NET::ERR_CERT_COMMON_NAME_INVALID	SSL_ERROR_BAD_CERT_DOMAIN
Untrusted issuer or self-signed	NET::ERR_CERT_AUTHORITY_INVALID	SEC_ERROR_UNKNOWN_ISSUER
Protocol or cipher problem	ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH	SSL_ERROR_NO_CYPHER_OVERLAP

Safari shows “This Connection Is Not Private” for most of these, with the details behind “Show Details”.

First, look at the certificate yourself

Before fixing anything, check what the server actually sends. This command shows the certificate’s validity dates, subject and the hostnames it covers:

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

The -servername flag matters. Servers that host several sites pick the certificate based on the name the client asks for, and without it you may see the wrong one. To see the whole chain the server sends, add -showcerts to the first command.

NET::ERR_CERT_DATE_INVALID

The certificate is outside its validity period. Nearly always that means it expired. Less often, the visitor’s computer clock is wrong, which makes a valid certificate look expired or not yet valid.

Typical causes on the server side:

• Automatic renewal stopped working after a server move, a change of web server or a DNS change that broke domain validation.
• The certificate was renewed, but the web server was never reloaded, so it still serves the old one from memory.
• The certificate was issued by hand a year ago for a subdomain everyone forgot.
• A load balancer, CDN or second server still holds the old certificate while the main server has the new one.

Fix: renew the certificate, install it everywhere it is served and reload the service. With Certbot, a dry run tells you whether renewal works before it matters:

sudo certbot renew --dry-run
sudo systemctl reload nginx

Then check the served certificate again with the openssl command above. The file on disk is not what visitors see; the served certificate is.

If only one visitor reports the error and the certificate is valid, ask them to check the date and time on their device.

NET::ERR_CERT_COMMON_NAME_INVALID

The certificate is valid, but not for this hostname. Browsers compare the address bar with the names listed in the certificate’s Subject Alternative Name field.

Common causes:

• The certificate covers northwind.shop but not www.northwind.shop, or the other way around.
• A wildcard certificate for *.northwind.shop is used on shop.eu.northwind.shop. A wildcard covers one level only.
• A new subdomain was pointed at a server that serves a default certificate for a different site.
• A DNS record points to the wrong server, for example an old host or a CDN that has no certificate for your domain.

Fix: issue a certificate that lists every hostname you serve, or a separate one per hostname, and check that each server block or virtual host uses the right one. If the hostname should not be served at all, remove its DNS record.

NET::ERR_CERT_AUTHORITY_INVALID

The browser does not trust whoever signed the certificate. Causes:

• A self-signed certificate, often left over from staging or from the default installation of a control panel.
• A certificate from a private or internal certificate authority used on a public site.
• An incomplete chain on some clients, see below.
• Something between the visitor and the server intercepting the connection, such as a corporate proxy or antivirus software. In that case only some visitors see the error.

Fix: replace self-signed and internal certificates on public sites with one from a publicly trusted certificate authority. Free certificates from Let’s Encrypt and similar services are trusted by all major browsers.

Incomplete certificate chain

Your certificate is signed by an intermediate certificate, which is signed by a root the browser trusts. The server must send your certificate and the intermediate. If it only sends your certificate, the result depends on the client: some desktop browsers fetch the missing intermediate themselves and show no error, while other browsers, mobile apps, curl and API clients fail. That is why this problem often surfaces as “works for me, broken for the payment provider’s webhooks”.

curl reports it like this:

curl: (60) SSL certificate problem: unable to get local issuer certificate

Fix: configure the server with the full chain file. With Certbot on nginx that means fullchain.pem, not cert.pem:

ssl_certificate     /etc/letsencrypt/live/northwind.shop/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/northwind.shop/privkey.pem;

ERR_SSL_PROTOCOL_ERROR and cipher mismatches

These errors mean the browser and server could not agree on how to talk securely, before any certificate check happened. Causes include a server that only offers old protocol versions such as TLS 1.0 and 1.1, which current browsers no longer accept, a misconfigured port that speaks plain HTTP on 443, a broken TLS configuration after an upgrade, or a firewall or proxy interfering with the handshake.

Fix: enable TLS 1.2 and TLS 1.3, use the modern cipher defaults of your web server or a trusted configuration generator, and check that port 443 is actually serving TLS. You can test a specific protocol version with openssl:

openssl s_client -connect northwind.shop:443 -servername northwind.shop -tls1_2

Mixed content

Mixed content is not a certificate error, but visitors often experience it as one. The page loads over HTTPS, but some resources, such as scripts, images, stylesheets or iframes, are requested over plain HTTP. Browsers block insecure scripts and frames outright, which can break the layout or functionality, and may show the page without the usual secure indicator.

Fix: change hard-coded http:// URLs in your templates, database and settings to https:// or relative URLs. On WordPress, mixed content often comes from old URLs stored in post content after a move to HTTPS. As a safety net, the Content-Security-Policy: upgrade-insecure-requests header tells browsers to request those resources over HTTPS instead.

Preventing certificate errors

Most certificate errors are configuration mistakes you fix once. Expiry is different: it comes back every time a certificate reaches the end of its life, and it tends to strike when the person who set up renewal has moved on. Prevention is a routine, not a one-off fix:

1. Keep an inventory. List every hostname that serves HTTPS, including APIs, admin panels, staging and client sites.
2. Automate renewal wherever you can, and know where it is still manual.
3. Check the served certificate after every change. Server moves, new load balancers and DNS changes are when renewals break.
4. Monitor expiry dates so you get a reminder weeks before a certificate runs out, while there is time to fix a failing renewal calmly.
5. Watch the domain and its records too. A lapsed domain or a changed DNS record breaks validation and the site with it.

Uptimecheck SSL monitoring tracks the expiry date of the certificate served on each domain and subdomain and sends reminders to your alert channels before it expires. It is included on every plan. Pair it with domain expiry monitoring and DNS monitoring, since a certificate is only as reliable as the domain and records behind it. Our guide on SSL certificate expiry monitoring has a full renewal checklist, and if the browser cannot even find your site, read about DNS_PROBE_FINISHED_NXDOMAIN.

Summary

Every SSL error is the browser refusing to trust a connection: because the certificate is out of date, issued for another name, signed by someone it does not know, sent without its chain, or offered over a protocol it no longer accepts. Check the served certificate with openssl, fix the configuration, reload the server and check again. Then make expiry a reminder instead of an incident.

Uptimecheck reminds you before certificates and domains expire and alerts you when your site stops answering. Try it free for 14 days, no credit card required.