By Greg Nowak. Updated 5 November 2026.
A certificate renewal job can finish successfully while your website still serves the old certificate. The replacement may be waiting for a reload, missing from a load balancer, or installed on only some servers. For your customers, renewal is complete when the services they use present a valid replacement.
Shorter TLS certificate lifetimes reduce the time available to catch these gaps. If you run a business website, customer API or agency hosting portfolio, the useful question is: can you demonstrate that validation, renewal, deployment and alerts work together without someone remembering to intervene?
What changes next, and which deadline applies?
As of 5 November 2026, Let’s Encrypt’s default classic profile still issues 90-day certificates. Its opt-in tlsserver profile already issues 45-day certificates. Check your client configuration against the current profile documentation before assuming which lifetime applies.
Let’s Encrypt’s published rollout changes the default profile in two stages:
- 10 February 2027: 64-day certificates and a 10-day authorization reuse period.
- 16 February 2028: 45-day certificates and a seven-hour authorization reuse period.
These changes apply to newly issued certificates, including renewals. Certificates already issued retain their expiry dates.
Other issuers have their own schedules within the CA/Browser Forum Baseline Requirements. The industry maximum for newly issued public TLS certificates is currently 200 days, falling to 100 days on 15 March 2027 and 47 days on 15 March 2029. An issuer can use shorter lifetimes.
Certificate validity and authorization reuse are separate clocks. One determines when a certificate expires; the other determines how long earlier proof of domain control remains reusable. Your setup must handle fresh validation reliably.
Start with the services that matter to the business
Build a short register of your website, checkout, customer APIs and other important hostnames. For each, record where TLS terminates, who manages it, which issuer and renewal client it uses, and who responds when something fails.
Include CDNs, load balancers and origin servers. A hosting provider may manage the public certificate while your team remains responsible for the origin certificate. Ask the provider how renewal failures are detected and escalated.
For agencies, keep this record with each client’s handover documentation. Responsibility should remain clear when an account manager, developer or hosting supplier changes.
| Check | Evidence of readiness | Fix first if… |
|---|---|---|
| Domain validation | A fresh challenge completes unattended. | Someone must edit DNS manually. |
| Renewal scheduling | Recent runs and a policy suited to the certificate lifetime. | A script waits a fixed 60 days. |
| Deployment | Every destination loads the replacement. | Copy or reload failures go unnoticed. |
| External monitoring | Checks observe the certificate actually served. | Monitoring only inspects local files. |
| Ownership | A test alert reaches an owner and backup. | The contact is an unattended mailbox. |
Check what happens behind the timer
A client’s execution schedule and its decision to renew are different things. Let’s Encrypt recommends ACME Renewal Information (ARI), which lets the issuer guide renewal timing. Check whether your client supports it and how it is enabled. Without ARI, use a policy that adapts to the actual certificate lifetime.
On Linux, inspect the systemd timer or cron entry, recent logs, execution account and configuration. Read any wrapper scripts too. A timer running twice daily offers little protection if a wrapper refuses to renew until day 60, suppresses errors or depends on an interactive login.
Test renewal and understand what the test proves
For Certbot, start with certbot renew --dry-run. It tests against staging and skips deploy hooks by default. Pre/post hooks can still run, and web server reloads may occur, so review the configured actions first.
After reviewing their effects, use certbot renew --dry-run --run-deploy-hooks to exercise applicable deploy hooks following a successful test. These use the current active certificate, rather than the temporary staging certificate.
The Certbot user guide also documents three details worth checking:
- The manual plugin needs authentication hooks for automatic renewal.
- A zero exit status from
certbot renewcan mean successful renewal or that nothing needed renewing. Use a deploy hook for actions following an actual renewal. - A failing hook does not directly make Certbot exit with a failure status. Monitor deployment failures separately.
A successful rehearsal establishes that the tested path works. The next production renewal should provide evidence that a newly issued certificate reaches every intended service.
Verify the certificate customers actually receive
Trace the deployment from the renewal client through file paths, copying steps and service reloads. Each step needs a visible failure signal. Then check from outside the renewal host, using the customer-facing hostname, and compare the served certificate’s identity and expiry with the intended deployment.
Where several servers or regions can answer, verify the relevant destinations. With a CDN, check the public endpoint and the origin separately where applicable. One successful connection cannot establish that every server received the replacement.
Leave enough time for someone to fix a failure
Combine renewal failure reporting with independent checks of the served certificate’s expiry. Set warning thresholds around the actual lifetime and expected renewal window, allowing time to investigate, repair and retry. A missed expected renewal deserves attention before expiry becomes urgent.
Alerts should identify the hostname, observed expiry, responsible service and next troubleshooting step. Test that an owner and backup receive them and know who can access DNS, hosting and deployment credentials. Repeat the review after infrastructure or supplier changes.
Use November to repair weak points and observe a production renewal before Let’s Encrypt’s February 2027 default change.
If you would like help, Greg can review the renewal client, Linux scheduling, validation and deployment path, then help establish external checks and a clear handover. Discuss your TLS renewal setup with Greg, starting with the endpoints your business depends on and the evidence you need to maintain them.
Related on GrN.dk
- Let’s Encrypt’s 64-Day Certificates Call for a Renewal Check
- Let's Encrypt Profiles Put Your Renewal Setup to the Test
- Apache 2.4.68: What to Check Before You Call It Patched
Need help with this kind of work?
Discuss your TLS renewal setup with Greg Get in touch with Greg.
