Skip to content

NET::ERR_CERT_VALIDITY_TOO_LONG: Fix Guide

Key idea:

NET::ERR_CERT_VALIDITY_TOO_LONG appears when an SSL certificate is issued for > 398 days. Since September 2020, Apple, Google and Mozilla reject certs longer than that — per Baseline Requirements 1.7.3. Fix: reissue with validity ≤ 397 days (Let's Encrypt = 90 days, always fits).

This error blocks HTTPS access. Below: causes, fixes, working config, FAQ.

Check your site's SSL →

Common Causes

  • Cert issued for 2+ years (legacy practice before September 2020)
  • Commercial CA delivered an "extended validity" cert bypassing the limit
  • Self-signed cert with days=10000 — a common admin mistake
  • Legacy certificate reissued with old parameters
  • Firewall/proxy replaced the cert with a long-validity one

Step-by-Step Fix

  1. Reissue the certificate: certbot renew --force-renewal
  2. For self-signed: openssl req -x509 -days 365 (not 3650!)
  3. Ask your commercial CA for a 1-year cert — 2-year ones were pulled in 2020
  4. Check the actual validity via Enterno SSL Checker — Not Before → Not After
  5. Corporate proxy: exclude your domain from SSL inspection

Check SSL Certificate →

Example: Proper nginx TLS config

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;

    ssl_stapling        on;
    ssl_stapling_verify on;
}

Related SSL Errors

TL;DR

The ERR_CERT_VALIDITY_TOO_LONG error occurs when an SSL/TLS certificate exceeds the maximum validity period of 398 days. To resolve this, you should replace the certificate with a new one that complies with the latest standards set by the CA/Browser Forum, ensuring it is valid for no more than 398 days. Regularly monitoring and renewing your certificates can help avoid this error.

Understanding ERR_CERT_VALIDITY_TOO_LONG

The ERR_CERT_VALIDITY_TOO_LONG error is a warning generated by web browsers when an SSL/TLS certificate exceeds the maximum allowed validity period. As of September 2020, the CA/Browser Forum has mandated that SSL certificates must not be valid for more than 398 days. This regulation aims to enhance security by encouraging more frequent certificate renewals, making it harder for compromised certificates to remain valid for long periods.

When a certificate exceeds this validity period, browsers like Chrome, Firefox, and Safari will display an error message, preventing users from accessing the website. This can significantly impact user experience and website credibility.

To avoid this error, it is essential for web administrators and developers to regularly check the validity of their SSL certificates and plan for timely renewals. Using automated tools can help in maintaining compliance with these standards.

How to Fix ERR_CERT_VALIDITY_TOO_LONG

To resolve the ERR_CERT_VALIDITY_TOO_LONG error, you need to identify and replace any certificates that exceed the 398-day limit. Here’s a step-by-step guide:

  1. Check Current Certificate Validity: Use the following command in your terminal to check the expiration date of your SSL certificate:
openssl x509 -in /path/to/your/certificate.crt -noout -dates

This command will output the start and end dates of your certificate's validity. If the end date is more than 398 days from the current date, you need to replace the certificate.

  1. Generate a New Certificate: If your certificate is nearing expiration or is invalid due to the ERR_CERT_VALIDITY_TOO_LONG error, generate a new certificate with a validity of less than 398 days. Depending on the Certificate Authority (CA) you choose, this may involve the following command:
certbot certonly --standalone -d yourdomain.com --preferred-challenges http --renew-by-default

Ensure you have the necessary permissions and configurations for your web server when using Certbot or any other tool.

  1. Install the New Certificate: After obtaining the new certificate, install it on your web server. The installation process will depend on your server type. For example, if you are using Apache, you would typically edit your configuration file as follows:
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

Be sure to restart your web server after making these changes:

sudo systemctl restart apache2
  1. Verify Installation: Use the following command to verify that the new certificate is correctly installed and check its validity period:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Ensure that the certificate's validity is within the acceptable limits. You can also use online tools such as SSL Labs' SSL Test to confirm the installation.

  1. Set Up Monitoring: To prevent future occurrences of the ERR_CERT_VALIDITY_TOO_LONG error, consider implementing a monitoring solution that checks your SSL certificate's validity. Tools like Certify The Web or other SSL monitoring services can alert you before your certificate approaches its expiration date.

By following these steps, you can effectively manage your SSL certificates and ensure compliance with current validity standards, thus avoiding the ERR_CERT_VALIDITY_TOO_LONG error.

CertificateExpiry, issuer, domains (SAN)
ChainIntermediate and root CA validation
TLS ProtocolTLS version and cipher suite
VulnerabilitiesHeartbleed, POODLE, weak ciphers

Why teams trust us

TLS 1.3
supported
Full
CA chain check
<2s
result
30/14/7
days-to-expiry alerts

How it works

1

Enter domain

2

TLS chain verified

3

Expiry date & vulnerabilities

What Does the SSL Check Cover?

SSL/TLS is the encryption protocol that protects data between the browser and server. Our tool analyzes the certificate, chain of trust, TLS version, and knownvulnerabilities.

Certificate Details

Issuer, validity period, signature algorithm, covered domains (SAN), and validation type (DV/OV/EV).

Chain of Trust

Full chain verification: from leaf certificate through intermediates to root CA.

TLS Analysis

Protocol version (TLS 1.2/1.3), cipher suites, Perfect Forward Secrecy (PFS) support.

Expiry Alerts

Set up a monitor — get Telegram and email alerts 30/14/7 days before expiration.

DV vs OV vs EV Certificates

DV (Domain Validation)
  • Confirms domain ownership only
  • Issued in minutes automatically
  • Free via Let's Encrypt
  • Suitable for most websites
  • Most common certificate type
OV / EV
  • Organization (OV) or Extended Validation (EV)
  • Issued in 1-5 business days
  • Costs $50 to $500/year
  • For finance, e-commerce, government sites
  • Increases user trust

Who uses this

DevOps

SSL certificate monitoring

Security

TLS config audit

SEO

HTTPS as ranking factor

E-commerce

customer trust

Common Mistakes

Expired certificateBrowsers block sites with expired SSL. Set up auto-renewal or monitoring.
Incomplete certificate chainWithout intermediate CA, some browsers and bots cannot verify the certificate.
Mixed content on HTTPS siteHTTP resources on an HTTPS page — the browser lock icon disappears, reducing trust.
Using TLS 1.0/1.1Legacy TLS versions have known vulnerabilities. Use TLS 1.2+ or 1.3.
Domain mismatch in certificateThe certificate must cover all site domains, including www and subdomains.

Best Practices

Set up auto-renewalLet's Encrypt + certbot with cron — certificate renews automatically every 60-90 days.
Enable HSTSStrict-Transport-Security header forces browsers to always use HTTPS.
Use TLS 1.3TLS 1.3 is faster (1-RTT handshake) and safer — legacy ciphers removed.
Monitor expiration datesCreate a monitor on Enterno.io — get notified well before expiration.
Verify chain after renewalAfter certificate renewal, confirm that intermediate certificates are installed.

Get more with a free account

SSL certificate monitoring, check history and alerts 30 days before expiry.

Sign up free

Learn more

Sources

Frequently Asked Questions

Why did Apple/Google/Mozilla cap the validity?

Shorter certs force more frequent reissuance → lower key-compromise risk and faster retirement of vulnerable certs.

Why exactly 398 days?

That is 13 months + renewal buffer. Apple introduced the cap in 2020: max 398 days. Google and Mozilla followed.

Can I bypass it with Chrome flags?

No. This is a built-in safetynet policy, not toggleable.

Let's Encrypt's 90 days is annoying, alternatives?

ZeroSSL, Buypass — free alternatives with 90-day certs. Commercial (DigiCert, Sectigo) — 1 year. All ≤ 398 days.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.