SSL certificate errors and what each one actually means

A certificate error is one of the few failures that stops every visitor with a full-page warning. There are only about five distinct causes, and each has a specific fix.

The errors

NET::ERR_CERT_DATE_INVALID - expired

The certificate's validity window has passed. Since 2020 the maximum lifetime has been 398 days, and the industry is moving shorter still, so manual renewal is no longer viable.

Fix: automate it. Let's Encrypt certificates last 90 days and every ACME client renews at 60. If you are renewing by hand, you will eventually forget, usually on a weekend.

NET::ERR_CERT_COMMON_NAME_INVALID - wrong hostname

The certificate does not cover the name in the address bar. Usually a certificate issued for example.com being served at www.example.com, or vice versa.

Fix: issue for both names, or use a wildcard. Note that a wildcard for *.example.com covers www.example.com but not example.com itself, and not a.b.example.com - wildcards match exactly one label.

NET::ERR_CERT_AUTHORITY_INVALID - untrusted issuer

The browser cannot build a chain from your certificate to a root it trusts. Almost always an incomplete chain: the server is sending the leaf certificate but not the intermediate.

This is the sneakiest error because it often works in your browser and fails elsewhere. Desktop browsers cache intermediates they have seen before, so your machine succeeds while a fresh device fails. Server-side clients - curl, mobile apps, other people's backends - fail immediately.

Fix: serve the full chain, leaf first then intermediates. Most tools call this the "fullchain" file.

ERR_SSL_PROTOCOL_ERROR - protocol mismatch

The client and server share no protocol version or cipher. Since TLS 1.0 and 1.1 were removed from browsers in 2020, this usually means a server still pinned to old protocols.

Fix: enable TLS 1.2 and 1.3. Disable everything below 1.2.

Mixed content warnings

The page loads over HTTPS but references an HTTP resource. Browsers block scripts and stylesheets outright and warn about images.

Fix: make every internal reference protocol-relative or absolute HTTPS. Content-Security-Policy: upgrade-insecure-requests is a useful stopgap, not a fix.

What to check before it breaks

• Expiry - with enough margin to react. Alert at 21 days, not 2.
• Chain completeness - test from a machine that has never visited the site.
• Hostname coverage - every name you actually serve, including the apex if you use a wildcard.
• Redirect behaviour - http:// should reach https:// in exactly one hop.

The SEO angle

HTTPS has been a lightweight ranking signal since 2014. The bigger effect is behavioural: a full-page browser warning drives essentially all traffic away, and if Googlebot hits an invalid certificate it can drop the page from the index entirely.

Two configuration details matter more than the certificate itself:

Redirect http to https in one hop, at the apex level. http://example.com → https://example.com directly, not via http://www.example.com. Every extra hop costs crawl budget.

Set HSTS once you are confident. Strict-Transport-Security: max-age=31536000; includeSubDomains tells browsers never to try HTTP again, which removes the redirect entirely for repeat visitors. Do not enable it until you are certain every subdomain has a valid certificate - the header is difficult to unwind.