TLS Certificate Warnings and What to Do

NET::ERR_CERT_DATE_INVALID appears when a certificate's validity period has ended. The "Not After" date in the certificate has passed. This warning is typically a server administration error: the administrator forgot to renew the certificate.

An expired certificate provides no security guarantee because the CA has stopped vouching for the certificate's validity. While the site may still be the legitimate site, the certificate infrastructure has broken down.

NET::ERR_CERT_AUTHORITY_INVALID appears when the certificate was signed by a CA not in the browser's trusted root store. This occurs with self-signed certificates, certificates from internal corporate CAs, or certificates from small CAs not included in major root programs.

Browser root programs (Mozilla, Google, Apple, Microsoft) maintain strict lists of trusted CAs. A CA must meet extensive audit requirements to be included. Certificate from non-included CAs trigger this warning.

NET::ERR_CERT_COMMON_NAME_INVALID appears when the certificate's Subject or SAN fields do not match the hostname in the browser address bar. Visiting "https://192.168.1.1" while the certificate says "router.example.com" triggers this warning.

This warning may indicate a misconfigured server, a MITM attack replacing the legitimate certificate with a different one, or a legitimate site accessed by IP address instead of hostname.

A self-signed certificate is one where the issuer and subject are the same: the certificate authority is the server itself. Browsers do not trust self-signed certificates by default because they provide no third-party verification.

Self-signed certificates are commonly used in development environments, internal tools, and testing. They encrypt traffic just as well as CA-signed certificates, but provide no identity assurance.

A revoked certificate warning appears when the CA has invalidated the certificate before its expiry. This typically occurs when the private key was compromised, the organization no longer exists, or the certificate was misissued.

Revocation is checked via OCSP (Online Certificate Status Protocol) or CRL (Certificate Revocation List). Chrome uses CRLSets (preloaded revocation data) for performance, supplemented by real-time OCSP for high-value certificates.

Certificate warnings can generally be bypassed in limited internal and development contexts: your own development server with a self-signed certificate, an internal corporate tool using a company CA not in the public root store, or a home router where you know the IP matches the device.

In these cases, the warning indicates a missing CA, not an attack. You can add the CA to your trust store or accept the specific certificate for that internal context. Document the decision and the reason.

Never bypass certificate warnings for banking, email, health portals, government services, or any site where you will enter credentials or sensitive information. The warning could indicate an active MITM attack.

Even one percent of the time that a certificate warning indicates a real attack, bypassing it for sensitive services creates unacceptable risk. The inconvenience of not accessing the site is far less severe than credential theft or financial fraud.

An attacker performing a MITM attack intercepts your TLS connection and presents their own certificate. If their certificate is not trusted by your browser, you receive a warning. The warning IS the security mechanism working correctly.

Attackers controlling corporate firewalls or compromised routers sometimes inject their own CA to perform TLS inspection without triggering warnings. If you suddenly start seeing certificate warnings on sites you normally trust, investigate immediately.

If you see unexpected certificate warnings on legitimate public websites, report them immediately. For Google properties, use the Chrome feedback button. For other sites, contact the site owner via an alternative channel (phone or different network).

Certificate Transparency logs allow anyone to monitor for unexpected certificates for their domains. Services like Facebook's Certificate Transparency Monitoring notify domain owners when new certificates are issued for their domains.

HTTP Strict Transport Security (HSTS) prevents browsers from accepting certificate errors for enrolled domains. Once a browser has seen an HSTS header, it refuses to connect to that domain over HTTP or with a certificate error, even if the user clicks "proceed anyway".

Sites on the HSTS preload list are hard-coded into browsers, so even a first-ever visit is protected. Preloaded sites can never have certificate warnings bypassed, making MITM attacks against them impractical.

Organizations that run internal CAs should distribute their CA certificate to all corporate devices via mobile device management (MDM) or group policy. This eliminates certificate warnings for internal tools without requiring users to bypass security warnings manually.

Internal CA keys should be stored in HSMs, not on file systems. CA certificates should have limited validity periods and should not be trusted for public internet domains, only for the organization's specific internal name spaces.

Test your understanding of TLS certificate warnings.

Certificate warnings indicate specific problems: ERR_CERT_DATE_INVALID (expired), ERR_CERT_AUTHORITY_INVALID (unknown CA), ERR_CERT_COMMON_NAME_INVALID (hostname mismatch). Each has specific causes and appropriate responses.

Never bypass certificate warnings on banking, email, or health sites. Internal tools with self-signed or internal CA certificates can be safely used after verifying the context. HSTS prevents bypassing warnings on enrolled domains, protecting against MITM attacks.