Blog · 7 November 2026 · 8 min read

Your SSL certificate is expiring: what customers see, how to check the date and how to never repeat it

At midnight the certificate expires and a website that has worked for three years turns into a full-screen red warning. The server is still running, the hosting dashboard is green, and customers bounce off the door because their browser tells them this place is dangerous. Below: exactly what they see, why automatic renewal fails, how to check the expiry date in a minute, and what to do so this article never applies to you again – especially now that certificates have started living shorter lives.

What happens one minute after expiry

• Customers see a warning instead of your site. Chrome shows “Your connection is not private” with the code NET::ERR_CERT_DATE_INVALID; Firefox and Safari have their own, equally red versions. The “proceed anyway” link is hidden under “Advanced”, and on a phone it can be impossible to find. Most people do what the browser tells them: they leave.
• Nothing else looks broken. The site responds, the server has spare capacity, and simple uptime checkers often only ask “does the server answer” without looking at the certificate. The outage lasts for days, until a customer calls.
• Integrations stop without a message. The payment gateway, the booking widget, the mobile app, the courier polling your API – programs have no “proceed anyway” button. They simply refuse to connect, and the error lands in a log nobody reads.
• E-mail can stop too. If your mail server (mail.yourcompany.com) uses the same certificate, mail clients start asking about trust or stop sending.
• Google does not drop the site immediately, but its crawler cannot fetch it. The longer the outage, the more pages fall out of the index, and recovery takes longer than the fix itself.

Why renewal fails: eight reasons

1. The automation broke quietly after a DNS, hosting or CDN change. Renewal requires the issuer to confirm you control the domain. After a move, the old server keeps dutifully renewing a certificate nobody uses, while the new one never received its own.
2. The certificate was bought manually by an agency that no longer looks after you. Expiry reminders go to an inbox nobody reads, and the login to the issuer's panel left with the contact.
3. An expired card or an unpaid invoice at the issuer or the host. The “SSL” service disappears quietly along with the payment.
4. A redirect or a firewall blocks validation. A forced redirect to https, a “coming soon” page, geo-blocking or a web application firewall cuts off /.well-known/acme-challenge/, the address the issuer uses to verify the domain. The panel records “challenge failed” and nobody sees it.
5. A CAA record in DNS only allows a different issuer. Someone added it years ago for a previous provider, and today's provider cannot get past it.
6. One domain, several certificates. www and the bare domain, shop., api., portal., mail. – each can have its own certificate with its own date. A wildcard certificate for all subdomains renews through a DNS API key that someone rotated.
7. The reminder e-mails no longer arrive. Let's Encrypt, the most popular free issuer, ended expiration notification e-mails on 4 June 2025, citing among other things that most subscribers now have automated renewal and that keeping millions of e-mail addresses conflicts with its privacy goals. If your site relied on that e-mail, nobody has warned you for a year and a half.
8. Lifetimes are shrinking and “once a year” no longer exists. The industry body of browsers and issuers (the CA/Browser Forum) adopted a schedule: the maximum certificate lifetime dropped from 398 days to 200 days from 15 March 2026, falls to 100 days from 15 March 2027, and to 47 days from 15 March 2029. Let's Encrypt certificates are valid for 90 days (renewal every 60 recommended), and six-day certificates are available on request. The conclusion is simple: whoever renews by hand from a calendar will lose to the calendar within two years.

How to check the expiry date in 60 seconds

1. In a desktop browser. Click the icon next to the address (padlock or site settings), then “Connection is secure” and “Certificate is valid” (Chrome), or “More information” → “View certificate” (Firefox). You are looking for two dates, “Valid from” and “Valid to”, and the issuer's name.
2. Read “Valid from”, not only “Valid to”. If the issuer is Let's Encrypt, ZeroSSL or your host's “auto SSL”, the certificate lives 90 days and should be renewed after 60. A “from” date 80 days ago means the automation has already failed – you have a few days before customers notice.
3. Check every name, not just the homepage. With and without www, the shop, the blog, the customer portal, the API, and the mail server's address. Type each one separately – the browser shows the certificate of that specific name.
4. On a phone, or for someone on your team: the free SSL Labs test (ssllabs.com/ssltest) shows the dates, the issuer, the chain and whether the certificate matches the name. It takes a minute or two.
5. For technical people: one terminal command prints the dates and the issuer:

   echo | openssl s_client -servername yourcompany.com -connect yourcompany.com:443 2>/dev/null \
     | openssl x509 -noout -dates -issuer

   The notAfter line is the expiry date.
6. Write the result down with date and issuer in one place for all names. That is your inventory – you will need it at every hosting or contractor change.

Symptom → cause → who fixes it

How to never repeat it

• Automation instead of a calendar. Choose hosting with automatic certificates (Let's Encrypt or its own “auto SSL”), or put the site behind a service like Cloudflare that manages certificates itself. With 200-day – soon 100- and 47-day – lifetimes, manual renewal is not a saving, it is a postponed outage.
• An independent early warning. A reminder from your host does not help when the host is the problem. You need something external that looks at the certificate every day and writes to you 14 and 7 days before the end. Let's Encrypt suggests, for example, the free Red Sift Certificates Lite plan; Webskan Monitor does it too (below).
• An inventory of names. A list of every address with a certificate – including mail and admin panels – with date and issuer. One sheet, updated at every change.
• Two notification addresses at the issuer and the host: yours and someone who will stay with the company. Not the former agency's.
• A test renewal after every change to DNS, hosting, CDN or firewall. Most tools have a dry-run mode (--dry-run) that checks whether validation would pass without issuing a certificate.
• When moving: certificate on the new server first, DNS change second. The other order gives you a few hours of red screen.

What Webskan checks

The in-depth audit checks the certificate on the audited addresses: validity, name match, the redirect from http to https and mixed content, and if less than 21 days of validity remain you get it as a separate finding with a recommendation. Webskan Monitor looks at the certificate every day and e-mails you 14, 7, 3 and 1 day before expiry, and immediately when the certificate becomes invalid; it also watches the expiry date of the domain itself (30, 14 and 7 days ahead). What we do not do: we do not renew certificates for you – that is your host's or developer's job, and our e-mail tells you where to look.

Sources and tools

• CA/Browser Forum, Ballot SC-081v3 – the schedule reducing certificate lifetimes from 398 to 47 days (March 2026 – March 2029); the 200- and 100-day steps per DigiCert's summary
• Let's Encrypt, Ending Support for Expiration Notification Emails – end of notifications on 4 June 2025 and the reasons
• Let's Encrypt, FAQ – 90-day certificates, renewal every 60 days recommended; six-day certificates on request
• Qualys, SSL Server Test – free test of certificate, chain and configuration