Explained
Your SSL certificate has expired — what that actually means
Real server problems, translated into plain English by Onserva.
What you're seeing
Visitors get a full-page warning instead of your site — “Your connection is not private”, or a certificate error naming an invalid date. There is no styling, no logo, nothing of yours. Getting past it takes a deliberate click through an “Advanced” link that most people will never find and shouldn't use anyway. Your server is running normally the whole time. The site is, for practical purposes, closed.
What it actually means
A certificate does two jobs: it encrypts the traffic between your visitor and your server, and it vouches that this server really is the one entitled to answer for your domain. That vouching has a deadline attached, and the browser refuses to accept an expired one — because a certificate that never expired would still be valid years after someone stole it.
Most certificates today come from Let's Encrypt and are valid for ninety days. That short life is deliberate, and it only works because renewal is meant to be automatic: your proxy asks for a fresh certificate roughly a month before the old one runs out, and keeps asking. You are supposed to never think about it.
So the important thing about an expired certificate is not that it expired. It is that the renewal has been failing for about a month, quietly, while everything looked fine. The outage you are looking at today started weeks ago. The deadline simply arrived.
Why renewal fails silently
Renewal needs to prove, again, that you still control the domain. Usually that means the certificate authority makes a plain HTTP request to your domain on port 80 and expects to find a specific file your proxy has just put there. Anything that breaks that round trip breaks renewal — and nothing about your live site changes when it breaks, which is why nobody notices.
- Port 80 stopped being reachable. A firewall rule tightened, a security group edited, a provider default changed. HTTPS keeps working perfectly, so the site looks healthy — but the renewal conversation happens on the port you just closed.
- A redirect swallowed the challenge. A blanket “send all HTTP to HTTPS” rule is good practice and will cheerfully redirect the verification request too, so the authority never finds the file it came for.
- The proxy lost its memory. Certificates and their renewal state live in a storage volume. Recreate the proxy container without that volume — during an upgrade, a migration, a tidy-up — and it comes back knowing nothing about the certificates it used to hold.
- The DNS moved and the domain didn't follow. If the domain now points somewhere else, or a subdomain was removed from the certificate's list, the proof fails for the parts that moved while the rest carries on renewing.
What to do now
- Confirm it is the date, not the name. An expired certificate and a certificate issued for the wrong domain produce similar scary pages and have completely different causes. The browser's warning names which one it is — read it before doing anything.
- Check that port 80 answers from the outside. Not from the server itself — from somewhere else entirely. This is the single most common cause, and testing it from inside the machine will tell you it is fine when it is not.
- Trigger a renewal and watch it fail. The failure message is the diagnosis. Renewal problems are unusually well-explained by the software: it will generally tell you exactly which check did not pass, which is far more useful than guessing from the browser's side.
- Mind the rate limits. Let's Encrypt limits how many times you may ask for the same certificate in a week. Retrying in a loop while the underlying problem is unfixed can lock you out for days — fix the cause first, then ask once.
- Once it is back, check the expiry date is really ninety days out. A renewal that appears to succeed but leaves the old date in place has not worked, and you will be here again next week.
When to worry
This is the outage that does the most reputational damage per minute. A site that is simply down reads as bad luck. A browser full-page warning about your security reads, to a customer who does not know the difference, as though you have been hacked — and it is the one failure they may repeat to other people.
It is also unusually bad at the edges you cannot see. Anything talking to your site that is not a person — a payment webhook, a mobile app, another company's integration — does not get an “Advanced” link to click. It simply fails, usually silently, and often keeps failing for a while after you have fixed the certificate.
The thing to worry about after the fire is out: if you renewed by hand, you have not fixed anything. You have bought ninety days. Whatever broke the automatic renewal is still broken, and the next deadline is already set — so the real work is confirming that the next renewal happens by itself, about a month before you need it.
How Onserva handles this
This is the rare outage with a publication date, so there is no excuse for being surprised by it. Onserva checks your sites from outside the machine, the way a visitor reaches them, and reads the certificate while it is there — so it tells you the expiry is approaching well before the deadline, when a failed renewal is still a quiet afternoon's work rather than a closed shop. It watches your domain's own registration expiry on the same principle, because the other way to lose a site overnight is to forget to renew the name it lives at.