A certificate is easy to overlook when HTTPS works. The more useful question for an owner is how that certificate stays valid. A shorter lifetime means the renewal process needs to keep working without depending on someone remembering a date. Start by separating three ideas: the certificate's validity period, the checks needed to obtain another certificate, and revocation information about certificates that should no longer be trusted.
What a certificate proves
For the domain-control checks described by Let's Encrypt, validation establishes control of the domain before certificates can be issued for it. Think of that as a narrow technical check, rather than a recommendation of the site's contents or the people behind it. A certificate is one part of operating HTTPS; it does not replace ordinary judgement about what a website says.
Validity and authorization reuse are different clocks. Validity describes how long an issued certificate lasts. Authorization reuse describes how long the issuer permits further issuance after domain control was validated. A plan for renewal should account for both, rather than assuming a successful check will remain reusable indefinitely.
Who sets the rules
The CA/Browser Forum describes itself as a voluntary gathering of certificate issuers and suppliers of browser software and other applications that use certificates. Its April 2025 ballot on validity and data reuse sets out reductions in both certificate lifetimes and the periods for reusing validation data.
Let's Encrypt explains that the Forum's Baseline Requirements set the technical requirements it must follow, and that other publicly trusted certificate authorities will be making similar changes. This is a useful distinction when comparing hosting plans: choosing a different issuer should not be treated as a substitute for maintaining a dependable renewal process.
From 398 days to 47
The ballot describes a reduction in maximum public TLS certificate validity from 398 days to 47 days, with reductions starting in March 2026 and concluding in March 2029. It also describes reducing reuse of Subject Alternative Name (SAN) validation data from 398 days to 10 days. The validity limit and the validation-data limit address different parts of issuance; one number should not stand in for the other.
These are maximum periods in a wider schedule, rather than a promise that every certificate lasts that long. For an owner, the practical question is the lifetime actually issued and the renewal behaviour configured for it.
The schedule for a free certificate
Let's Encrypt's published lifetime schedule plans to reduce its 90-day certificates to 45 days by 2028. Its default classic profile is scheduled to issue 64-day certificates from February 10, 2027, with a 10-day authorization reuse period. From February 16, 2028, the schedule calls for 45-day certificates and a seven-hour reuse period.
Its October 2026 implementation announcement says the 64-day default applies unless subscribers select a shorter lifetime. It expects the last 90-day certificate to expire on May 11, 2027, and says valid certificates will not be revoked as part of the transition. Keep the issuance date, expiry date, and planned renewal separate when reviewing a particular certificate.
Renew by automation, not by calendar
Let's Encrypt recommends ACME Renewal Information (ARI), which helps a renewal client know when to renew. If the client does not support ARI, its guidance accepts renewal at approximately two thirds of the current certificate's lifetime. A fixed 60-day renewal interval will no longer be sufficient for a 45-day certificate. Manual renewal is not recommended as lifetimes shorten.
Review the surrounding process as well as the renewal command. The October announcement recommends looking for hardcoded numbers such as 83, 80, or 60 in scheduled jobs, wrapper scripts, and runbooks. It also recommends testing in staging, automating installation and reloads, and adding alerts for renewal failures. Ask for a demonstration of the process and agree who responds if it fails.
Revocation after OCSP
In its OCSP end-of-life announcement, Let's Encrypt says it turned off that service on August 6, 2025, and now publishes revocation information exclusively through Certificate Revocation Lists (CRLs). This describes Let's Encrypt's service, rather than an announcement that every issuer has stopped using OCSP.
The stated reason was primarily privacy. An OCSP responder can learn which website a visitor's IP address is accessing when software checks that certificate's revocation status. Let's Encrypt says CRLs avoid that issue. Revocation information is distinct from routine renewal, so keep questions about status checking separate from questions about replacing an expiring certificate.
An owner's checklist
- Record the issuer, the actual certificate lifetime, and the renewal method.
- Ask whether the renewal client uses ARI or follows the current lifetime.
- Check that the process covers installation and reloads as well as issuance.
- Agree who receives failure alerts and who takes action on them.
- Include the renewal instructions in the handover to another maintainer.
When responsibility changes, ask the incoming maintainer to explain the renewal steps back in plain language. Resolve any uncertainty about access or failure alerts before relying on the arrangement.
Use those answers when assessing a hosting arrangement or agreeing a project handover. A useful explanation should make the next renewal understandable to the person responsible for it, without turning an automated task into a private calendar reminder.