Bridge SSL
- Bridge SSL
- Errors
- ERR_CERT_DATE_INVALID: what it means and how to fix it
ERR_CERT_DATE_INVALID: what it means and how to fix it
Quick facts
| Browsers | Chrome, Edge, and other Chromium browsers |
|---|---|
| Exact text | Your connection is not private with NET::ERR_CERT_DATE_INVALID |
| Layer | certificate validity window |
| Who fixes it | the site owner, unless the visitor's clock is wrong |
| Warning first | none — the change is instant and total |
What this error means
Every certificate carries two fields that bound its life: notBefore and notAfter. A browser reads them, compares both against its own idea of the current time, and rejects the certificate if the answer falls outside. There is no tolerance window and no degraded mode. A certificate that was fine one second ago is refused the next, for every visitor at once.
The comparison has two sides, and that is what makes this error ambiguous. The certificate can be wrong, or the clock can be wrong. A device whose date is set months into the future will reject a perfectly valid certificate, and a device set into the past will reject one that has not started yet.
Fixes by cause
The certificate expired
The common case, and the one the site owner owns.
notAfterhas passed. Nothing about the certificate can be repaired: a new one has to be issued and put into service. Renewal issues a replacement; the original is never extended, whatever the documentation's wording suggests.The certificate is not valid yet
notBeforeis in the future. This appears after a certificate is issued and deployed faster than the authority's own timestamp, or on a server whose clock runs behind. Wait, or correct the server clock, and it resolves itself.The clock on the visitor's device is wrong
Nothing is wrong with the site. A phone or laptop with a badly wrong date rejects the certificate, and only that device sees it. Ask the visitor what date their device thinks it is; if it is not today, that is the whole answer.
The intermediate expired, not the leaf
Rarer, and easy to misread. The certificate your server presents can be well inside its window while a certificate above it in the chain is not. A checker that reports the chain rather than only the leaf will show which one.
Browser variants
Chromium browsers show NET::ERR_CERT_DATE_INVALID under the heading Your connection is not private. Firefox reports the same underlying fault as SEC_ERROR_EXPIRED_CERTIFICATE under Warning: Potential Security Risk Ahead. Safari does not print a code and says the connection is not private. The fault is identical in all three; only the wording differs.
How to diagnose
Ask the certificate what it thinks, from outside, on a machine whose clock you trust. An independent check matters here more than in most errors, because the failure mode you are testing for is a disagreement about time, and a check running on the affected machine inherits its clock.
Read notBefore and notAfter from what the hostname actually presents. If both bracket the current time, the certificate is fine and the problem is the clock on whatever machine reported the error. If notAfter has passed, renewal did not happen or did not reach this hostname. If notBefore is ahead of the current time, the certificate is early rather than expired, and the same two suspects apply: the authority's timestamp or the server clock.
Why a missed renewal is so easy to miss
The check that most teams run asks the system performing the renewal whether the renewal happened. That system answers honestly, and the answer is useless when the system itself is the fault. A renewal job can run, report success, and still leave the old certificate in place because it wrote the new one somewhere the server does not read, or because nothing reloaded.
An independent check, made from outside and asking what the hostname presents, stays useful in exactly that case, because it shares nothing with the thing that failed.
The pressure is also rising on a published schedule. The CA/Browser Forum ballot SC-081v3, adopted April 2025, cuts the maximum lifetime of a publicly trusted certificate in steps, reaching 47 days in March 2029. Every cut multiplies the number of renewal events, and every renewal event is a chance for this error.
How to prevent it
Remove the deadline rather than tracking it. A certificate that is issued and renewed by the layer that serves the site cannot be renewed correctly and then fail to be picked up, because there is no handover between the two.
That is what Bridge SSL does: certificates are obtained and renewed by the platform that serves your site, wildcards included, with nothing to install and no renewal task to schedule. Keep the independent check anyway: that recommendation does not change because renewal moved.
FAQ
Does an expired certificate still encrypt the connection?
The cryptography itself would still work, but the browser refuses to use it, so no connection is established at all. Expiry is a trust decision, and the browser makes it before any traffic flows. The visitor gets the interstitial, not a weaker padlock.
How long is the grace period after expiry?
There is none. Validity ends at an exact moment carried inside the certificate, and every browser enforces it immediately and identically. The cutoff applies to every visitor at the same instant, which is why an expiry that happens during the night is discovered by the morning's first users.
Can I keep the same certificate and just extend the date?
No. The dates are inside the signed material, so changing them would break the signature. Renewal always means a new certificate rather than an extended old one, which is why the word is misleading and why every renewal ends with the replacement being installed and served.
Only one visitor sees this. Is my site broken?
Almost certainly not. When one device reports the error and others do not, the disagreement is about time rather than about the certificate, because everyone else's browsers accept the same certificate. Ask what date that device thinks it is; if it is not today, that is the whole answer.
Should I still monitor certificates if renewal is automatic?
Yes. A check that depends on the renewing system reports success until that system is the thing that failed. An independent check made from outside, asking what the hostname actually presents, shares nothing with the renewal and stays useful in exactly the case the inside check misses.
Certificates that renew themselves
Bridge SSL is the TLS layer of Bridge CDN: issuance and renewal happen as part of serving your site, wildcards included. Nothing to install, nothing to schedule.