SSL/TLS Certificate Errors Explained: A Troubleshooting Guide

Browsers show a full-page, red-triangle warning for certificate problems on purpose - it's meant to be alarming enough that nobody clicks through on autopilot. But underneath the scary interstitial, almost every certificate error falls into one of four causes, and each one has a specific, findable fix.

NET::ERR_CERT_DATE_INVALID - Expired or Not-Yet-Valid

Certificates have a fixed validity window, and this error fires the moment the current date falls outside it. The most common real-world cause by far is a broken renewal automation - Let's Encrypt certificates, which now cover most of the web, are only valid for 90 days specifically to force renewal to be automated rather than a manual calendar reminder someone eventually forgets. When the cron job or renewal hook silently stops running (a server migration, a changed file path, a permissions issue), nothing fails loudly until the certificate actually expires.

A less common but genuinely confusing variant: the error can also fire if the client's system clock is wrong, not the certificate. Worth ruling out first if a certificate that should still be valid is throwing this error for one specific visitor and nobody else.

NET::ERR_CERT_COMMON_NAME_INVALID - Hostname Mismatch

A certificate is issued for specific hostnames, listed in its Subject Alternative Name (SAN) field - the old Common Name field is effectively deprecated and modern browsers ignore it entirely. This error means the domain in the address bar isn't in that list. The two ways this usually happens: a certificate issued for example.com being served on www.example.com (or vice versa) without both listed as SANs, or a wildcard certificate for *.example.com not covering a second-level subdomain like api.staging.example.com - a single wildcard level only covers one segment deep.

NET::ERR_CERT_AUTHORITY_INVALID - Incomplete Chain or Untrusted Issuer

A browser doesn't just trust your certificate directly - it verifies a chain from your certificate up through one or more intermediate certificates to a root that's already baked into the operating system or browser's trust store. This error means that chain is broken, and it has two distinct causes that get fixed completely differently:

• Missing intermediate certificate.The server is only serving the leaf certificate, not the intermediate(s) that link it to a trusted root. This is the classic "works in some browsers, breaks in others" case - some browsers cache intermediates they've seen before and can complete the chain anyway, which is exactly why it's easy to miss in your own testing and only get reported by users on a device that's never seen that intermediate.
• Self-signed or internal CA certificate in production.Fine for local development, but a certificate not issued by a publicly trusted CA will never validate in a normal visitor's browser, regardless of how correctly everything else is configured.

Mixed Content Warnings

Not a certificate error technically, but it shows up in the same padlock-icon area and gets confused with one constantly. Mixed content means a page loaded over HTTPS is pulling in a subresource - an image, script, or stylesheet - over plain HTTP. Browsers block active mixed content (scripts, stylesheets) outright and warn on passive mixed content (images). It's almost always leftover from a migration to HTTPS where a handful of hardcoded http:// URLs in the database or codebase never got updated.

How to Diagnose Quickly

openssl s_client -connect example.com:443 -servername example.com from a terminal dumps the full certificate chain the server is actually presenting, including which intermediates are (or aren't) included - the fastest way to confirm a chain problem without guessing from browser behavior alone. Clicking the padlock icon in any browser and viewing the certificate details will show the exact SAN list and expiry date, which resolves most hostname and expiry questions in a few seconds.

Preventing Recurrence

The recurring theme across all of the above is that certificate problems are almost never a one-time configuration mistake - they're a monitoring gap that eventually surfaces as an outage. Automated renewal removes the expiry failure mode but doesn't remove the risk of the automation itself silently breaking. Redirecting all HTTP traffic to HTTPS at the server level prevents mixed content from creeping back in after a migration. And checking your certificate chain and expiry window on a recurring schedule - not just when someone reports a warning - is what actually catches a renewal failure before it becomes a full outage instead of after.

A security scan checks certificate validity, expiry window, and chain completeness alongside the rest of your security header posture, so a renewal failure shows up as a flagged finding well before it becomes a production incident. See our security headers guide for the rest of what a scan like that checks.