CA/Browser Forum Votes for 47-Day Cert Durations By 2029 (computerworld.com) 69
"Members of the CA/Browser Forum have voted to slash cert lifespans from the current one year to 47 days," reports Computerworld, "placing an added burden on enterprise IT staff who must ensure they are updated."
In a move that will likely force IT to much more aggressively use web certificate automation services, the Certification Authority Browser Forum (CA/Browser Forum), a gathering of certificate issuers and suppliers of applications that use certificates, voted [last week] to radically slash the lifespan of the certificates that verify the ownership of sites.
The approved changes, which passed overwhelmingly, will be phased in gradually through March 2029, when the certs will only last 47 days.
This controversial change has been debated extensively for more than a year. The group's argument is that this will improve web security in various ways, but some have argued that the group's members have a strong alternative incentive, as they will be the ones earning more money due to this acceleration... Although the group voted overwhelmingly to approve the change, with zero "No" votes, not every member agreed with the decision; five members abstained...
In roughly one year, on March 15, 2026, the "maximum TLS certificate lifespan shrinks to 200 days. This accommodates a six-month renewal cadence. The DCV reuse period reduces to 200 days," according to the passed ballot. The next year, on March 15, 2027, the "maximum TLS certificate lifespan shrinks to 100 days. This accommodates a three-month renewal cadence. The DCV reuse period reduces to 100 days." And on March 15, 2029, "maximum TLS certificate lifespan shrinks to 47 days. This accommodates a one-month renewal cadence. The DCV reuse period reduces to 10 days."
The changes "were primarily pushed by Apple," according to the article, partly to allow more effective reactions to possible changes in cryptography.
And Apple also wrote that the shift "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."
Thanks to Slashdot reader itwbennett for sharing the news.
The approved changes, which passed overwhelmingly, will be phased in gradually through March 2029, when the certs will only last 47 days.
This controversial change has been debated extensively for more than a year. The group's argument is that this will improve web security in various ways, but some have argued that the group's members have a strong alternative incentive, as they will be the ones earning more money due to this acceleration... Although the group voted overwhelmingly to approve the change, with zero "No" votes, not every member agreed with the decision; five members abstained...
In roughly one year, on March 15, 2026, the "maximum TLS certificate lifespan shrinks to 200 days. This accommodates a six-month renewal cadence. The DCV reuse period reduces to 200 days," according to the passed ballot. The next year, on March 15, 2027, the "maximum TLS certificate lifespan shrinks to 100 days. This accommodates a three-month renewal cadence. The DCV reuse period reduces to 100 days." And on March 15, 2029, "maximum TLS certificate lifespan shrinks to 47 days. This accommodates a one-month renewal cadence. The DCV reuse period reduces to 10 days."
The changes "were primarily pushed by Apple," according to the article, partly to allow more effective reactions to possible changes in cryptography.
And Apple also wrote that the shift "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."
Thanks to Slashdot reader itwbennett for sharing the news.
Needed? Or money grab? (Score:1)
First post?
Re: (Score:3)
Needed because revocation is broken.
No money grab because there are several free CAs.
Re: (Score:1)
Needed because revocation is broken.
Then fix revocation so it isn't broken.
Making it 7x more expensive fixes nothing. This is a money grab, nothing more.
Re: Needed? Or money grab? (Score:2)
Re: Needed? Or money grab? (Score:3)
Steve Gibson is a monumental dickhead. Dropping his name does not do anything to convince me.
Re: (Score:3)
There are complex reasons revocation doesn't work and simply saying fix doesn't actually fix it.
There is no actual complexity. There are not so many keys compromised in the world a complete list of actually compromised keys can't easily be globally distributed to browsers with regular deltas. The only reason the obvious is not being done is security isn't actually the point of this scheme.
Re: (Score:2)
Re: (Score:3)
So far two mechanisms have been tried for dealing with compromised keys. Certificate revocation lists and Online Certificate Status Protocol. Both create more problems than they solve. A certificate can be revoked not just because it s key has been compromised, but also simply because it is no longer meant to be used. That happens quite a lot actually in the modern virtualized world.
What actually matters? Security or making sure internal administrative constraints are enforced? The revocation lists are full of administrative nonsense not actual security breaches that have any substantive real world implications for users.
How much is "certificate can be revoked not just because its key has been compromised" worth in the real world? Is it worth up to 45 days of ongoing compromise after there is a security breach because otherwise tombstoning compromised keys is "too hard"?
The notion
Re: (Score:3)
Re: (Score:3)
There are complex reasons revocation doesn't work and simply saying fix doesn't actually fix it.
Neither does shortening the duration. All it does is slightly shorten the maximum amount of time that someone can use a stole private key/cert combination. And if they don't discover that the key is compromised, chances are, the website will generate a new cert with the same key, and it won't even do that.
Revocation absolutely can work. You start by mandating OCSP, you follow it up by making browsers refuse to connect to TLS-enabled sides if OCSP servers are blocked, and you drag the certificate authorit
internal system / backend certs don't need this an (Score:2)
internal system / backend certs don't need this.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Correct me if I'm wrong but if browsers enforce this duration, then it IS affected.
It's generally not the browser that limits certificate lifetime -- the lifetime is embedded into the certificate and the browser enforces the expiration date baked into the certificate. If you run your own internal CA, you can issue certificates for whatever lifetime you want. You will have to add your internal CA's certificate to the browser's list of "trusted CAs" though. Depending on the browser, the list of trusted CAs may be configured within the browser install itself, or may be delegated to the opera
Re: (Score:2)
unless someone like google codes in some like if ca / cert life over XX days = mark ca / cert as untrusted.
Re: (Score:2)
unless someone like google codes in some like if ca / cert life over XX days = mark ca / cert as untrusted.
They could, but then they would not be following RFC 5280 [ietf.org] with regard to what defines a certificate's validity period.
Re: (Score:2)
Correct me if I'm wrong but if browsers enforce this duration, then it IS affected.
It's generally not the browser that limits certificate lifetime -- the lifetime is embedded into the certificate and the browser enforces the expiration date baked into the certificate. If you run your own internal CA, you can issue certificates for whatever lifetime you want. You will have to add your internal CA's certificate to the browser's list of "trusted CAs" though. Depending on the browser, the list of trusted CAs may be configured within the browser install itself, or may be delegated to the operating system's list of trusted CAs.
My quick reading of it looks like this is the max age that a browser will accept.
Any enterprise not using Automatic Certificate Management Environment (ACME) really needs to think about shifting to modern encryption infrastructure. Humans and AIs make mistakes and having an expired certificate because of human or AI error that causes your site to stop accepting traffic, if you have an enterprise level site, is ridiculous. If this causes any extra work for you, you're doing it wrong.
Re: (Score:2)
47 days (Score:2)
may seem random, but it's probably meant as 1.5 months plus a day of wiggle room. I was hoping for 42 though.
will renew fees be the same = pay an more or be sa (Score:2)
will renew fees be the same = pay an lot more or be same for 1 year?
Re: (Score:3)
Letsencrypt will be the winner from this - free and automated.
Re: (Score:2)
Letsencrypt will be the winner from this - free and automated.
I typically use zero SSL for important sites as letsencrypt has a rate limit that if you accidentally make a mistake and exceed can cause your certificates to not be renewed.
For most management tools it is a two line change to move from letsencrypt to zerossl, (change the endpoint you are hitting and your key) and it was fairly cheap to not risk hitting the rate limit. But, there are lots of options for ACME compatible certificate signers beyond just Mozilla's Let's Encrypt.
Re:will renew fees be the same = pay an more or be (Score:4, Interesting)
>"Letsencrypt will be the winner from this - free and automated."
Except in my case, one of our major platforms is outsourced but is a subdomain of my domain. So it is IMPOSSIBLE to automate it. It is a private site, but is reachable publicly for remote access. And I can't load the certificate on their system, only they can, and doing so is difficult and causes downtime. So it means countless hours of my time wasted in renewals, payments, reimbursements, scheduling tickets, uploading files, and downtime. Plus the constant risk of something in that chain failing or being missed and taking down all our operations. Once a year was already a total pain in the a**. I am really pissed about this.
One word (Score:4, Insightful)
One word: Automation.
Posting as anonymous coward for obvious reasons - my current employment is PKI.
This will drive automation to a new level. There is no way IT grunts will be manually renewing these certificates. ACME, or something spawned from that, will be the name of the game for trusted TLS certificates. I've worked for companies where changing the TLS certificate on their main public facing websites was a whole process wrapped up in change control. Those processes will also need to change as it doesn't make sense with all of the overhead the change control process can add, to do this every 30 days.
And if you are using TLS trusted certificates for internal-only facing systems, these will switch to private issuance, which do not need to follow the CA/B forum rules. For private issuance, you can issue certificates with validity that is in the hundred of years. There is absolutely no reason why internal systems need to use trusted certificates, and this will basically end that practice.
Many things already use private issuance certificates such as Intune - it would be insane to have your Intune infrastructure use Trusted TLS given the number of certificates are issued for Intune configured systems and authentication.
As an aside, the CA/B forum has also made OCSP optional, which over time you'll see less and less of. I know of some CA operators who are privately cheering for OCSP to go away as its a high volume real-time service that if it breaks, can break a lot of things rather quickly (speaking from experience).
change control issues or java app injecting issues (Score:3)
change control issues or java app injecting issues / downtime. Makes automation not work.
What about places where that cert change is part of an month or more long change control process?
Re: (Score:2)
Re: (Score:2)
There is absolutely no reason why internal systems need to use trusted certificates, and this will basically end that practice.
Being pedantic, but I assume you mean no reason for internal use of publicly trusted certificates. From a security point of view, it's a bad idea not to validate certificates on internal systems -- you need to validate them against your internal CA of course, but failure to validate would open you up to internal threats.
Re: (Score:2)
I assume you mean no reason for internal use of publicly trusted certificates.
If you're streaming video from a server on a home LAN or an air-gapped network to a smart TV or a streaming stick, the server will probably need a publicly trusted certificate. I've been told major brands of streaming device have no way to let the user install a privately trusted certificate.
Re: (Score:2)
Re: (Score:3)
One word: Automation.
Still needs testing and verification afterward. Now each instance will have ten chances to break each year instead of one.
I've worked for companies where changing the TLS certificate on their main public facing websites was a whole process wrapped up in change control.
Probably somebody broke it in the past. I've seen that happen too.
Re: (Score:2)
Which is likely to be better - first, something that breaks once every couple of years will likely be put up with because it's not worth putting in the effort of fixing. Except now that tribal knowledge is having to be passed on because no one can be bothered to fix it.
If it breaks every other time every few weeks, then there's much more incentive to fix it properly so it quits breaking
Re: (Score:2)
Once that knowledge gets put into scripts, if in a few months you discover the script overlooked something, you fix the script and make life simple.
A lot of stuff is complicated enough it is simply better to do in person. Zero impact changes often require failover/failback of HA pairs. Appliances like ASAs or F5s may have dozens of different cert chains on the same device. Not everyone can just use certbot in a cron job.
Re: (Score:2)
Re: (Score:2)
What's the uncomplicated way to change a certificate on a service on an air-gapped network, where you control the server and do not control the clients' certificate stores?
Re: (Score:1)
Subordinate CA is not trusted (Score:3)
Because you don't control the clients' certificate stores, your subordinate CA is not trusted. Instead, your server must use a certificate from a publicly trusted CA that the client already recognizes. And all the publicly trusted CAs are about to require a (roughly) monthly rotation.
Re: (Score:2)
Re: (Score:2)
Once that knowledge gets put into scripts, if in a few months you discover the script overlooked something, you fix the script and make life simple.
A lot of stuff is complicated enough it is simply better to do in person. Zero impact changes often require failover/failback of HA pairs. Appliances like ASAs or F5s may have dozens of different cert chains on the same device. Not everyone can just use certbot in a cron job.
F5s can be managed from the command line and can have their configs checked into code. F5 even offically supports ansible for managing it https://clouddocs.f5.com/produ... [f5.com]
So, it certainly can be managed from a cron job.
Re: (Score:2)
Re: (Score:2)
Which is likely to be better - first, something that breaks once every couple of years will likely be put up with because it's not worth putting in the effort of fixing. Except now that tribal knowledge is having to be passed on because no one can be bothered to fix it.
If it breaks every other time every few weeks, then there's much more incentive to fix it properly so it quits breaking so often. And something that breaks every few months is more likely to be passed onto the next guy because it's more recent information than something that only happens once every couple of years.
It likely happened because it's a process that doesn't happen often, so all the tricks you learned this time around are forgotten the next time it happens. When a certificate expires yearly, someone has to remember what they did last year in order to renew it all. And likely things broke because they forgot some things.
Once that knowledge gets put into scripts, if in a few months you discover the script overlooked something, you fix the script and make life simple. The script becomes the working memory and if something breaks, the script can be run through manually to ensure every piece is updated.
Also, there's a chance if something breaks, it'll get caught all that much quicker - someone moves a file somewhere and it's forgotten about a year later. Here it's only a month and a half and chances are someone remembers "Oh, we moved that a month ago!".
This ^
And the more complicated the more you want things to be fully automated. Manual enterprise deploys have about an 80% fail rate while automated deploys have a far less than 1% fail rate.
as for "you need to test your site after deploying a new certificate" If it is important enough to be paying someone to work on it, it should be monitored 24x7 anyways.
The biggest problem with the automated certificates is that the tooling around them is so good you have people who set them up and are in charge of th
Re: (Score:1)
This will drive automation to a new level. There is no way IT grunts will be manually renewing these certificates. ACME, or something spawned from that, will be the name of the game for trusted TLS certificates.
How many breaking changes have their been to ACME in the past few years and how many can we expect in the future?
Re: (Score:2)
This will drive automation to a new level. There is no way IT grunts will be manually renewing these certificates. ACME, or something spawned from that, will be the name of the game for trusted TLS certificates.
How many breaking changes have their been to ACME in the past few years and how many can we expect in the future??
Re: (Score:2)
Re: (Score:2)
>"One word: Automation."
Another three words: Not Possible Everywhere
I have outsourced systems that use subdomains of my domain and I can't control those systems or install certs on them. And the system is needed 24/7. And it needs to be accessed from everywhere. And installing a certificate means major effort, tickets, additional scheduling, payments, support time, downtime, etc. Doing it annually was already too much.
47 (Score:2)
Any insight why they picked 47 as the magic number? Why not 46 or 48? Or more likely a multiple of 7, to account for weeks?
Re: (Score:2)
I would guess ceil(31 * 1.5), but that's pretty arbitrary and (to me) 31+2*7 would make just as much sense.
Re: (Score:2)
Re: (Score:2)
Any insight why they picked 47 as the magic number? Why not 46 or 48? Or more likely a multiple of 7, to account for weeks?
I think for business purposes you'd want a multiple of 7 plus a few days extra, in case of unforeseen complications / emergencies - and 47 accomplishes that.
There's no reason you couldn't renew every 42 days under this stricture. Or schedule it "on the first Tuesday of each month".
Personally I see this as largely security theater, but trying to argue against it does seem like opposing the tides at this point...
sigh (Score:2)
All the legacy systems will be so broken. currently some of them are already a pain to update yearly, with no reasonable way to automate.
I guess there will be a need to put a reverse proxy with the automated certificate renewal in front of them.
Re: sigh (Score:2)
Hello, Cloudflare.
Re: sigh (Score:2)
How about no? (Score:5, Insightful)
At the rate they're going, they'll need to invent new low latency networking and data processing technologies in order to renew the certs before the old one (issued 30 seconds ago) expires.
Yay (Score:5, Insightful)
Re: (Score:3)
Google and Apple are not the internet.
They are, however, the publishers of the operating systems that run on the Internet terminals that most people keep closest to them most of the time.
Dentists also recommend cleanings every 47 days (Score:4, Insightful)
And please change your car's oil every 47 days.
For the exact same reason.
Re: (Score:1)
Well see, the US expired with the 47th president and now needs a reset. So the number makes sense.
Outcome: more problems, few benefits (Score:5, Interesting)
2. Other organizations will resort to automation, which will in turn make supply-chain attacks that leverage the automation much more attractive. I'll predict that within a year of this change going live we'll see just such an attack.
3. This isn't going to significantly increase aggregate security, because -- for the most part -- certificates aren't the security problem. Bad software, e.g. WordPress, that's widely deployed and poorly maintained is a much bigger problems.
4. The argument that this will stop some cryptographic exploits is weak, at best. The primary threats in that space are nations, and this change won't really affect them -- because they have far more resources than defenders, and they can readily deal with an 8X decrease in certificate duration by allocating 10X the computing power. (Which, since they're no doubt aware of this year-long debate, and since they know when this goes into effect, they have plenty of time to plan and execute.)
This is going to make things less secure (Score:2)
And for anyone saying there's no reason for an API to invalidate its certificates every 47 days, as soon as the one-year limit hit every API I work with and there's several switched to that. So the 47-day one is next.
Re: (Score:2)
When an API can use weak passwords, it can also generate its own certificate independently from any web certificate authority like for example, openvpn with easyrsa which generates its own certificate independently so your point is really moot. For web certificates used for access for the public at large, there is no weak password option. Furthermore, for internal web sites, you will still be able to generate your own certificates internally and independently and have them last several years if you wish. Th
Re: (Score:2)
DV CAs are redundant and dangerous (Score:3)
The CA scheme for DV is needlessly dangerous and redundant and needs to end. Existing schemes like ACME are still based entirely upon insecure indications from insecure protocols.
There is no reason for global overlapping trust anchors to exist in the first place. This only creates more avoidable avenues for global compromise with zero commensurate benefit.
More importantly it is redundant for a third party to seek to independently establish domain ownership when this function should just be a function of the domain registrar which already has an existing relationship with the domain owner. There was never any reason for CAs to insert themselves into the process in the first place. It used to be in the early days the CAs would validate you as an organization but that quickly devolved into a lights out process involving placing files in folders and servers making insecure HTTP requests to retrieve those files.
Neither do I accept the legitimacy of a handful of corporations voting for a change that has substantial global administrative impacts on countless millions of the worlds operators without any substantive outreach, study or consensus.
Personally I will be working to advocate for expansive use of PAKEs as an alternative to global trust anchors. Most every website worth securing has some form of independent trust relationship with the user. The insecure and dangerous universal practice of authentication via adhoc web forms in plain text over TLS has lead to unnecessary and substantially avoidable mass ownage via phishing related exploits. The utilization of secure authentication based on zero knowledge proofs is far more secure than DV certificates.
Most sites and internal applications should have never required PKI in the first place. This was always something that has been dominated by band-aids and inertia. A series of decisions that were rational at the time yet in totality have become untenable.
Global trust anchors should only have ever been used sparingly as onramps for service discovery and onboarding. It was always foolish to aggregate so much responsibility into the hands of the few with global potentially catastrophic consequences. It is past time to end DV certs as we know them.
Re: (Score:3)
Re: (Score:2)
ACME with a sane CA is about as strong as DV can get.
ACME is STILL based on INSECURE indications from INSECURE protocols. This isn't strength, it is a PATHETIC joke.
If you implement DNSSEC and use the DNS-01 challenge type, you have a trust chain for the ACME challenge itself.
If everyone had DNSSEC there would be no need for DV CAs and this would all be MOOT.
I'm going to ignore the rest of the rant as pointless.
If you have nothing to say keep your mouth shut.
Re: (Score:2)