ERR_CERT_DATE_INVALID

Every SSL certificate carries an implicit promise: "Trust me until this date." ERR_CERT_DATE_INVALID appears when that date has passed—or hasn't arrived yet. The browser isn't being difficult. It's enforcing a contract.

This is one of the most common TLS errors, and one of the most preventable. Most certificate expirations happen not because anything changed about the certificate or the server, but because someone forgot to renew it. The entire security infrastructure of a website, brought down by a calendar reminder that didn't fire.

The Trust Contract

Every certificate includes two timestamps: "Not Before" and "Not After." For the browser to trust the certificate, the current moment must fall between these dates. Outside that window, trust is revoked.

This isn't arbitrary. Certificates expire because trust must be periodically re-earned. An expired certificate might have a compromised private key that was never detected. The organization behind it might no longer exist. The cryptographic algorithms it uses might have weakened. Expiration forces everyone to prove, again, that they're still who they claim to be.

The industry has steadily shortened certificate lifetimes. Certificates that once lasted five years now max out at 398 days. Let's Encrypt issues 90-day certificates. There's serious discussion of 30-day or even weekly certificates. Shorter lifetimes mean less time for things to go wrong—and more pressure to automate.

Expired: The Common Case

The vast majority of ERR_CERT_DATE_INVALID errors mean the certificate expired and wasn't renewed in time.

The fix is straightforward: get a new certificate. If you're using Let's Encrypt, run certbot renew --force-renewal. For commercial CAs, contact their support for expedited renewal. Once installed, reload your web server and verify the new certificate is being served.

The harder question is why automated renewal failed. DNS changed and broke validation. Firewall rules blocked port 80. The ACME client crashed and nobody noticed. Rate limits were hit during testing. The cron job was on a server that got decommissioned. Certificate expiration is almost always a monitoring failure masquerading as a certificate problem.

Not Yet Valid: The Rare Case

Occasionally the certificate isn't expired—it's not valid yet. The Not Before date is in the future.

This usually means a clock is wrong somewhere. If your server's clock is behind, a freshly issued certificate might appear not-yet-valid. If a client's clock is ahead, valid certificates appear expired. NTP synchronization prevents these issues. Every server touching certificates should have accurate, synchronized time.

Client-Side Clock Errors

Sometimes the certificate is fine and the problem is the user's computer.

A user whose system clock is set to 2027 will see ERR_CERT_DATE_INVALID on every HTTPS site—the certificates all appear expired from the future. A user whose clock is set to 2019 might see certificates that appear not-yet-valid.

If a user reports certificate errors that you can't reproduce, ask them to check their system time. This is more common than you'd think, especially on devices that have been offline for extended periods or have dead CMOS batteries.

Checking Certificate Dates

To see a certificate's validity period, click the padlock in your browser and view certificate details. You'll see "Valid From" and "Valid To" dates.

From the command line:

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

This shows the notBefore and notAfter timestamps. If notAfter is in the past, the certificate has expired.

Preventing Expiration

Certificate expiration is entirely preventable. The formula is simple: automate renewal and monitor for failures.

For Let's Encrypt and other ACME-compatible CAs, Certbot or similar clients handle renewal automatically. Configure a systemd timer or cron job to attempt renewal daily. Certbot only actually renews when certificates are within 30 days of expiration, creating a buffer to catch failures.

Set monitoring alerts at multiple thresholds: 60 days, 30 days, 14 days, 7 days, 1 day. If you're seeing the 7-day alert, something is wrong with automation. If you're seeing the 1-day alert, drop everything.

For multi-server deployments, ensure renewed certificates propagate to all servers. Load balancers terminating TLS need updates too. Test from multiple locations to verify all edges are serving current certificates.

After Renewal

Once you've renewed, verify the fix:

1. Visit the site in multiple browsers and check the padlock
2. Confirm the certificate details show the new expiration date
3. Run SSL Labs (ssllabs.com/ssltest) to verify the certificate is valid
4. Check that monitoring systems see the updated certificate

If you're running multiple servers or a CDN, test from different locations to ensure the new certificate has propagated everywhere.