CA/Browser Forum Votes for 47-Day Cert Durations By 2029 (computerworld.com) 114
"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.
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: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:1)
The renew fee will be the same. I mean, the same ammount you paid for 1 year you will now pay for 47 days, naturally. What did you expect?
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.
Re: (Score:2)
I assumed you already looked into it, but ACME has a way to use DNS validation with a totally unrelated domain. Just need to add an CNAME entry to the original domain to a domain you control. Then the DNS validation can update the domain you control while renewing the domain you don't control.
Re: (Score:2)
>"I assumed you already looked into it [ACME]"
I haven't, but will. I have no idea if that can help in this odd situation in which I am stuck.
To me, this radical shortening of certificate duration really does look like a bunch of "security theater" and full of potential conflicts of interest. My posting was to point out that, despite what appears to be the majority opinion, there are minority cases (of which I am one) where it will cause a lot of damage.
It is easy for people to dismiss such cases as "yo
Re: (Score:2)
For the record, I agree with you on the security theater here. I have a hard time understanding their reasoning.
On the actual technical "solution", I have yet to encounter a situation where this does not work if a) the registrar/dns provider supports API access and B) you can get a cname pointed to a domain you control in the zone you do not control.
The way this works is that when doing the verification, you tell it to check a specific sub-domain. This subdomain is a cname that points to a domain you cont
Re: (Score:2)
Yes, review here: https://www.eff.org/deeplinks/... [eff.org], particularly the section Use a "Throwaway" Validation Domain.
The parent domain can just set up the acme challenge CNAME for your subdomain and point it at some domain you do control.
Re: (Score:2)
One word (Score:5, 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: change control issues or java app injecting is (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?
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:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Maybe just accept that your Enterprise VPN is shit if it tells you that a certificate rotation needs a restart or disconnecting running connections.
I just told you it doesn't, that is the whole point. It is also not just "push button to install new cert" done remotely from home office or running as a cron job. There can be a lot of moving pieces between the endpoints - reverse proxies, load balancers, application firewalls, etc. You may think it is a solved problem in code but in the real world actual thought and planning are still required. I also don't think changing security certificates should be tho
Re: (Score:2)
Re: (Score:2)
https://support.apple.com/en-c... [apple.com]
Re: (Score:2)
I never had to manually accept a certificate for WiFi. Guess I was holding it wrong. Oh wait, no. Those RADIUS servers had competent admins that served a certificate chain to a trust root. I guess it explains why you are retied when you still couldn't figure out automation of certificate rollover..
Most of the popular wireless supplicants (windows, android..etc) are insecure by default and will accept literally any certificate. There is no relationship between the identity of the certificate and the network as there would be in a browser going to a given URL where the domain name entered is required to match the name on the cert.
Even if the system accepts only valid certs from a valid trust anchor the system is still completely insecure because anyone can attain such a certificate. The only practica
Re: (Score:2)
apachectl graceful will reload the new cert without dropping any connections. It might wait until there are no active connections although I'd have to double check.
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: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.
Re: (Score:2)
I use a reverse proxy and manage all TLS there to solve those issues.
Re: (Score:2)
Re: (Score:2)
I'll bite: How do you automate this with java applications and jks ? (in a secure way)
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)
If ACME is not to your liking, consider other certificate management protocols, like CMP (RFC 4210 and RFC 4210bis). Modern versions of OpenSSL have a built-in CMP client.
Re: (Score:2)
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)
The first assumption made is that it is recommended to update certificates after around 2/3 of their life time.
Why is this recommendation made for monthly renewals but not 3- or 6-month renewals, which have 100- and 200-day expirations respectively? With a nominal 30-day month, those give only 10 or 20 days of margin respectively, a far cry from the 50% you posit. The three-month cycle gives fewer days of margin than the one-month cycle. It gives the impression of being rather arbitrary, not based on that kind of assumption or recommendation.
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:3)
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: (Score:2)
Cloudfire does not work well inside your own network...
Re: sigh (Score:2)
Re: (Score:2)
Most of the systems I was talking about were things in categories you mentioned.
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:2)
I often see references to frequent oil changes. Question: Did the concept of better oil and better engines miss America entirely? Car manufacturers (at least in Europe) have never in history recommended oil changes as infrequently as they currently do. In many cases it's not even done as part of yearly inspections anymore.
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:4, Interesting)
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.
Licensing servers (Score:3)
Re: (Score:2)
23.5% of the previous lifespan... (Score:2)
Does this solve a real problem? (Score:2)
Does this solve a real problem? That old certificates are "cracked"?
It's not only websites that use TLS (Score:2)
As the CA/Browser forum said in their response to this, they feel automation is the key. Protocols like ACME do exist, but really only exist for web servers.
People forget that it's more than websites that exist on the internet that use PKI infrastructure. Your printer sitting on your desk -- that's got embedded certs. Have a phone? Yup, that has certs loaded into it as well to do encrypted phone calls. LDAP servers, directory servers, mail servers, API servers, game servers, etc. Hell, that IoT lightbu
Re: (Score:2)
> Protocols like ACME do exist, but really only exist for web servers.
That's not so, an example I mentioned in another thread is the Certificate Management Protocol (CMP, RFC 4210 and its follow-up RFC 4210bis), it is versatile and applicable in context other than web-servers. There are open source CMP client implementations, even OpenSSL 3.x has one - so it is easy to start prototyping and automating your workflow by wrapping `openssl cmp` into scripts.
Start with https://docs.openssl.org/maste... [openssl.org]
break everything (Score:2)
Break everything every few months. You must upgrade today today, right away, today.
Makes everything more fragile (Score:2)
Instead of a chance to break once per year, now your certificate process can break every 47 days, or even more often.
For a lot of services, even most services, this is overkill. How about letting each service decide?
Great (Score:2)
Driven by the CA industry? (Score:2)
I get the feeling this is driven by the Certificate Authority industry rather than any real need. Their biggest concerns are for compromises in the issuing process, where the wrong parties get issued a certificate they shouldn't have. There's a revocation protocol already defined, but the CAs would rather make certificates expire faster than support revocation lists. This incidentally makes them more money issuing new certificates. Maybe we should push for better support of OCSP so compromised certificates
The real message (Score:2)
People keep assuming that there must be some kind of profit-driven fuckery to explain this lunacy. It has to be something other than the bullshit facade they're trying to sell. Perhaps they simply cannot say what the real reason is.
I think the real message cannot be said out loud. It's likely that there's no better way to insert/remove a multi-keyed signing cert (for 3rd party snooping) into the chain without the renewals being fully automated. The meddlesome admins that maintain these systems would sta
Re: (Score:3)
Needed because revocation is broken.
No money grab because there are several free CAs.
Re: Needed? Or money grab? (Score:2)
Re: Needed? Or money grab? (Score:3, Insightful)
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:2)
I love that you are just ignoring what others are saying. Let's ignore web servers for a moment and look at client certificates where the very same problems exist.
If I have a client certificate on a smartcard, there are three main reasons for a revocation: (1) the smartcard was stolen (2) the smartcard had to be reissued (since it was "broken") or (3) the account was closed. In most environments, (2) and (3) are much, much more common than (1), but are entirely valid reasons for revocations with real world security impacts. For a big company like IBM with around 300,000 employees, just normal fluctuation would result in thousands of CRL entries at any given moment. Now you still would need to send the CRL to any service in a timely manner. Wait, some servers are offline in sealed networks? Though luck. The servers are in a remote location with very expensive internet (like the Easter Islands?)? Guess security is going to cost you.
This is completely unrelated to DV certs and a misunderstanding of the technology. DV CAs generally don't issue client certs. This is done by corporate CAs or adhoc to protect one off services. The purpose of the client certificate is authentication rather than authorization.
If you lose a smart card or it is stolen the security of the system is never at any point dependent upon certificate expiry, revocation or correct operation of CRLs. What actually occurs is the card is no longer authorized to access
Re: Needed? Or money grab? (Score:5, Interesting)
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 authorities' reliability kicking and screaming up to the seven nines required for a site that is mission-critical.
Or we can take a step back, acknowledge that HTTPS Everywhere was a mistake, and start over, separating the need for identity/trust and encryption.
Before the push to enable HTTPS for every website, a certificate meant something. It cost a lot of money, so anybody who had one was very likely to be legitimate. Now, TLS is useless for identity/trust purposes, because without doing a detailed look at the cert, I can't tell the difference between my completely untrustworthy personal website with a LetsEncrypt cert and Amazon.com.
We need a new protocol — let's call it HTTPE for encrypted — in which traffic is encrypted with a key that is stored similar to the way SSH does, where once you have established a link, future connections will be encrypted. This would give you trust that you're still dealing with the same site, but without the need for any bulls**t certificates that provide zero benefit for that use case, and cause ever-increasing headaches as the certificate authorities find new and more creative ways to make life miserable for site admins.
And of course, you would still have the strong HTTPS version in parallel, which would be used for e-commerce sites, banks, and other sites where the site's identity actually matters. You would just have a *lot* fewer of those. No more low-quality certs. Everything is a paid cert, everything requires proving more than just that you control the web server. Extended validation only, ideally.
The HTTPS CA folks could then do whatever the heck they want with stupidly short expiration periods, or better, mandate OCSP and high reliability, and it wouldn't matter for the other 99% of traffic for which the mere existence of a cert likely provides zero benefit, much less expiration thereof.
Re: (Score:2)
Or we can take a step back, acknowledge that HTTPS Everywhere was a mistake, and start over, separating the need for identity/trust and encryption.
We had that already in the form of extended validation certificates. For a brief period in history when you went to bankofamerica.com you didn't see the URL in the title, you saw a verified check of their identity instead.
The world abandoned the identity model in favour of simple encryption. That wasn't the fault of HTTPS Everywhere which was still an objectively good thing. The ability to provide an encrypted session should never have been the subject of a financial expense.
Re: (Score:2)
The ability to provide an encrypted session should never have been the subject of a financial expense.
Even without the financial expense: imagine that you manage a fleet of IP cameras in a secure building. They use HTTPS, hence they require certs. The only way to update the certs is to connect to each one's web interface and upload the certs. Usually this is no problem, you make the 10-year wildcard cert *.camera.internal.net and you are done.
Re: (Score:2)
The ability to provide an encrypted session should never have been the subject of a financial expense.
Even without the financial expense: imagine that you manage a fleet of IP cameras in a secure building. They use HTTPS, hence they require certs. The only way to update the certs is to connect to each one's web interface and upload the certs. Usually this is no problem, you make the 10-year wildcard cert *.camera.internal.net and you are done.
Put another way, short-duration certificate mandates are a financial expense. They're just a different kind of financial expense. They're infrastructure that has to be built and maintained, and possibly very site-specific infrastructure. Certificates are entirely the wrong choice for that use case, and really, for all offline and semi-offline use cases, because revocation is basically useless in that situation anyway, so you're taking on a lot of extra effort for no benefit.
Re: (Score:2)
This resonates with me because I manage a fleet of embedded devices where renewing certificates is a big deal! Te company ships the devices with a given certificate, and some (but not all) organizations will replace the certificates. Those organizations also put the devices in an SDMZ that blocks all outgoing traffic. So updating the certificates is currently manual. The devices browsing the embedded devices are similarly limited, so no OCSP or CRL validation is allowed. We recently released an update
Re: (Score:2)
OCSP does not work for multiple reasons.
For reasons I do not understand, letsencrypt also doesn't want to use OCSP-stapling what is (together with must-stable) kind of providing certificates that last only a few hours by requiring a current OCSP response being sent in addition.
So they now rely on CRLs. And having only 47 days lifetime limits the size of the CRL.