NET::ERR_CERT_VALIDITY_TOO_LONG: How to Fix Certificate Lifetime

NET::ERR_CERT_VALIDITY_TOO_LONG is Chromium net error -213, "The certificate's validity period is too long." Chrome computes notAfter minus notBefore of the server certificate and compares it with the maximum lifetime allowed on the date the certificate was issued (its notBefore). It is a certificate-verification error in the TLS handshake. It is not expiry (ERR_CERT_DATE_INVALID), not a name mismatch and not related to your system clock, because only the two dates inside the certificate are compared.

Chromium applies these limits, taken from its source code:

The 200, 100 and 47-day steps follow CA/Browser Forum ballot SC-081v3 and were added to Chromium in September 2025. Two conditions matter: the check runs only for certificates that chain to a publicly trusted root (is_issued_by_known_root), and a certificate with a notBefore later than its notAfter is flagged too. Certificates from private or enterprise CAs are never checked.

Publicly trusted CAs are not allowed to issue over-long certificates, so this error is rare and can point to one of three things: a certificate issued with an outdated product setting just after a deadline (for example a "1-year" certificate dated after 15 March 2026), a mis-issued certificate that the CA should revoke and replace, or a certificate with broken dates. Apple counts 398 days as 398 periods of 86,400 seconds, and any time beyond that is an extra day.

Self-signed certificates, internal CAs, and the certificates generated by antivirus or corporate TLS inspection do not chain to a public root, so a 10-year internal certificate never produces this code. If such a certificate fails, you will see a trust error such as ERR_CERT_AUTHORITY_INVALID instead.

The browser judges the certificate served by whatever terminates TLS. On a Cloudflare-proxied hostname that is Cloudflare's edge certificate, which Cloudflare issues within the limits, so your origin certificate is not what visitors see. The relevant proxy check is the opposite case: a hostname set to DNS-only, a second load balancer, or an old node still serving a certificate you replaced elsewhere.

# compare what each backend or edge IP really serves
for ip in 203.0.113.10 203.0.113.11; do
  echo "== $ip"
  openssl s_client -connect $ip:443 -servername example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -serial -startdate -enddate
done

Every node should return the same serial and dates. If one differs, update the certificate on that node (nginx ssl_certificate, HAProxy crt, the load balancer listener).

1. Measure the lifetime of the deployed certificate.

   openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
     | openssl x509 -noout -startdate -enddate > dates.txt
   start=$(grep notBefore dates.txt | cut -d= -f2)
   end=$(grep notAfter dates.txt | cut -d= -f2)
   echo $(( ($(date -d "$end" +%s) - $(date -d "$start" +%s)) / 86400 )) days

   Compare the result with the limit for its notBefore date in the table above (GNU date syntax).
2. Ask the CA to reissue within the limit. A certificate issued now (October 2026) may last at most 200 days. A CA that delivered more has mis-issued; request a replacement and, if needed, a revocation of the old one.
3. Automate renewals. With 100-day certificates from 15 March 2027 and 47-day certificates from 15 March 2029, manual yearly renewals stop working. Use ACME (certbot, acme.sh, Caddy, cert-manager) and check that the renewal hook reloads the server.
4. Keep internal names on an internal CA. If you need multi-year certificates for devices, issue them from a private CA that browsers trust through enterprise policy; the lifetime check does not apply there.
5. Deploy and reload on every node: nginx -t && systemctl reload nginx.

Certificates issued before 15 March 2026 with up to 398 days remain valid until they expire, so there is no need to replace a compliant certificate early.

This is a server-side certificate problem; a visitor cannot fix it.

• Changing the system clock, clearing the cache or switching DNS does not help, because Chrome compares two dates written inside the certificate.
• Another network will not help either, unless a different network reaches a different server that has a valid certificate.
• Do not enter passwords or payment data after clicking through any certificate warning. Tell the site owner the exact code; it tells them precisely what to reissue.

Re-run the lifetime calculation against the live host and confirm the number of days is within the limit for the notBefore date, then reload the page in Chrome in a new tab. For an external view of the dates, issuer and chain, check the hostname with the enterno.io SSL checker.

• ERR_CERT_DATE_INVALID: expired or not yet valid
• ERR_CERT_INVALID: other malformed certificates
• ERR_CERT_AUTHORITY_INVALID: untrusted issuer
• How to renew a Let's Encrypt certificate
• How to rotate an SSL certificate