By Greg Nowak. Updated 6 October 2026.
A certificate renewal job can finish successfully while your customers still receive the old certificate. The new file might be sitting on disk, waiting for a service reload, or installed on only one of several servers. For a business website or customer API, renewal is complete when the right certificate reaches the services people actually use.
Shorter TLS certificate lifetimes leave less time to discover and repair those gaps. Business owners need clear responsibility; operations teams need evidence that the whole process works. Agencies managing several client sites need both across the portfolio.
What is changing, and when?
As of 6 October 2026, Let's Encrypt's default classic profile still issues 90-day certificates. Its opt-in tlsserver profile already issues 45-day certificates, according to the current profile documentation. Check which profile your client requests before assuming your setup has until next year.
The published rollout sets two further changes for the default profile:
- 10 February 2027: 64-day certificates, with a 10-day authorization reuse period.
- 16 February 2028: 45-day certificates, with a seven-hour authorization reuse period.
These dates affect newly issued certificates, including renewals. Existing certificates keep their expiry dates.
The wider CA/Browser Forum schedule also reduces public TLS certificate lifetimes and validation-data reuse. Those are separate clocks: certificate validity controls how long a certificate lasts; authorization reuse controls how long earlier proof of domain control can support another issuance. Your automation must handle fresh validation as well as renewal.
Start with the hostnames your business depends on
List your public website, checkout, customer APIs, subdomains and secondary domains. For each hostname, record where TLS terminates, who operates that component, the certificate issuer and profile, the renewal mechanism, and the person responsible for fixing a failure.
Include every deployment destination. A certificate requested on a Linux server may need to reach a separate load balancer or several application servers. With a CDN, the customer-facing certificate and the origin certificate can have different owners and renewal arrangements.
If hosting manages certificates for you, ask how failures are detected and escalated. For agency teams, keep this record with each client's handover documentation so an alert does not start a search through old emails.
| Stage | Evidence to ask for | Common gap |
|---|---|---|
| Validation | A fresh challenge completes unattended. | Manual DNS updates or inaccessible credentials. |
| Scheduling | Recent executions and a lifetime-aware renewal policy. | A wrapper that waits a fixed number of days. |
| Deployment | The certificate reaches every destination and loads successfully. | A missed copy, failed hook or service reload. |
| Public verification | An external check sees the intended certificate and expiry. | One endpoint still serves the previous certificate. |
| Escalation | A test alert reaches an owner and backup. | An unattended mailbox or unclear responsibility. |
Check the renewal policy behind the timer
How often a client runs and when it decides to renew are different questions. Let's Encrypt recommends ACME Renewal Information (ARI), which lets the issuer guide renewal timing. Check your client's current documentation for support and configuration. A hardcoded 60-day renewal interval cannot support a 45-day certificate.
On Linux, inspect the actual systemd timer or cron entry and recent logs. Confirm the command, account and configuration it uses. Read wrapper scripts for calendar restrictions, swallowed errors and dependencies on an interactive login. A frequent timer cannot compensate for a script that refuses to renew until too late.
Rehearse renewal without overstating what it proves
For Certbot, certbot renew --dry-run tests renewal against staging. Deploy hooks are skipped by default. After reviewing their effects, use certbot renew --dry-run --run-deploy-hooks to exercise applicable deploy hooks following a successful test. They use the current active certificate, not the temporary test certificate.
Dry runs can trigger web server reloads and execute pre/post hooks. Review these before testing a live service. Also check whether domain validation needs manual input: Certbot's manual plugin requires authentication hooks for automatic renewal. These behaviours are documented in the Certbot user guide.
A zero exit status from certbot renew can mean either successful renewal or that nothing needed renewing. Use a deploy hook for actions that should follow an actual renewal.
Keep rehearsal results separate from production evidence. A successful dry run demonstrates the tested validation and hook path; the next production renewal must show that a newly issued certificate reaches the intended services.
Verify deployment from the customer's side
Follow the certificate through its configured path, copying steps and service reloads. Make failures in each step visible. Then connect from outside the renewal host, using the hostname customers use, and compare the served certificate's identity and expiry with the intended deployment.
Where several servers or regions can answer, check each relevant destination. If a CDN terminates public TLS, inspect the origin separately where applicable. One successful connection cannot establish that every component received the replacement.
Give alerts an owner and leave time to act
Combine renewal failure reporting with external certificate expiry monitoring. Choose warning thresholds around the lifetime and expected renewal window actually in use, leaving time to investigate, repair and retry. Include the hostname, observed expiry and a route to the responsible service in each alert.
Test delivery and acknowledgement with a named owner and backup. Review the setup after changes to hosting, DNS, credentials or deployment scripts. October is a useful time to repair weak points and observe a production renewal before the February 2027 default change.
If you need help turning this into a manageable review, Greg can inspect renewal clients and Linux scheduling, test deployment hooks, and help establish external checks and clear responsibilities. Discuss your TLS renewal setup with Greg and agree which endpoints and handover evidence the work should cover.
Related on GrN.dk
- Let's Encrypt Profiles Put Your Renewal Setup to the Test
- Google Review Link Generators: What Small Teams Actually Need
- Shorter TLS Certificates Make Renewal Monitoring a Server Job
Need help with this kind of work?
Discuss your TLS renewal setup with Greg Get in touch with Greg.
