If a certificate expires on a Friday evening, customers see a browser warning, an integration stops, or a VPN refuses to connect. Many companies renew certificates by hand once a year with a calendar reminder. That routine has an end date, because the maximum lifetime of publicly trusted certificates is being cut in stages.
This article helps whoever owns IT operations decide what to automate before the next cut, who owns each certificate, and how to be warned when a renewal fails.
What changes, and when
The CA/Browser Forum, the body that sets the rules for publicly trusted certificate authorities, has written a schedule into its Baseline Requirements (section 1.2.2, relevant dates). Maximum validity of a subscriber certificate becomes 200 days on 15 March 2026, 100 days on 15 March 2027 and 47 days on 15 March 2029. The same schedule shortens how long a certificate authority may reuse an earlier domain validation: 200 days, then 100 days, then 10 days.
| From | Maximum certificate validity | Domain validation reuse |
|---|---|---|
| 15 March 2026 | 200 days | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
The first step is already in force, and some authorities go faster. Let's Encrypt has said that its default profile moves from 90-day to 64-day certificates on 10 February 2027 and to 45-day certificates on 16 February 2028, and its optional tlsserver profile has issued 45-day certificates since 13 May 2026. These rules cover publicly trusted certificates. A certificate from your own internal authority has whatever lifetime that authority is configured to issue.
The effect is arithmetic: a certificate renewed once a year needs seven or eight renewals a year at 47 days and nearly four at 100 days. Multiplied by every certificate you hold, a calendar reminder stops being a process.
The lesson: manual renewal does not fail suddenly, it fails when the number of renewals outgrows the number of people who remember them.
Start with an inventory, not a tool
You cannot automate what you cannot list. Write down every certificate in one table with five columns: the name it protects, where it is installed, who issued it, when it expires, and who is responsible for it. A named person, not a mailbox, turns an expiry into an action.
Three places are often missed: devices (printers, firewalls, load balancers, VPN gateways), certificates a vendor installed for you, and old internal tools. Your existing register of online accounts and domains is a sensible place to add a certificate column, and your device inventory will show which devices hold one.
The lesson: an inventory with an owner per row is the cheapest control here, and every later step depends on it.
Automate by exposure and effort
Not everything needs automating on the same day. Sort the inventory by two questions: what breaks for customers if this expires, and how easily can it renew itself?
| Priority | Typical certificate | Approach |
|---|---|---|
| 1 | Public website, API, login pages on servers you control | Automate renewal with an ACME client now |
| 2 | Public services behind a managed platform (CDN, hosting, load balancer from a cloud provider) | Check that the platform renews for you and who is told if it does not |
| 3 | Internal web tools and test systems | Automate if they run a web server you control; consider an internal authority |
| 4 | Devices that cannot run an ACME client | Plan a workaround (next section) |
ACME is the protocol, specified in RFC 8555 (2019, still the current ACME standard), by which software proves control of a domain to a certificate authority and collects a certificate without a person in the loop. Let's Encrypt uses it, and many other authorities and platforms offer it; check what yours supports, because a vendor without ACME needs another route, such as its API.
Two details cause trouble. ACME proves control through a challenge, usually an HTTP file or a DNS record, so a firewall that blocks the request or a DNS provider without automation breaks renewal. And a certificate renewed on disk is useless if the web server never reloads it, so test that step too.
The lesson: automate the public services first and verify the whole path, including the challenge and the reload, not just that a client is installed.
Devices that cannot do ACME
Some equipment accepts a certificate only through a web form or has no ACME support at all. You have four realistic choices, in order of preference:
- Put a reverse proxy or load balancer that supports automated renewal in front, and let the device keep an internal certificate.
- Use an internal certificate authority for devices that are never reached from outside, and set its lifetime yourself.
- Ask the vendor whether a firmware update adds ACME.
- Keep manual renewal, with a named owner and a recurring task that starts early enough.
Option 4 is acceptable only as an exception on a list: a device that needs a person and a maintenance window every few weeks will be neglected or replaced, so decide which now, and add certificate automation to purchase criteria.
The lesson: every device that cannot automate needs an explicit exit (proxy, internal authority, upgrade or replacement), not a quiet exception.
Renew early and alert on failure
Let's Encrypt advises renewing about two thirds of the way through a certificate's life, which for a 47-day certificate is around day 31. It also warns that a fixed 60-day renewal interval will no longer be enough once lifetimes reach 45 days, and recommends monitoring that raises an alert if renewals do not happen when expected.
A better signal than a fixed schedule is ACME Renewal Information, defined in RFC 9773 (2025). It lets the authority tell your client a suggested renewal window, for example to spread load or request early renewal after a problem. Check your client's documentation for support.
Two alerts are worth having, and both should reach a named person:
- Expiry check from outside. A scheduled check that connects to each public hostname and warns when the certificate has fewer days left than your renewal margin. This catches certificates your automation does not know about. It can be part of your weekly uptime and form checks.
- Renewal failure. An alert from the renewal job itself when an attempt fails, so you learn on the first failure and not on the last day.
The lesson: alert on a missed renewal while there is still time to fix it, and treat the outside expiry check as your safety net.
What to do this week
- List every certificate you can find and give each one a named owner and an expiry date.
- Mark each as automated, platform-managed, or manual.
- Automate the public services you control, and test the challenge and the reload.
- Choose one of the four exits for each device that cannot automate.
- Add an outside expiry check and a renewal-failure alert.
If you do only one thing, fill in the owner column. The weekly uptime and form monitoring routine shows how to fit the expiry check into checks you already run, and White Veil Industries can help build the inventory and renewal alerts for your systems.
Sources
- CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (current version, accessed 12 November 2026): cabforum.org. Maximum validity and validation reuse dates are from section 1.2.2 (relevant dates) of the published document.
- Let's Encrypt, Decreasing Certificate Lifetimes to 45 Days (2025): letsencrypt.org. Dates and renewal advice are the vendor's own statements about its service, not a rule for all authorities.
- Let's Encrypt, Profiles documentation (current page, accessed 12 November 2026): letsencrypt.org/docs/profiles.
- IETF, RFC 8555, Automatic Certificate Management Environment (ACME) (2019): rfc-editor.org. Older than 24 months; still the base ACME specification.
- IETF, RFC 9773, ACME Renewal Information (ARI) Extension (2025): rfc-editor.org.
Where this advice does not fit: if a managed platform you do not control issues and renews all your certificates, confirm who is alerted instead of running ACME. The 2027 and 2029 dates could be revised by the CA/Browser Forum, so recheck the Baseline Requirements before planning around them.
