NET::ERR_CERT_VALIDITY_TOO_LONG: Fix the 398-Day Cap

Problem

Chrome shows Your connection is not private with NET::ERR_CERT_VALIDITY_TOO_LONG. Read that carefully, because it trips people up: the certificate is not expired, the name matches, the chain is intact. Everything about it is fine except one number. Its validity window — the distance from notBefore to notAfter — is longer than browsers now allow. Since Chrome 85, any TLS certificate issued on or after 2020-09-01 that chains to a publicly-trusted CA must have a validity period of 398 days or less (about 13 months). Go one day over and the browser treats the certificate as misissued and refuses it, no matter how healthy everything else looks.

Symptoms

• The full-page interstitial reads NET::ERR_CERT_VALIDITY_TOO_LONG in Chrome and Edge. Safari and Firefox reject the same certificate — they enforce the identical 398-day cap.
• The certificate’s dates are current. This is not ERR_CERT_DATE_INVALID; today falls comfortably inside the validity window.
• Clicking “Advanced” offers no useful “proceed anyway” for a public site — the browser considers the certificate itself non-compliant, not merely untrusted.
• It appears on every network and every fresh profile, because it’s a property of the certificate, not of the connection or a cache.

Top 3 Causes

1. A public-CA certificate minted with a validity span over 398 days - The literal cause. Commercial CAs stopped issuing these years ago, so in 2026 this usually comes from a private intermediate that chains to a publicly-trusted root but was configured to sign long-lived leaves — an internal PKI whose root got cross-signed, an appliance’s built-in sub-CA, or a device management platform issuing two- and three-year certs the old way. Chrome applies the 398-day rule to anything terminating in a public root, wherever in the chain the long lifetime was set.
2. A backdated notBefore - The sneaky one. Some operators backdate notBefore by a few days to survive client clock skew. Do that and then set a forward validity of, say, 397 days, and the total span the browser measures quietly crosses 398. The certificate looks like a one-year cert to a human and reads as too long to the browser. Always measure notAfter minus notBefore, not “how many months from today.”
3. An older long-life certificate still inside its window - Certificates issued before the cutoff with two- or three-year lifetimes were grandfathered only if issued before 2020-09-01. One issued after that date with a legacy lifetime — reused from an internal template, restored from a backup, or generated by firmware that never got the memo — fails the moment it’s served, even years into its life.

Diagnose with DechoNet

• SSL Check reads the certificate on the wire and shows notBefore, notAfter, the issuer, and the chain. Subtract the two dates: if the span is over 398 days and the issuer chains to a public root, you’ve confirmed the cause in one look. It also tells you whether you’re serving what you think you are.
• HTTP Check confirms the endpoint is otherwise healthy once TLS is set aside — useful when you’re reissuing across several edges and need to know the swap actually took on each one.

Resolution Checklist

• Measure the served certificate’s real span: echo | openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN 2>/dev/null | openssl x509 -noout -dates. Compute notAfter − notBefore. If it exceeds 398 days, that’s the whole problem.
• Check for a backdated notBefore. If notBefore sits days before the issuance date, the forward validity plus the backdate may be what pushed the span over. Shorten the forward validity to compensate.
• Reissue with a compliant lifetime. Aim well under the cap — the industry is ratcheting down: CA/Browser Forum ballot SC-081v3 already cut the maximum to 200 days as of 2026-03-15, heading to 100 days in 2027 and 47 days in 2029. A 90-day certificate (Let’s Encrypt-style, auto-renewed) sidesteps every future step of this.
• If the long lifetime came from your own intermediate CA, fix the issuing template — not just this one leaf — or every renewal reproduces the error.
• If an appliance or firmware mints its own long-lived cert you can’t reconfigure, front it with a reverse proxy terminating TLS on a compliant certificate.
• Reinstall and re-verify on every terminating layer — origin, load balancer, CDN edge — then re-run SSL Check and confirm the new span is under 398 days from more than one vantage point.

When to Escalate

• If a commercial, publicly-trusted CA actually issued a leaf with a span over 398 days after the cutoff, that’s a misissuance on their side. Report it — CAs are bound by CA/Browser Forum rules and will want to know.
• If the certificate is minted by hardware you can’t reconfigure (a load balancer appliance, an out-of-band management controller, a printer), stop fighting the device. Put a compliant certificate on a proxy in front of it and let the appliance keep its self-signed cert on the back side.
• If this is an internal-only host and reissuing short is genuinely impractical, distribute the issuing root to the fleet as a manually-trusted CA. That exempts it from the 398-day rule — but it’s a controlled-fleet answer only, never something to reach for on the public internet.