Problem
The certificate expired on a weekend: bringing the site back
The site is not broken. The browser is refusing it because its certificate is no longer valid — and a certificate can be reissued in minutes, Sunday included.
Force the renewal on the server, then reload the web server: that second half is what everyone forgets. If you cannot reach the server, reissue from the host’s control panel. And if you have neither, put the domain behind a proxy that supplies its own certificate — on a holiday weekend it is the only workaround that fits in ten minutes.
Do this right now
Four moves. The first stops you repairing the wrong fault: three unrelated errors produce the same warning screen.
Read the error code, not the headline
1 minThe headline on the warning screen is identical for every cause. The code underneath names the fault. DATE_INVALID: the certificate has expired, or is not valid yet. COMMON_NAME_INVALID: it is valid but does not cover this hostname. AUTHORITY_INVALID: the chain is incomplete or the issuer is not trusted. Three codes, three different repairs.
Force the renewal, then reload the server
5 minOn a server you administer, force a renewal with your ACME client, then reload Nginx, Apache or Caddy. This is the trap: a certificate renewed on disk but not reloaded changes nothing for the visitor, because the server keeps the old one in memory. It accounts for half of all “I renewed it and it still doesn’t work”.
If renewal fails, read the validation error
10 minThe certificate authority has to confirm you control the domain before it signs. Two causes come up constantly: the domain no longer points at this server because somebody changed a DNS record, or a rule added since intercepts the /.well-known/acme-challenge/ path and answers an error instead of serving the validation file. Test that path by hand before touching anything else.
Check from the outside, on both hostnames
3 minYour own browser may accept a certificate another one will reject, because it cached the intermediate chain on an earlier visit. Check from outside, on the bare domain and on www. A certificate that covers only one of the two breaks for half the visitors.
The screen your client is looking at, decoded
They will send you a screenshot of this, usually without the code. Ask them to expand the bottom of the screen: that line is the only one that teaches you anything.
Your connection is not private
A warning paragraph follows, then a collapsed button at the bottom of the screen.
NET::ERR_CERT_DATE_INVALID
Advanced
- The headline is identical for every cause. It teaches you nothing, so do not look for the fault there — and above all do not conclude that the site has been hacked.
- The code does name the fault. DATE_INVALID means expired — or not yet valid, which happens when the server clock is wrong: check the time before reissuing everything.
- This button expands a “proceed anyway” link. Your client will click it and believe the problem is solved. It is not: every visitor sees the same screen, and so do search engines.
Which move, based on what you can actually reach
On a Saturday night the question is not which fix is best, it is which fix is available to you right now. All three branches end in the same place, using different access.
Can you still reach the server that serves the site?
- Yes, on the command line
Force the renewal, then reload the web server.
In that order, and both of them. A certificate renewed on disk and not reloaded changes nothing for the visitor.
- No, but I have the host’s panel
Reissue from the interface, then force a reload.
On most shared hosts this is one button and two minutes. Then check that the reissued certificate covers the bare domain and www, not only the name you typed in.
- Neither, and nobody is answering
Put the domain behind a proxy that supplies its own certificate.
You change the domain’s name servers at the registrar, the proxy issues its own certificate and serves the site over HTTPS. You need registrar access, not server access. Allow time for the name server change to be picked up.
What you write to the client on a Saturday
They have read “your connection is not private” and they are thinking about hackers. Your first sentence has to dismantle that, not explain what a certificate authority is.
Subject: Site temporarily unavailable — being restored
Hello,
The site has been showing a security warning since [time]. This is not a hack and no data has been lost: the certificate that encrypts traffic between visitors and the site reached its end date, and the browser refuses to display the page until it is renewed.
I am reissuing it now. Allow [duration] before the warning clears for everyone; some browsers lag by a few minutes.
Nothing for you to do, and nothing to announce to your own customers: orders, forms and data are untouched.
I will write as soon as the site is back to normal.
The word to avoid is “security”. It turns a technical outage into an incident, and you will spend the week reassuring people. “The certificate reached its end date” says the same thing and starts nothing.
Why it happened
A certificate never expires by surprise: its end date is known the day it is issued. What expired is the automation that was supposed to replace it.
Let’s Encrypt issues certificates valid for 90 days and recommends renewing every 60. That thirty-day margin exists precisely to absorb a failed renewal. When a certificate genuinely expires, renewal has been failing silently for weeks.
And since 4 June 2025, Let’s Encrypt no longer sends expiry notification emails. Its January 2025 announcement is blunt about why: the service was expensive, it required retaining millions of email addresses, and most subscribers now have reliable automation. The safety net that used to catch these failures has been removed — watching the end date is now on you.
That watching is about to matter more. The CA/Browser Forum adopted ballot SC-081v3, a schedule that reduces the maximum validity of a public TLS certificate from 398 days to 47 days in steps between March 2026 and March 2029. Shorter certificates mean more renewals, and more chances for an automation to break unnoticed.
How to avoid it next time
Watch the end date of the certificate actually served to visitors, from the outside, rather than the file sitting on the server. A valid certificate on disk and a certificate served on port 443 are two different things — that gap is exactly what an unreloaded server creates.
Alert at thirty days, not three. Thirty days is enough time to work out why the automation gave up and fix it on a Tuesday. Three days is enough time to improvise on a Saturday.
And check both hostnames at every handover. A certificate covering example.com but not www.example.com will never trigger an expiry alert, because it has not expired — it simply breaks for everyone who types the www.
Check the certificate that is served, not the one on disk
The tool opens a connection the way a visitor would, reads the certificate presented, its end date, the names it covers and the state of its chain. Enter the site’s domain.
The certificate, reread several times a day.
DomainVigil reopens the connection like a visitor, across every client domain you manage, and warns you when an end date approaches or a chain breaks. Five domains free, no card required.
Five domains free, forever. No card required.