Towards monthly certificate renewal

Last updated: January 2026

In late 2024, Apple shocked everyone with a move to reduce the maximum certificate lifetime to only 45 days. It took a few months and a couple of small revisions, but by April 2025 the deal was done as CA/Browser Forum ballot SC-081v3. In case you're not already familiar, the changes are pretty drastic, reducing the maximum allowed certificate lifetime from the current 398 days to only 47 days in March 2029. There's no time to dally, either, because there are two intermediary milestones: the first reduction is to 200 days in March 2026 (around the corner!) and the second to 100 days in March 2027.

In practice, we are transitioning from yearly renewals today, to twice a year in 2026, to quarterly in 2027, and finally monthly in 2029. 

As a result, everyone is scrambling to find where they have public certificates and then implement automation. In the long term, these changes will make things better, but the additional short-term workload they create are a substantial burden for many.

Let's Encrypt, the free CA where most of the world gets their certificates from, and the CA that pioneered 90-day certificates, has a more aggressive schedule: they'll reduce their certificates to 45 days in February 2028. You probably don't care much about that. Their certificates are always issued automatically, which means that there won't be anything to do except observe the change.

There are many good arguments to be made for shorter certificate lifetimes. Consider the following:

• Manual renewal is wasteful. Countless work hours have been spent on planning, coordinating, and executing on this menial activity. Additionally, every time there is a manual change, there is a chance of breaking something, and fixing that requires further resources. Manual renewal becomes unfeasible when certificate lifetimes are short, and that will, in turn, effectively require everyone to implement automation. Everyone will be much better off in the long term.
• Automated renewal is agile. Public PKIs put a lot of emphasis on the correctness of the certificates. Being strict avoids long and heated conversations about whether a particular mistake is significant enough to warrant misissuance. The ecosystem settled on being pedantic as a way of avoiding such conversations. Because of this, when mistakes are made they have to be corrected, even when there is no practical impact. Forced certificate renewal due CAs' mistakes never goes down well with customers, but automation is a way to solve that. In RFC 9773, ACME has been extended with the ability for CAs to trigger automated renewal of broken certificates.
• Shorter lifetimes support cryptographic agility. Back in the day, we used to rely on the SHA1 hash function for the certificate signatures, only to realise one day that this hash function is broken. The migration to SHA2 took a long time, in part because there were many long-lived certificates that were using SHA1. Browsers therefore couldn't just stop accepting them as they would cause a lot of immediate breakage. With shorter certificate lifetimes, similar problems will be easier to deal with.
• Revocation checking is not being done. A couple of years ago, major browsers decided to forego revocation checking, citing performance, availability, and privacy issues. (Firefox is the only exception, they instead implemented something called CRLite, which is currently deployed in their desktop platforms.This creates an awkward situation: if a certificate is compromised, there is a very long window of opportunity of up to 398 days for someone to abuse it. Reducing certificate lifetime is the only reliable way to deal with this problem.
• Residual certificates are everywhere. These days it's become rare to get your own certificates. Instead, we sign up for platforms, which get certificates on our behalf. That's one fuzzy aspect of public PKIs—these certificates bear our domain names but they are under control of a third party. So whose certificates are they? When you move service from one platform to another, your older certificates remain active… somewhere. The same happens when domain name ownership is changed; the previous owner retains some control over the domain name that no longer belongs to them. More information is available in this research paper. Shorter certificate lifetimes will reduce the impact of this problem as well.

It's clear that this is a good thing, but it's less clear why 47 days should be where we end up. You could argue that 90 days would achieve the same purpose, with less chance to overload the issuance and monitoring mechanisms. On the other hand, we could see another push for even further reduced maximum lifetimes in the future… but it'd be very difficult to justify further reduction for everyone.

In their 2024 Annual Report, the Internet Security Research Group (ISRG, the home of Let's Encrypt) took reduction of certificate lifetimes to the extreme and announced six-day certificates for 2025. These will not make sense for most organisations, but are a perfect fit for those who want to minimise the danger of compromised certificates. In the worst case, the window of exposure is only six days. That's actually better than the guarantees provided by online revocation checking (as implemented in practice), which was 7 days.

I enjoy a bit of PKI archeology, so I spent some time researching the history of maximum certificate lifetimes. In some ways, the changes made over the years are a reflection on the evolution of public PKIs, from a "wild west" situation in the beginning, to being strictly regulated and closely monitored, where we are today. It's a bit of a soap opera as well.

The first restrictions were introduced with the first release of CA/Browser Forums' Baseline Requirements (BR) document, which specifies how certificates should be issued. Before BR, there were no limits as such, and it was possible to get a certificate for 10 years if you were so inclined. The first BR version capped the lifetimes to 60 months initially in 2012, with a further reduction to 39 months postponed to 2015.

Two years later, in 2017, there was first a failed ballot (Ballot 185) to restrict certificates to 398 days. Virtually all CAs voted "no". Interestingly, two browser vendors also voted "no" and one abstained. However, just a month later, Ballot 193 succeeded, and reduced certificate lifetimes to 825 days.

Two years later, in October 2019, the second attempt to reduce certificate lifetime to 398 days (Ballot SC-022v2) also failed. CAs again didn't like this proposal. Reading through the justifications, the main reason was increased customer load. Doing something twice often is twice as costly. Browsers feel no customer pain, but CAs do, and their incentives were not aligned. This ballot, like no other, exposed the existing deep rift between browsers and CAs.

In the end, even though Google was the force behind SC022, Apple made a unilateral decision and, at the CA/Browser Forum meeting in February 2020, announced that, from September 2020, they would not accept new certificates valid for more than 398 days. Formally, changes to BR were made in Ballot SC-031, enthusiastically named "Browser Alignment".

As you already know, Apple was also behind the most recent push to 47 days. This time, most CAs voted for the proposal. It's a question of how many really wanted to, and how many felt they had no choice.

To be fair, the situation in 2025 feels much better when it comes to automation, after 10 years of automated issuance via Automatic Certificate Management Environment (ACME). There is a sense perhaps that comprehensive automation is within our grasp? Also, the ballot has been clear about adopting a staged approach so that we can reverse course if we encounter a significant obstacle.

A closer reading of Ballot SC-081v3 (which introduced the final reduced certificate lifetimes) reveals that there is a similar reduction to the validation reuse periods. If you're not familiar with PKI, you may not even be aware that certificate validations can be reused, but they can.

Back in the day, when most validation was manual, the ability to reuse validation results was a fantastic time saver for customers and CAs. CAs would validate their customers and their domain names only periodically, after which they would be able to issue certificates [for their properties] pretty much instantly. Anyone who's gone through manual validation knows that this is a process that could take days. This approach made perfect sense and saved everyone a ton of work.

For subject validation (e.g., organisation identity), the limit is currently 825 days, but that's being reduced to 398 days in March 2026, and no reductions after that. This activity has to be done manually and requires a lot of effort, which is why it makes sense to allow longer reuse.

On the other hand, reuse of validation results of domain names and IP addresses, which can be fully automated, will be reduced in a similar pattern as certificate lifetimes, but the last milestone will be just 10 days.

These changes represent another push toward automating everything that can be automated. It's part of a larger cleanup work, which also involved deprecation of the older validation methods, such as WHOIS, email, and telephone communication (for example SC-090, SC-091, and SC-080v3). As a result, domain owners will have more say over who can issue for their properties. It won't necessarily mean more work for either party, however, as new features are being introduced that focus on continuous signalling of who is allowed to issue, such as a persistent DNS record for domain validation (also part of SC-091).