When an SSL certificate expires, browsers put a full-page warning in front of your site, and the fix is to renew the certificate and then confirm that the server is actually serving the new one. The lasting fix is different: take renewal out of anyone's memory by automating it, and watch the result from outside. If you renew certificates by hand on shared hosting, if visitors are reporting a "not secure" screen right now, or if you simply want this to be the last time, following this order of work will get you there.
What an expired certificate does to a visit, and to everything else
A certificate carries a start date and an end date. Once the end date passes, the browser treats the certificate as invalid and replaces the page with a warning. The wording depends on the browser and its version, but the meaning is constant: the identity of this site could not be confirmed. A visitor reaches your content only by clicking through an extra step, and many will not.
The damage is wider than the page a person sees. Anything that connects to your hostname over HTTPS meets the same error: a mobile app, a payment form, a feed reader, a partner system that posts bookings to you, a monitoring script. These clients have no friendly screen to show. They fail, and the failure may be noticed hours later in a spreadsheet instead of a browser.
What a warning does not tell you
A warning screen does not prove that the certificate expired. It can come from a name mismatch, a missing intermediate certificate, a device clock that is wrong, or a proxy in the middle. Treat the screen as a symptom and read the certificate details before you change anything.
Ninety days by design: why short lifetimes exist
Let's Encrypt explains its choice of a 90-day lifetime in the post Why ninety-day lifetimes (Opens in a new tab). Two reasons are given. Short lifetimes limit the damage from key compromise and from mis-issuance, because a stolen key or a wrongly issued certificate stays usable for a shorter time. And short lifetimes push people toward automation, which the post calls absolutely essential for ease of use; once renewal is automatic, a short lifetime is no more work than a long one.
The same post recommends that subscribers renew every sixty days. That leaves a thirty-day margin before expiry, which the authors describe as room for manual renewal where automation is not in place yet. The page marks itself as a historic post and points readers to the current certificate lifetime documentation for present policy. Lifetimes and recommended timing can change, so check Let's Encrypt's current pages before you build a schedule around these numbers.
The practical reading is simple. A certificate that lasts months cannot be managed with a once-a-quarter reminder in someone's head. Expiry is not an outage that happens to you. It is what a manual process produces after enough months.
The email reminders are gone: what changed at Let's Encrypt
For years, Let's Encrypt sent a warning email to the contact address on an account as a certificate approached expiry. The service has ended. The expiration emails page (Opens in a new tab) says Let's Encrypt has ended its email expiration service, and the announcement post (Opens in a new tab) sets the end date as June 4, 2025.
The announcement lists four reasons. Many subscribers now have automated renewal. Sending the emails means keeping email addresses linked to issuance records, which conflicts with the organization's privacy values. The service costs tens of thousands of dollars per year. And it adds infrastructure complexity that raises the chance of mistakes. If your plan was to wait for the email, that plan no longer exists, and monitoring is now your job.
What the announcement recommends
The post points to Red Sift Certificates Lite, formerly Hardenize, and says its expiration email monitoring is free for up to 250 certificates. It also says other options are listed on the Let's Encrypt monitoring options page. That statement describes a third party's offer, and the terms may change, so read the provider's current page. The announcement gives no guidance on ACME client renewal timing or on specific tools beyond these pointers.
Outside monitoring that does not depend on the renewer
Practical suggestion: whatever renews the certificate must not be the only thing that reports on it. If the renewal job dies, it will not tell you. An independent checker connects to the site from outside, reads the certificate the server presents, and alerts you when the end date falls under a threshold.
| Question for any monitor | Why it matters |
|---|---|
| Does it read the certificate the server serves, or a file on disk? | A renewed file that the web server never loaded still produces a warning for visitors |
| Does it check each hostname separately? | The bare domain, the www name and each subdomain can carry different certificates |
| Does it run from a network outside your own? | A load balancer or CDN may present a different certificate to the public than to your internal tests |
| Does it detect a broken chain? | A missing intermediate certificate produces failures on some devices only |
| Where do alerts go? | One person's mailbox is a single point of failure; a shared address or team channel is not |
Use two thresholds: an early one that leaves room to fix a failed renewal, and a late one that triggers a manual renewal and tells a manager. You choose the day counts. No document sets them for your site, and a site that takes bookings should place the early threshold further from expiry than a brochure site.
Reading the warning before you act
Open the certificate details from the warning page or the padlock. Compare three things with what you expect.
Dates, with time zone
Read the end date with its time and zone, not only the day. A renewal made late on the last day can already be too late. Practical suggestion: never plan a renewal for the final days of validity.
Names
The certificate lists the hostnames it covers. A new subdomain, a changed redirect from www, or a campaign domain pointed at the same server can leave a name outside the list and produce a mismatch warning that looks like an expiry problem.
Chain
The server should send its own certificate and the intermediate certificate that links it to a trusted root. If the intermediate is missing, some devices open the site and others refuse. Installing the full chain file supplied by your host or client avoids this inconsistency.
| What you see | Likely cause | First check |
|---|---|---|
| End date is in the past | Not renewed, or renewed but not loaded | Read the date in the browser, then reload the web server |
| End date is in the future, warning persists | Name mismatch or missing intermediate | Compare the name list and chain |
| One device only | Wrong date or time on that device | Correct the clock and retry |
| Only www or only the bare name | Certificate covers one of the two | Open both addresses separately |
| Fresh date on server, old date for visitors | A CDN or proxy layer holds the old certificate | Review the edge certificate setting |
Keep a note of what you saw, because the same evidence helps a host support agent reproduce the problem. A screenshot of the certificate details, the hostname you tested and the time of the test are enough for a first reply. If the provider asks for more, ask which exact value they want instead of guessing; renewal tickets stall when each side waits for the other to clarify.
Renewing now: host panel, ACME client or paid certificate
The route depends on where the certificate comes from. If you do not know, open the SSL section of your hosting panel; it names the issuer and end date.
| Source | Renewal route | Watch for |
|---|---|---|
| Hosting company manages it | Use the panel's renew control or open a support ticket | Check the new date yourself afterwards |
| You run an ACME client such as one that talks to Let's Encrypt | Run the renewal, then find out why the scheduled run did not | Do not stop at the manual run |
| Paid certificate | Buy or reissue, complete validation, upload files in the panel | Include the full chain file |
Let's Encrypt and a paid certificate both end up as the same padlock, and the monitoring plan is identical for both. The difference is who does the renewal. A host-managed certificate shifts the work to your provider, a client-managed one makes you responsible for the scheduler, and a paid certificate adds a purchase, a validation email and sometimes a payment approval, which all need a human. Rule of thumb for choosing: ask who notices if the renewal is forgotten, and prefer the model where the answer is not "nobody".
An hour-one runbook
- Reproduce the warning from two different networks to rule out a local cause.
- Write down the end date, the name list and who issued the certificate.
- Pick the renewal route from the renewal-route table and carry it out.
- Reload the web server or purge the edge certificate if a CDN is in front.
- Confirm the new date from a browser on a different network.
- Write one line explaining why the renewal was not done in time.
Automatic renewal: four parts that all have to exist
Automation is more than an installed client. A working setup has four parts, and a missing one explains the mysterious expiries.
- A tool that obtains and renews certificates, either an ACME client or a feature in the hosting panel.
- A scheduler that starts that tool on a regular basis.
- A step that tells the web server to load the new certificate after each renewal.
- An alert that fires when the renewal fails.
Parts three and four are the ones people skip. Without the reload step, a renewal succeeds in the logs while visitors continue to receive the old certificate. Without the alert, a failed renewal is discovered by a customer.
Test before you trust
Some ACME clients can simulate a renewal without issuing a certificate. Run that test after the first setup and again after any change to hosting, DNS or redirects. The mode name differs by client, so use your client's own documentation.
Renew early
Practical suggestion: schedule renewal attempts well before the end date. The sixty-day recommendation from Let's Encrypt is a sound reference because a failed attempt at day sixty still leaves weeks to repair the cause.
Why renewals fail quietly
| Cause | What you will notice | Direction of the fix |
|---|---|---|
| Validation path blocked | The client reports it could not reach the validation address | Check redirects, firewall rules and maintenance pages that catch every path |
| DNS no longer points to this server | Validation fails after a hosting move | Review DNS records and the migration timeline |
| Scheduler not running | No renewal attempts in the logs | Check the scheduled job and the account that runs it |
| Web server not reloaded | File is fresh, browser shows an old date | Add the reload step |
| Client outdated or removed | Errors about protocol or unsupported features | Update the client or move to host-managed renewal |
| New hostname missing from the certificate | Mismatch warning on the new name only | Reissue with the new names |
The first row deserves attention. A maintenance page that redirects every request, a new rule in a web application firewall, or a forced redirect to another host can intercept the validation request without anyone noticing. When you change those rules, keep the validation path open. For what a maintenance page should return, see maintenance mode and 503 downtime.
Example scenario: the partner booking subdomain
Example scenario: a wedding venue takes enquiries through its main site, and a partner catering company sends event requests to a separate booking subdomain that was set up two years ago by a freelancer. The main site renews automatically through the hosting panel. The subdomain never joined that system. Its certificate expires on a Friday evening, the partner's system rejects every request, and nobody sees a warning because no human opens that address. The first alert is a caterer asking why the weekend event requests did not arrive.
The lesson is in the inventory. The main site was safe, the forgotten name was not. A table of every hostname, its certificate source, its end date and an owner would have shown the gap in a minute. Put this table next to your DNS records and review it twice a year.
Lessons from the booking subdomain
Three habits would have prevented the weekend failure. First, a monitor that lists the subdomain by name, since the main site check never touched it. Second, an alert address that more than one person reads. Third, a rule that any hostname added to DNS gets a row in the inventory on the same day. Each habit costs minutes. The incident cost a weekend of event requests and a difficult conversation with a partner.
What to tell customers during the incident
While the warning is live, customers and partners will ask what is happening. Keep the message short and factual: a certificate renewal was missed, the fix is in progress, and you will confirm when the site is back. Do not describe the event as an attack unless you have evidence, and do not promise a time you cannot control. Practical suggestion: write down the exact hour the warning began and the hour it ended, because partners may ask for it later.
Four assumptions that cost the first hour
Under pressure, people reach for the explanation that feels scariest. Each of these four can be tested in a few minutes.
| Assumption | Test | What it changes |
|---|---|---|
| The site was hacked | Read the end date in the certificate details. A past date explains the warning without any intrusion | Treat it as a renewal task and do not announce a breach you cannot show |
| Renewal ran, so the work is done | Open the site from a second network and compare the end date with the one you expected | A server that has not reloaded keeps sending the old file |
| Clearing the visitor's browser will fix it | Test from a device that has never visited the site | The certificate comes from the server, so a visitor-side cleanup cannot replace the file the server sends |
| Only the main address matters | List every hostname that partners, forms and apps call | A forgotten name can fail silently while the main site looks healthy |
Practical suggestion: write the result of each test in the incident note before you change anything, so the note records the cause and not only the cure.
Decision rule for the first call
Decision rule: if the end date is in the past and the certificate comes from your host, open a support request first and renew second. If it comes from your own ACME client, find out why it did not run before you run it by hand. Skipping the cause leaves the same failure waiting for the next renewal, and a manual fix with no written reason teaches the team nothing.
A calendar of checks
| When | Action | Owner |
|---|---|---|
| Day of setup | Test run, record the first end date, connect the monitor | Technical owner |
| After each renewal | Confirm the new date from a browser | Technical owner or agency |
| Early alert threshold | Investigate why renewal has not happened | Shared mailbox |
| Late alert threshold | Renew manually and tell management | Manager and technical owner |
| Any infrastructure change | Retry renewal after DNS, hosting, redirect or firewall edits | Whoever made the change |
| Twice a year | Review the hostname inventory and remove unused DNS records | Technical owner |
Ownership, handover and hosting moves
Thresholds that fit your site
The number of days before expiry at which an alert fires is your decision. A shop that depends on checkout needs the early alert far enough ahead to allow a support ticket with the host, a purchase approval and a validation email. A static brochure site can accept a shorter lead time. Write the chosen numbers in the same place as the inventory, so that a new teammate understands why they were chosen.
Roles instead of names
Certificates fail when the person who understood them leaves. Attach the task to a role, not a name: a technical owner role, a shared address for alerts, and written instructions for the renewal route. If an agency handles your site, put certificate renewal and monitoring in the contract in plain words.
Hosting moves deserve a separate line in the plan. A certificate managed by your old host does not travel with you. Decide in advance when the new certificate is issued, when DNS switches, and when the old renewal automation is switched off. Otherwise the first sign of the move is a certificate warning. The step-by-step order is in the hosting change and DNS cutover checklist, and a domain change adds the certificate for the new name to the list in the site migration guide.
After the fix: HTTPS checks and a short post-incident note
Once the padlock is back, check that nothing else shifted. Pages should not load insecure resources, the HTTP address should redirect to HTTPS, and a strict transport policy should behave as you expect when a certificate problem occurs. Those topics have their own checklist: mixed content and HSTS after an HTTPS migration. For other infrastructure risks on the same server, see the website security and hosting checklist, and for how status codes should behave during repair work, see the HTTP status codes guide.
Write a one-page note covering the owner, the renewal method, where reminders went, why automation failed or did not exist, and who will verify the next renewal. The note is not paperwork. It is how the duty moves from one person's memory into the organization.
Checklist for certificate expiry
- The source of each certificate (host, ACME client, paid provider) is written down.
- Every hostname has an end date in a shared table.
- Automatic renewal is on and was tested with a simulated run.
- The web server reload after renewal is defined.
- An outside monitor reads the served certificate.
- Alerts reach a shared address or team channel.
- Renewal is retried after every DNS, hosting, redirect or firewall change.
- The new end date is confirmed in a browser after each renewal.
Decision rule: if two or more of these are missing, treat the next expiry as a live risk and close the gaps before that date arrives.
Frequently Asked Questions
If my certificate expires, will my Google rankings drop?
Google's documentation does not make a statement on this. What is certain is that visitors meet a browser warning. Renew quickly and verify the served certificate.
Has Let's Encrypt really stopped its expiry emails?
Yes. Its documentation page says the email expiration service has ended, and the announcement post gives June 4, 2025 as the end date. Set up your own monitoring.
I renewed the certificate but the warning stays. Why?
The web server may not have loaded the new file, a CDN may still serve the old certificate, or the new certificate may cover only one of the www and bare names. Reload the server and read the end date in a browser.
How long does a Let's Encrypt certificate last and when should it renew?
The Let's Encrypt post describes a 90-day lifetime and recommends renewing every sixty days. It is a historic post, so confirm current values in the certificate lifetime documentation.
Does buying a paid certificate end the problem?
No. A paid certificate also expires, and renewal needs a person. Monitor the end date independently whichever model you use.
Which tool should I use to monitor expiry?
Let's Encrypt names Red Sift Certificates Lite in its announcement and lists further options on its monitoring options page. Choose any checker that reads the served certificate from outside and alerts a shared address.
Conclusion
When a certificate has expired, separate the cause first, renew through the route that matches where the certificate comes from, and confirm in a browser that the server serves the new file. The lasting protection has three layers: automatic renewal, monitoring that does not depend on the renewer, and a written owner. Now that Let's Encrypt has ended its expiration emails, the third layer is your responsibility.
Once the certificate routine is stable, you can turn to earning links for a site that stays reliably secure. For that, take a look at our backlink packages.
Post a comment
Please log in to leave a comment. Login