By Greg Nowak. Last updated 2026-09-06.
Your renewal job can finish successfully while customers still receive the old certificate. For a business website or customer API, the job is only complete once the intended certificate is being served. The scheduler, certificate request and public endpoint each need checking.
Shorter certificate lifetimes make gaps between those steps harder to leave unattended. Can your setup validate domains, obtain certificates, deploy them and check the result repeatedly, without someone having to remember a maintenance task?
As of September 2026, Let's Encrypt's lifetime documentation still lists 90 days as the default. Shorter lifetimes limit exposure from compromised keys and mis-issued certificates, and encourage automated renewal.
Its published rollout schedules the default classic profile to issue 64-day certificates from February 10, 2027, and 45-day certificates from February 16, 2028. The opt-in tlsserver profile was scheduled to move to 45 days on May 13, 2026. These changes apply to newly issued certificates, including renewals. Certificates already issued keep their existing expiry dates.
The CA/Browser Forum's adopted SC081v3 ballot sets the wider schedule for reducing public TLS certificate validity and validation-data reuse. Those are two separate clocks: one determines how long a certificate lasts; the other determines how long earlier validation evidence can support issuance. Your review needs to cover both when renewal happens and whether the system can prove domain control again.
Start with a list of public hostnames, including customer APIs and secondary domains. For each one, record where TLS terminates, who operates that component, which certificate it should serve and who owns renewal. If your hosting provider manages certificates, make that responsibility explicit and establish what evidence it can supply.
This list should help someone investigate an alert. They need to get from a hostname to the responsible service, renewal mechanism and owner without first reconstructing the architecture. Include every deployment destination, especially where the machine requesting the certificate is not the one serving it.
Use the following checklist to agree what counts as a working renewal setup.
| Stage | What you need to see | Where to look if it is missing |
|---|---|---|
| Domain validation | A renewal test completes the configured challenge without manual intervention. | Challenge routing, credentials and authentication automation. |
| Scheduling and issuance | The scheduler runs and the client's renewal policy supports shorter lifetimes. | Timers, client versions and custom scheduling rules. |
| Deployment | The intended certificate reaches every component that serves TLS. | Installation steps, distribution, deployment hooks and service reloads. |
| Public verification | An external connection receives the expected certificate and expiry date. | The difference between the intended deployment and what the public endpoint serves. |
| Escalation | A test alert reaches the named owner and backup. | Alert delivery, responsibility and the response route. |
When checking scheduling, separate how often the client runs from how it decides a certificate is due for renewal. Let's Encrypt recommends ACME Renewal Information, or ARI, to guide that decision. It also explicitly warns that a hardcoded 60-day renewal interval is incompatible with 45-day certificates.
Inspect the actual Linux timer or cron entry and its recent execution history. Check the command, the account running it and the configuration it loads. Read any wrapper scripts too: they may impose their own calendar rules, hide failures or rely on an interactive environment.
By the end of this check, you should be able to identify what decides renewal is due, show that the scheduler invokes it and explain how a failed attempt becomes visible. An enabled timer or an installation date cannot answer all of that.
For Certbot, certbot renew --dry-run tests renewal against staging. Deploy hooks do not run by default. Adding --run-deploy-hooks runs applicable hooks after a successful test, using the current active certificate. A dry run can also reload the web server and execute pre/post hooks, so inspect those effects before testing. The Certbot user guide documents these behaviours.
There is another detail worth checking in your scripts: certbot renew returns exit status zero both when renewal succeeds and when no certificate needs renewing. That status alone does not prove a new certificate was issued. Use a deploy hook for actions that should follow an actual successful renewal.
Agree separate checks for the rehearsal and the next production renewal. The rehearsal should show that validation and the intended hook execution work. The production renewal should provide evidence that the newly issued certificate reaches the public service. Keep those results distinct so everyone understands what the test has established.
Follow the deployment path all the way through. Check the configured certificate location, any copying or distribution steps, and how each service loads the replacement. Where a reload is required, verify that it succeeds. If a hook runs several commands, failures in individual steps need to be visible.
Then connect from outside the renewal host using the hostname customers use. Compare the certificate identity and expiry with the intended deployment. If several components can answer for that hostname, decide how you will check each one. A mismatch remains an open deployment issue until you understand its cause.
Monitoring belongs in the handover. Let's Encrypt recommends alerts when certificates are not renewed as expected. Combine renewal failure reporting with external expiry checks, and choose warning thresholds that leave enough time to investigate, fix the problem and try again within the certificate lifetime actually in use.
Each alert needs a named owner, a backup and a clear escalation route. Include the hostname, observed expiry and enough context to find the responsible service. Test both delivery and acknowledgement; the person receiving the alert needs to be able to act on it.
September leaves time to inspect the setup, fix weak points and observe a subsequent renewal before the February default change. Greg could help with that work: inventorying endpoints, inspecting ACME clients and Linux timers, testing renewal and deployment hooks, repairing reload arrangements, and setting up external expiry alerts with an escalation owner. The handover should leave you with documented responsibilities and evidence that the full renewal process works for the endpoints reviewed.
Related on GrN.dk
- Cloudflare Service Keys: Audit Old Automation Before September 30
- Your AI Image Has Content Credentials. Will Your Website Keep Them?
- Apache 2.4.68 Is a Reminder That Old Proxy Rules Need a Real Audit
Need help with this kind of work?
Discuss your TLS renewal setup with Greg Get in touch with Greg.
