[clintwilson]

SC-081 Preamble

Overview

• Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)
  • Eventual reduction of non-SAN validation data reuse from 825 to 398 days
  • Eventual reduction of SAN validation data reuse from 398 days to 10 days
• Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years
  • Eventual reduction of maximum validity period from 398 days to 47 days
• These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained ecosystem underpinning the foundational security properties of the internet. Since the TLS Baseline Requirements (TBRs) were first adopted in the CA/Browser Forum and subsequently incorporated into various Root Programs as an interoperable, basic threshold for participation, the topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have on the overall health and stability of the Web PKI.

The focus of this ballot is a set of changes to the TBRs. The TBRs address requirements only for certificates which are “intended to be used for authenticating servers accessible through the Internet” [1]. Certificates which match or are compatible with the profiles described in the TBRs can be (and are) used for a variety of purposes not addressed by the TBRs, but these use-cases are not directly in scope of the TBRs nor the changes proposed in this ballot.

The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period. While this requirement has been part of the TBRs since its first adopted version, the reality of certificate management practices — whether policy, practice, or technology — has not necessarily reflected such an expectation. Nonetheless, this is and has been the requirement presented by the TBRs.

Approach

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], it’s important to provide mechanisms for 1) substantiating previously unassessed risks and 2) altering course when necessary. Similarly, in order to shift more unknown unknowns towards known unknowns and known knowns over times, it is useful to ensure broad awareness prior to changes taking effect. In an effort to meet these goals, this ballot proposes multiple changes over an extended period of time with the intent of setting reasonable and attainable timelines upfront, while still allowing for future alterations if determined to be necessary [3].

Benefits

The value of continuing to reduce maximum certificate validity and data reuse periods remains evident today, as described in prior ballots which proposed similar changes [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1. Certificates are representations of a point in time state of reality. That is, at the point of certificate issuance, all data certified therein is correct and the process followed for that certification is accurately documented for that point in time (with some exceptions). The more time passes from that moment of issuance, the more likely it becomes that data represented in the certificate diverge from reality. Thus, a reduction to both certificate lifetimes and data reuse periods increases the average net reliability of certificates [6].
2. The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] and recent research reinforces this risk, whether with domain expiration, key access/control by third parties, or other “security-relevant events that enable a third-party to impersonate a domain outside their control” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.
3. As alluded to above, at times CAs do not issue certificates in accordance with the policies, requirements, or specifications which govern such issuance. Requiring more frequent validation of information used in the issuance of certificates and lowering the maximum validity period of certificates reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.
4. While not intended to be a primary benefit of this ballot, it is also worth noting that an ancillary benefit to these changes is expected in increased consistency of quality, stability, and availability of certificate lifecycle management components which enable automated issuance, replacement, and rotation of certificates. Increased deployment of robust, bi-directional automation is not a panacea for challenges in the Web PKI, but it certainly helps [9].
5. Certificate status services, such as CRLs and OCSP, are technologies which do not adequately protect relying parties at the current scale of the internet, whether due to privacy concerns, performance impacts, timeliness of relevant statuses, the accuracy (and usability) of data, or other inadequacies. A reduction to certificate lifetimes provides firm protection to users, independent of certificate status services, further reducing the associated costs to internet users.
6. Deprecating cryptographic algorithms used in the generation or certification of keys is typically a complex process affecting security-critical properties of certificate use. When factoring in the ever-present risk that a weakness may be identified with an algorithm, library, or similar component of the ecosystem at any time, with or without forewarning, it is vital that the Web PKI structure itself such that a response can be made rapidly and effectively. A reduced maximum validity period for TLS certificates provides substantial support for smoothly — and, when necessary, swiftly — transitioning between deployed and supported cryptography.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1. Scalability:
   1. Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.
2. Reliability:
   1. The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.
   2. Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.
   3. Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.
3. User Impact:
   1. Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

As with the problems described under Benefits, the problems associated with the use of certificate status services may be addressed with a variety of solutions, each requiring action by multiple parties — not all of which are represented within the CA/Browser Forum nor are those solutions fully within the scope of the Forum’s ability to guarantee adoption. Regardless, however, those problems are adjacent to, rather than encompassed by, the proactive measures sought within this Ballot.

Conclusion

Since its first version, the TLS Baseline Requirements have set timelines to reduce the validity period and restrict the data reuse period for the certificates issued under them. The value of doing so then remains largely the same as the value in doing so now. The value of doing so in Ballot 185 remains largely the same as doing so now. The value of doing so in Ballot SC-022 remains largely the same as doing so now. This Ballot takes a somewhat different approach than any prior reduction, but does so with the aim of providing early and clear communication around both near and far-term changes needed by Web PKI participants while retaining the space to assess and incorporate new information as it becomes available.

[1] - https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview
[2] - https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20211028135554557-0735:9781009039604:51076fig13_1b.png?pub-status=live
[3] - This follows a pattern present since Version 1 of the TBRs (which established an initial maximum validity period of 60 months along with a future reduction to 39 months) and most recently in Ballot SC-063 (which introduced an initial Short-Lived Subscriber Certificate validity period of 10 days with a future reduction to 7 days).
[4] - https://cabforum.org/2017/02/24/ballot-185-limiting-the-lifetime-of-certificates/
[5] - https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/#ballot-sc22-reduce-certificate-lifetimes-v2
[6] - Fundamentally, the above property of certificates is not something which can be addressed through revocation of certificates without much more substantial changes to the ecosystem.
[7] - https://insecure.design/
[8] - https://zanema.com/papers/imc23_stale_certs.pdf
[9] - https://www.hezmatt.org/~mpalmer/blog/2024/01/30/why-certificate-automation-matters.html

[ghost]

In this proposal: Tell me you've never worked in IT without telling me you've never worked in IT.

[XxPatrickxX]

Until the majority of software packages and hardware platforms support ACME or similar methods for automated device cert rollovers this is not viable.

• IIS does not natively support
• Tier 1 firewall vendors do not support
• IoT devices, lets not get started
• Most smaller SAS vendors

[DaxDupont]

This is not realistic suggestion as the vast majority of applications and devices do not support ACME. Especially in Windows heavy environments we see a lot of applications from anywhere in the SMB to Enterprise environments that are 'behind the times' so to speak.

It's a mix of legacy and still supported applications that suffer from the lack of ACME.

Have there been any examples recently of security issues posed by certificate theft where revocation wasn't sufficient where this period change would've helped?

[ajh0912]

I think this proposal is great, and definitely the right direction towards a healthier public CA ecosystem.

The majority of complaints regarding systems that cannot support automated renewal methods (eg ACME), are either systems that should not be exposed on the public internet and would be better suited to an internal CA - or systems that should be put behind a reverse proxy or web application firewall and use automated certificate renewal on that.

I think there are too many companies using certificates issued from publicly trusted CAs, where instead an internal CA is better suited. If you are having a public CA issue certificates, and are loading those certificates onto internal systems, only accessed by other internal systems - then you should most likely be using an internal CA instead.

Of course if you run your own internal CA you have full control of certificate validity periods, but you also take on the burden of ensuring a secure and available CA. That's the cost of having full control.

If this proposal is adopted, I would expect the major web browsers will also enforce some client-side validation of certificate validity periods much like was done for the 398 days validity. These validations only apply to certificates issued from public CAs, not CAs/certificates that have been added into enterprise trust stores etc.

If a company doesn't want to run their own internal CA, but wants full control over their certificates - there are privately rooted hosted solutions. 'PKIaaS' and managed PKI services is where a CA vendor runs your own CA for you. Of course the general public wouldn't trust these roots, much like an internal CA - they would be for internal corporate use rather than public websites etc.

[joe-berry]

Very funny this is coming from Apple, who has 0 skin in the game in the server world. They don't have a working server CA solution to issue certs to MacOS devices for 802.1x cert authentication. You have to use a windows CA for this. They don't manage any web server technologies, therefore don't have anything to change to help the world shift workloads towards this automation. ACME protocols are barely starting to gain adoption in the enterprise. Public CAs like digicert/entrust/verisign/sectigo are gouging prices for certificates which will directly drives business PKI costs up 884%. If let's encrypt free product fails, this will directly cause massive outages to the public internet and be extremely difficult to solve with no alternate solution available.
How about you go offer a free certificate service before you come changing public design for your own corporate interests.

[stebet]

Until the majority of software packages and hardware platforms support ACME or similar methods for automated device cert rollovers this is not viable.

• IIS does not natively support
• Tier 1 firewall vendors do not support
• IoT devices, lets not get started
• Most smaller SAS vendors

These providers and/or their users and community have a full year to respond with some features/functionality/scripts before this starts impacting any customers. If they can't respond in that time with some form of support or suggestions I'd see it as a huge flag to move away from them i.m.o.

[ajh0912]

@joe-berry

who has 0 skin in the game in the server world

Apple doesn't create their own server software as far as I know, but that doesn't mean they don't host or run server infrastructure. They run a lot of servers, for a lot of services.

They don't have a working server CA solution to issue certs to MacOS devices for 802.1x cert authentication

Apple don't need to make their own solution for enterprise authentication of 802.1x clients.

You have to use a windows CA for this.

No, you can use any CA?
It's common to use an MDM connector back into your existing internal CA, whatever that is.
Here's an example for Microsoft Intune MDM, where you use a connector into your existing internal CA for certificate issuance. This guide is for Windows's AD Certificate Services.
But there's nothing stopping you using any other CA your MDM solution will support, here's JAMF Pro's guide for using a hosted PKI solution from DigiCert.

ACME protocols are barely starting to gain adoption in the enterprise.

ACME-integration is available in most major web server technologies, if not natively - then by sidecar software.
Any custom-written web servers, legacy versions etc. should be placed behind a reverse proxy (and use automated renewal on that) or use an internal CA instead (as they should be internal only and not on the public internet).

Public CAs like digicert/entrust/verisign/sectigo are gouging prices for certificates which will directly drives business PKI costs up 884%.

With public CA certificate purchases, you do not purchase a 'certificate' instead it's more like buying a certificate term. You buy 1/2/3 year etc, and within that period you can rotate or re-key your cert however many times you want. If the max certificate validity period was lowered to 45 day, you would not be buying 8.84x 45 day certificates. You would buy 1 year worth of certificate time and end up re-keying ~9 times during that period. No change in purchase cost at all.

This already happened with the reduction to 398 days max validity, you used to buy a cert that was valid for a whole 2 years etc. Now you can still buy a '2 year cert' but you have to renew it in the middle of the 2-year purchase term.

If let's encrypt free product fails, this will directly cause massive outages to the public internet and be extremely difficult to solve with no alternate solution available.

There are multiple, no-cost public TLS certificate services available. Of course you are free to use a paid solution - nothing is stopping you. But I would limit my CA choice to only those who support automated certificate renewal (at no extra cost).

A few free ACME compatible public cert issuers:

• https://letsencrypt.org/
• https://pki.goog/ - Google Trust Services
• https://zerossl.com/

[ScottHelme]

Very funny this is coming from Apple, who has 0 skin in the game in the server world.

They have skin in the game as the party responsible for protecting the secure communications of over 1 billion iPhone users, not to mention iPad and Mac too! On top of this, it will also have a positive impact on the secure communications of billions of other people who use the Internet every, single, day.

[ajh0912]

@XxPatrickxX

Tier 1 firewall vendors do not support

Wouldn't you be using an internal CA / private PKI for the admin-interface for all internal network equipment?
If there was a specific reason to use a public CA, some vendors do actually support ACME already. For example FortiGate as of 7.0+ supports ACME for the admin web interface and for SSL-VPN. Their docs are open so easy to link to, but there are other vendors that support this.

For the likes of a remote-user VPN, again you could use an internal CA as all devices connecting would be corporate assets. But if you wanted to use a public CA, some SSL-VPN solutions have integration with ACME as above.

[stebet]

IIS tools for ACME: https://letsencrypt.org/docs/client-options/#clients-windows-/-iis

Firewall support for ACME:
Fortinet: https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/822087/automatically-provision-a-certificate
Juniper: https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-ipsec-vpn-acme-protocol.html
F5/BigIp: https://community.f5.com/kb/technicalarticles/automating-acmev2-certificate-management-on-big-ip/328935
Cisco: https://acme.cisco.com/acme/
And the list goes on...

My point being that this is supported pretty much everywhere in some way or another. It's just a matter of putting the relatively small amount of time into automating this and have your IT teams do more important stuff than manually going around updating certificates on servers.

[dmagdavector]

This is not realistic suggestion as the vast majority of applications and devices do not support ACME.

Or similar protocols, like SCEP:

• https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_Protocol

[jnewmaster]

Great.
Now actually make it reasonable for the industry by changing the timeline.
How did the decision for 9/2025 through 9/2027 come to be?

Give 2 more years runway with communication campaigns. 9/2027 through 9/2029.
That gets its "done by 2030".

This will start a monumental wave of technical dept across the open-source and closed-source software industries and that should be considered to take more time.

Frankly, even with that timeline, an already often-overburdened IT staff will now have significantly more work needing to be done for those systems which would not be implementing this on Internet-facing software by 9/2029.

The recent changes of validity duration has been a burden on Information Technology professionals due to software developers of all sizes generally ignoring it. They will try to ignore this and push the burden to Information Technology professionals this time as well, if only for a period of time.

That doesn't even address certificates that are exchanged with vendors. I know of many IT departments that exchange certificates with more vendors than they even have IT staff.

The issue should be pushed, but the professionals renewing the certificates will be most negatively-impacted if done too quickly.

[b02860de585071a2]

• IoT devices, lets not get started

IoT is 100% my biggest concern here, it's already a nightmare sometimes.

[bsanchezb]

Can you explain what is the reasoning behind the change? How come a qualified electronic certificate for eSignatures or eSeal may have validity range about 3-5 years, but TSL/SSL certificates become vulnerable after 45 days?

Why should we shorten validity range of the certificates, instead of relying on well-established revocation mechanisms?

Maybe the issue is not validity of the certificates, but the selection of trustworthy CAs? Would not it be better to filter trust service providers in more detail, instead of shifting the burden on businesses and users?

[ghost]

What's the target date to have certs expire after a femtosecond? This will make things more secure.

[blackhelicoptersdotnet]

@stebet

These providers and/or their users and community have a full year to respond with some features/functionality/scripts before this starts impacting any customers.

It is a very generous assumption indeed to suggest that users have the budget and manpower to rip and replace potentially millions of dollars worth of otherwise perfectly serviceable and supported infrastructure to meet this arbitrary deadline in 12 months' time.

This is assuming that all of their vendors are ready to go today, which obviously they won't be.

Cisco: https://acme.cisco.com/acme/ And the list goes on...

You clearly didn't even read this link.

This is Cisco's internal ACME service, established for their own use. It has nothing to do with their products.

[blackhelicoptersdotnet]

Let's say I have a system where I want people with personally-owned mobile devices to be able to interact with that system over HTTPS via a local wifi network. These systems have limited or nonexistent internet connectivity.

There are a lot of these out there; onboard entertainment systems on aircraft and vessels, mobile command centres used by emergency services etc.

At the moment, I can buy a commercial certificate, install that manually and then renew it every 12 months. With this proposal, this becomes something I would need to somehow do every 45 days.

Unless I'm missing something, the two workable alternatives I see are:

1. Don't use TLS
2. Use self signed certificates, and encourage users to click through the certificate warnings

Neither of these are particularly desirable.

[hanyuwei70]

I think it is better to rely on revocation than shorterning certificate lifetime.

[Viajaz]

Is this GitHub issue the appropriate place for non-forum members, such as companies or industry groups, to make a formal response to this proposal or should it be made on a mailing list?

[Fangliding]

It seems that this proposal is highly controversial
This will force people to use automated programs such as ACME to deploy certificates

[diagprov]

I have joined the public lists, but I have the same question r.e. commentary. Should it take place here or via e-mail?

@bsanchezb one major difference is that there is no requirement for server TLS certificates to protect the key in any way. For a qualified signature to have legal standing on its own merits under Swiss ZertES+ordonnances, or Europe's eIDAS, it must be issued on a qualified signature creation device - basically a smartcard/usb token/HSM. 3-year certificates are the maximum that can be issued here. Similar requirements exist for EV code signing, for example.

There's an alternative way to issue such certificates - temporarily in response to some other strong authentication mechanism. Quite a lot of web-based signing platforms in Europe that support qualified signatures integrates with such a "QTSP". These have even shorter lifetimes - minutes, not days, to mitigate any leakage risk.

More generally, I would point out that the currently accepted baseline requirements mean that if a CA becomes aware of a mis-issued subscriber certificate (including capitalisation bugs in their own software) then they must revoke it within 5 days. If they believe there is a security sensitive issue, then it is 24h. As a "subscriber" (you bought a certificate) you agreed to this in your terms and conditions.

So irrespective of the outcome of this ballot I would encourage considering how your business would respond to all of your certificates being replaced within 5 days, because it could be required that a CA do this right now. Or even 1 if you for example rely on them to generate keys and they discover their key generation is vulnerable e.g. ROCA.

I'm speaking as someone who works on PKI in organisations, but I am not a representative/employee of a CA or Browser and therefore not part of CA/B.

[dzacharo]

@clintwilson @wthayer can you please do a final review if all the pieces and relevant dates in 1.2.2 are correct? I had to do a re-base to sync the ballot branch with the latest changes in "main" and I'd like at least a second pair of eyes to make sure it was done correctly.

[wthayer]

I've reviewed the dates in section 1.2.2 - LGTM.

[oldthreefeng]

dm!!! apple.

[sierja]

This comment is for posterity, given that this has already been merged. However, I want to ensure that the issues described here cannot later be characterised as unforeseen.

I said in October 2024:

It should be noted that some governments have previously cut off internet access, to certain regions, for weeks (Sudan, Myanmar, Türkiye) or even months (India, Ethiopia, Chad, DR Congo) at a time.

This proposal would increase burden to operators in similarly affected regions, during what would probably already be a difficult time, and probably at a time where certificate chain validation is especially important for end-users in said regions.

With Iran’s internet shutdown now well into its second week, and with reports that there is a plan for Iran to become a "sealed intranet", it is providers and users in these regions that most need a trusted, untampered PKI, the kind the CA/Browser Forum aims to uphold. This proposal will make it extraordinarily difficult to obtain and maintain trustworthy certificates consistently. Shorter lifespans mean more frequent renewals, and renewals depend on connectivity that is neither ubiquitous nor reliably available in unstable regions. These are often the very places where secure communications are most critical.

The assumption that internet access is sufficiently ubiquitous and unimpeded for shorter-lifespan certificates to be viable in all parts of the world does not hold. Users in these regions are likely among the highest-risk populations in the world for interception, which makes an accessible and trustworthy PKI even more critical. The CA/B Forum should consider the end-users in lower-HDI countries in its decision-making and the real-world circumstances of those end-users on the ground.

Shorter certificate lifespans mean more renewals, which in turn means more frequent communication with CAs outside regional boundaries. In prolonged outage scenarios, this will likely push operators toward workarounds such as relying on untrusted or even hostile PKI, or retaining otherwise-valid CA/B-issued certificates beyond their lifetimes. Either outcome risks desensitising users in affected regions to certificate warnings, precisely where those warnings may matter most.

I would encourage the large technology companies that have pushed this proposal to consider, at least in the long term, alternatives to shorter certificate lifespans that address the underlying problems of existing certificate revocation mechanisms.

[heutger]

This comment is for posterity, given that this has already been merged. However, I want to ensure that the issues described here cannot later be characterised as unforeseen.

It's not too late. A few companies here forced a change without need (see in discussion, the real issue is, that revocation hasn't been adopted yet by the browsers in the right way, however, there are currently projects maybe to fix), as they just see their bubble and this is to enforce automation as in their world it works, ignoring anything else. As finally that underlines misusage of their market power, you could case a file with FTC, EU, ... which may stop this procedure. However the authors also "accepted" with their step-by-step going down, that there may arise issues once they stop down further, so maybe (or better hopefully) they will be able to recognize their mistake before it's too late.

[GryBsh]

However the authors also "accepted" with their step-by-step going down, that there may arise issues once they stop down further, so maybe (or better hopefully) they will be able to recognize their mistake before it's too late.

I wouldn't put money on that. All sorts of people made many good points on why shorter validity windows were absolutely not a preferable solution to legitimate threats over fixing clear and evident defects in how browsers implement chain trust or mitigating problematic aspects of validation. It's impossible to credibly say to anyone that some mechanism to background fetch or distribute CRLs periodically can't be devised, for example.

And yet, merged.

[heutger]

However the authors also "accepted" with their step-by-step going down, that there may arise issues once they stop down further, so maybe (or better hopefully) they will be able to recognize their mistake before it's too late.

I wouldn't put money on that. All sorts of people made many good points on why shorter validity windows were absolutely not a preferable solution to legitimate threats over fixing clear and evident defects in how browsers implement chain trust or mitigating problematic aspects of validation. It's impossible to credibly say to anyone that some mechanism to background fetch or distribute CRLs periodically can't be devised, for example.

And yet, merged.

Following the move that forced D-Trust to replace certificates with a validity period of over one year over Easter due to CA/B Forum requirements, the backlash against the “community” or “industry” has intensified significantly, as can be seen from a quick glance at technical articles and posts. Furthermore, the reduction in certificate validity periods has not yet sunk in for most people and is currently leading to some strong reactions. Let’s hope that the antitrust and regulatory authorities take note of this as well.

[rpedrica]

On 2026/04/07 18:15, Christian Heutger wrote: *heutger* left a comment (cabforum/servercert#553) <#553 (comment)> However the authors also "accepted" with their step-by-step going down, that there may arise issues once they stop down further, so maybe (or better hopefully) they will be able to recognize their mistake before it's too late. I wouldn't put money on that. All sorts of people made many good points on why shorter validity windows were absolutely not a preferable solution to legitimate threats over fixing clear and evident defects in how browsers implement chain trust or mitigating problematic aspects of validation. It's impossible to credibly say to anyone that some mechanism to background fetch or distribute CRLs periodically can't be devised, for example. And yet, merged. Following the move that forced D-Trust to replace certificates with a validity period of over one year over Easter due to CA/B Forum requirements, the backlash against the “community” or “industry” has intensified significantly, as can be seen from a quick glance at technical articles and posts. Furthermore, the reduction in certificate validity periods has not yet sunk in for most people and is currently leading to some strong reactions. Let’s hope that the antitrust and regulatory authorities take note of this as well. — Reply to this email directly, view it on GitHub <#553 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHYDXVFFPVT3TL5O5GYNGL4UUZRXAVCNFSM6AAAAABPVSRTGKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMBQHA4TSNZRHE>. You are receiving this because you commented.Message ID: ***@***.***>

CRLite was Mozilla's fixed revocation system introduced around Firefox 135 (along with cert transparency), and resolves the CRL/OCSP issue completely. It also seems to have been ignored by the CA/B .... Like many political and social activism movements these days, certain interests in IT seem to take preference overriding either majority view, majority benefit or logic. And this madness doesn't end. Code-signing certs are now pretty much a requirement for anyone releasing software apps, and the certificate mafia have decided to "raise the roof" on costs - eg. Digicert is $ 996/yr!!! How can small devs afford this especially in the age of ci/cd? - the CA/B has reduced the lifetime of these certs from 39 months to 15 months ... for zero reason! -  they've already mandated HSMs (or expensive cloud signing - and we know how secure cloud stuff is) - AND there are caps on the number of signings you can do per period / per app The benefits run only one way with certs. R.

[heutger]

CRLite was Mozilla's fixed revocation system introduced around Firefox 135 (along with cert transparency), and resolves the CRL/OCSP issue completely. It also seems to have been ignored by the CA/B .... Like many political and social activism movements these days, certain interests in IT seem to take preference overriding either majority view, majority benefit or logic. And this madness doesn't end. Code-signing certs are now pretty much a requirement for anyone releasing software apps, and the certificate mafia have decided to "raise the roof" on costs - eg. Digicert is $ 996/yr!!! How can small devs afford this especially in the age of ci/cd? - the CA/B has reduced the lifetime of these certs from 39 months to 15 months ... for zero reason! -  they've already mandated HSMs (or expensive cloud signing - and we know how secure cloud stuff is) - AND there are caps on the number of signings you can do per period / per app The benefits run only one way with certs. R.

100% agree. Lifetime reduction also resulted in less security in my home IT. I won't secure printer UI, ad blocking UI, heating control UI, wifi control UI, home control UI, voice assistant for home control UI any more as all of them have no automation module and I don't want to manually change certs, great job!

[wwadepohl]

100% agree. Lifetime reduction also resulted in less security in my home IT. I won't secure printer UI, ad blocking UI, heating control UI, wifi control UI, home control UI, voice assistant for home control UI any more as all of them have no automation module and I don't want to manually change certs, great job!

This affects also private systems. They postulate "These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet". But, the Browser Manufactures ignore this and put the same requirements on all CAs whatever the CA is private and not in the list or not. This breaks whole private IoT systems. Noone of the members of the browser forum cares. For they it seems there is only one usecase of certificates out. Simple Minds.

[romanf]

I'm working for a CA and we are not under any pressure or obligation from root store operators (Browsers) to reduce validity of certificates from private roots.

Of course, the browsers per default only trust roots from CAs that are in their root store. But every user is free to add additional trusted roots (i.e. private roots). In many browsers this can be done via central policies to include e.g. private roots that are used purely internally for device authentication or similar use-cases.

Kind regards
Roman

[rpedrica]

Thanks Roman, You are correct, within context. But ... 1. not everyone has the skills, capacity or budget to run a local root CA 2. not everyone should need to run a local root just to manage some private devices I think the point here is that browsers should allow (with appropriate notices) local exception methods. But we're getting off-topic now - this is a browser issue, not a CA issue. Regards Robby

…

On 2026/05/29 12:03, Roman wrote: *romanf* left a comment (cabforum/servercert#553) <#553 (comment)> I'm working for a CA and we are not under any pressure or obligation from root store operators (Browsers) to reduce validity of certificates from private roots. Of course, the browsers per default only trust roots from CAs that are in their root store. But every user is free to add additional trusted roots (i.e. private roots). In many browsers this can be done via central policies to include e.g. private roots that are used purely internally for device authentication or similar use-cases. Kind regards Roman — Reply to this email directly, view it on GitHub <#553?email_source=notifications&email_token=AAHYDXQ4F7KCKF35KKICMGL45FU7VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJXGQYTQOJTGQ32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4574189347>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHYDXTEP7JNULDCR63HUTT45FU7VAVCNFSM6AAAAABPVSRTGKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNZUGE4DSMZUG4>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAHYDXXEF26SM6FNKJUALPT45FU7VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJXGQYTQOJTGQ32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AAHYDXU6UENRYR54LOPNJED45FU7VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJXGQYTQOJTGQ32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[wwadepohl]

I'm working for a CA and we are not under any pressure or obligation from root store operators (Browsers) to reduce validity of certificates from private roots.

Of course, the browsers per default only trust roots from CAs that are in their root store. But every user is free to add additional trusted roots (i.e. private roots). In many browsers this can be done via central policies to include e.g. private roots that are used purely internally for device authentication or similar use-cases.

Kind regards Roman

I think you misunderstood me. We already add private roots. But, for example, Safari applies its policies about lifetime also for the added private root, but the CA/B stadard does not enforce this, in contrast it should not. That is a major problem, because I have to update certs of thouthands of IoT devices over s small bandwidth connection in very short interval. The other side of the mTLS is no problem, because it is totally under our control.

BTW shortening the lifetime is not a wise solution to the problem. Invalidating a cert just after it's issue will solve it, but make the whole thing useless. Revocation is not as bad as some people say, but they want the bandwith used for ads and not for revocation list.

[wwadepohl]

browsers should allow (with appropriate notices) local exception methods. But we're getting off-topic now - this is a browser issue, not a CA issue.

But the browser bros drive the shortening of lifetime. And lifetime is a CA/B issue. IMHO It is at least partially on-topic.

[barkermn01]

100% agree. Lifetime reduction also resulted in less security in my home IT. I won't secure printer UI, ad blocking UI, heating control UI, wifi control UI, home control UI, voice assistant for home control UI any more as all of them have no automation module and I don't want to manually change certs, great job!

not to mention a lot of enterprise firewalls do not even have support for ACME, so there goes all firewall UI's security.