net::err_cert_date_invalid: Why It Happens and How to Fix It

• 28 June 2026
• by: Idris Mensah
• in: SSL Certificates
• Tags: cert date invalid, expired certificate, ssl error
• note: no comments

You went to load a site and instead of the page you got a full-screen red warning and the string `net::err_cert_date_invalid`. It feels like the site is broken or dangerous, but stay calm — in almost every case this is one of two very ordinary problems, and both are quick to sort out once you know which one you’re looking at.

Let me walk you through exactly what the browser is complaining about, the two halves of this error, and how to fix it methodically — whether you own the site or you’re just trying to visit it.

Key Takeaways
• `net::err_cert_date_invalid` means the SSL/TLS certificate is outside its valid date range — either the certificate has expired (you’re past its end date) or it’s not yet valid (you’re before its start date), so the browser refuses to trust it.
• For site owners, the number-one cause is a certificate that genuinely expired because a renewal was missed.
• For a single visitor, the number-one cause is the device’s clock being wrong — a phone or PC set to the wrong date will reject a perfectly current certificate as “expired” or “not yet valid.”
• One test sorts it instantly: does the error happen on other devices and networks too? Yes = the certificate expired (the owner must renew). No = your clock is wrong (fix your date).
• The permanent fix for owners is automatic renewal (AutoSSL or certbot) so a certificate can never silently lapse again.

What does net::err_cert_date_invalid actually mean?

Every SSL/TLS certificate has a built-in shelf life. When a certificate is issued, it’s stamped with two timestamps: a “valid from” date (when it starts being trusted) and a “valid to” date (when it stops). Between those two dates, the certificate is good. Outside of them, it isn’t.

When your browser connects to a site over HTTPS, one of the checks it performs is dead simple: is right now between the certificate’s start date and its end date? It compares the certificate’s two timestamps against the current date and time. If “now” falls inside the window, that check passes. If “now” falls outside the window — on either side — the browser stops, blocks the connection, and shows you `net::err_cert_date_invalid`.

The error is not saying the certificate is fake or that the site is malicious. It’s saying the certificate’s dates and the current time don’t line up.

What are the two halves of this error?

This is the key distinction, and it’s why the same error code can have two completely different fixes. A date can be wrong in two directions:

1. Expired — past the end date. The certificate’s “valid to” date is in the past. The certificate was fine, but its window closed. This is overwhelmingly what’s happening when a real, live website starts throwing the error for everyone.

1. Not yet valid — before the start date. The current time is *earlier* than the certificate’s “valid from” date. A correctly issued certificate that started yesterday shouldn’t look not-yet-valid to anyone — so when you see this half, it almost always means the device’s clock is set too far in the past, not that the certificate is wrong.

Both directions produce the same `net::err_cert_date_invalid` string, so you can’t tell from the error code alone which half you’re dealing with. You have to look at *who* is seeing it — which we’ll get to.

What causes net::err_cert_date_invalid?

There are four realistic causes, and they sort neatly into “owner problems” and “visitor problems.”

1. The certificate genuinely expired (the #1 cause for site owners). Certificates don’t last forever — many today are valid for a year or less — and someone forgot to renew before the end date passed. The moment the clock ticks past “valid to,” every visitor starts getting blocked.

1. The visitor’s device clock is wrong (the #1 cause for a single visitor). TLS validates the certificate against *your device’s* current date and time. If your phone or laptop has the wrong date — set months in the past, stuck in the future, or simply never synced — a perfectly valid, current certificate will look “expired” or “not yet valid” to that one machine, even though it’s flawless for everyone else.

1. Auto-renewal failed silently. The owner set up automatic renewal, but it broke — a cron job stopped running, a domain-validation check failed, or a configuration changed — and nobody noticed until the old certificate expired. The intent was right; the automation lapsed.

1. The wrong certificate is installed. During setup or migration, an old or mismatched certificate file got installed on the server, and its dates don’t match a currently valid one. This is less common but worth checking when a renewal “didn’t take.”

Is it everyone, or just you?

Before you change a single setting, run the one test that tells you everything. Try the same site on a different device and a different network — a phone on mobile data instead of your home Wi-Fi is perfect, because it’s a separate clock and a separate connection.

• If it fails everywhere — other devices, other networks, other people — the certificate itself is the problem. It has genuinely expired (or the wrong one is installed). This is the owner’s job to fix.
• If it fails only on your one device but works fine elsewhere, the site is healthy and the problem is local to your machine. The culprit is almost always your clock.

This single test saves you from “fixing” your own settings when a site is actually down, and from emailing a site owner when your own laptop just needs the right date. Do this first, every time.

How do I fix net::err_cert_date_invalid as a visitor?

If the site works on other devices but not yours, the fix lives on your machine. Work through these in order.

1. Check and fix your device’s date and time — this is the big one. Open your clock settings and look hard at the actual date, not just the time. A date set to the wrong year, or stuck weeks in the past, is the single most common reason one device sees this error.

1. Set your clock to update automatically. Turn on “set time automatically” and “set time zone automatically.” This lets your device sync from a network time server so it stays accurate going forward — and it stops the problem from coming back. On most systems this is a single toggle in date and time settings.

1. Restart after correcting the clock. A quick reboot, or at least fully closing and reopening the browser, makes sure the corrected time is picked up everywhere.

1. Clear your browser cache. Browsers can cache a certificate state. After fixing the clock, clear cached files (or open the site in a private/incognito window) so the browser re-checks the certificate fresh.

1. Try another device to confirm. If the site already worked on your phone in the “is it everyone or just you” test, and now works on your computer after fixing the clock, you’re done — it was the date all along.

If you’ve corrected the date, your clock is syncing automatically, and the error still appears on every device, then it isn’t your machine — the certificate has expired and only the site’s owner can fix it.

How do I fix net::err_cert_date_invalid as a site owner?

If the error shows up for everyone, your certificate is outside its valid window. Here’s the methodical fix.

1. Confirm the expiry. Check the certificate’s validity dates — you can view them by clicking the warning details in a browser, or by querying the certificate on the server. Confirm that “valid to” is in the past (expired) rather than chasing a different issue. If your renewal-error pattern looks unfamiliar, is a useful cross-reference.

1. Renew the certificate. Issue a fresh certificate for the domain. With a free Let’s Encrypt certificate this is a renewal command or a click in your hosting panel; with a paid certificate it’s a renewal through your provider. For a full walkthrough, see .

1. Install the new certificate correctly. Replace the expired certificate on the server with the newly issued one, including the full chain. Don’t leave the old file in place — an expired certificate sitting next to a new one is exactly cause #4 above.

1. Set up automatic renewal so this never recurs. This is the real fix. Configure AutoSSL (in cPanel-style hosting) or certbot’s renewal timer so certificates renew themselves well before the end date. A renewal you have to remember is a renewal you will eventually forget. covers how the automated approach works.

1. Verify the fix from the outside. After installing, load the site in a fresh private window (and ideally a second device) and confirm the padlock appears with no warning. Re-check the new “valid to” date so you know exactly when the next renewal is due — though if auto-renewal is working, you shouldn’t have to think about it.

Cause and fix at a glance

Cause	Who usually sees it	Fix
Certificate genuinely expired	Everyone, on every device	Renew the certificate and reinstall the new one
Auto-renewal failed silently	Everyone, on every device	Renew now, then repair the AutoSSL/certbot automation
Wrong certificate installed	Everyone, on every device	Install the correct, currently valid certificate with full chain
Device clock is wrong	Only one device	Fix the date/time and set it to update automatically

Here’s the insight that makes this error easy to diagnose every single time: `net::err_cert_date_invalid` splits perfectly by who sees it. TLS validates a certificate against the *device’s* current date and time, which means the same error code can come from two opposite places. If everyone gets it on your site, the certificate genuinely expired and the owner must renew — and set up auto-renewal so it never lapses again. But if only one person sees it, the culprit is almost always *that device’s* wrong clock, because a phone or PC set to the wrong date will reject a perfectly valid, current certificate as “expired” or “not yet valid.” One test sorts it instantly: does it fail on other devices and networks too? Yes = expired cert, renew it. No = your clock is wrong, fix the date. Certificates have a shelf life, and so does your device’s idea of “now” — this error is simply where those two disagree.

How DarazHost keeps this error from ever happening

The frustrating thing about `net::err_cert_date_invalid` for site owners is that the #1 cause — a forgotten renewal — is entirely preventable. That’s exactly what DarazHost’s free AutoSSL is built to handle: it automatically renews your certificates well before they expire, so the certificate behind your site is always current. The “I forgot to renew” failure simply can’t happen on a hosted DarazHost site, because nobody has to remember. You get always-valid HTTPS that renews itself, plus 24/7 support if any certificate question ever comes up. If you’d rather never see this error in your own logs again, automated renewal is the whole answer — and it’s already included.

To understand how certificate validity fits into the bigger picture of trust and encryption, see our complete guide to how HTTPS, SSL encryption, and trust work.

Frequently asked questions

Is `net::err_cert_date_invalid` dangerous? The error itself isn’t a sign of an attack — most of the time it’s a harmless expired certificate or a wrong clock. That said, the browser blocks the page for a reason: it can’t confirm the certificate is currently valid, so don’t enter passwords or payment details until the certificate is fixed and the padlock returns.

Why does the site work on my phone but not my computer? Because each device checks the certificate against *its own* clock. If your phone shows the site fine but your computer throws `net::err_cert_date_invalid`, the certificate is valid — your computer’s date or time is wrong. Fix the clock and set it to sync automatically.

The certificate looks “not yet valid” instead of expired. What’s going on? “Not yet valid” means the current time is *before* the certificate’s start date. A correctly issued certificate that started in the past can’t be not-yet-valid for everyone — so this almost always means your device’s clock is set too far in the past. Correct the date and the error clears.

I renewed the certificate but still see the error. Why? Three common reasons: the old expired certificate is still installed alongside the new one, the new certificate wasn’t fully deployed (including its chain), or your browser cached the old state. Reinstall the new certificate cleanly, restart the web server, and re-test in a private window.

How do I stop this from happening again as a site owner? Set up automatic renewal — AutoSSL on cPanel-style hosting or certbot’s renewal timer — so certificates renew well before expiry without anyone remembering. Automated renewal is the only fix that’s permanent.