24 ms·

TLS certificate lifetimes will officially reduce to 47 days

• ocdtrekkie 2y ago
  It's hard to express how absolutely catastrophic this is for the Internet, and how incompetent a group of people have to be to vote 25/0 for increasing a problem that breaks the Internet for many organizations yearly by a factor of ten for zero appreciable security benefit. Everyone in the CA/B should be fired from their respective employers, and we honestly need to wholesale plan to dump PKI by 2029 if we can't get a resolution to this.
  • rcxdude 2y ago
    A large part of why it breaks things is because it only happens yearly. If you rotate certs on a regular pace, you actually get good at it and it stops breaking, ever. (basically everything I've set up with letsencrypt has needed zero maintenance, for example)
    • ocdtrekkie 2y ago
      So at a 47 day cadence, it's true we'll have to regularly maintain it: We'll need to hire another staff member to constantly do nothing but. (Most of the software we use does not support automated rotation yet. I assume some will due to this change, but certainly not 100%.) And also, it probably won't avoid problems. Because yes, the goal is automation and a couple weeks ago I was trying to access a site from an extremely large infrastructure security company which rotates their certificates every 24 hours. And their site was broke and the subreddit about their company was all complaining about it. Turns out automated daily rotation just means 365 more opportunities for breakage a year. Even regular processes break, and now we're multiplying the breaking points... and again, at no real security benefit. There’s like... never ever been a case where a certificate leak caused a breach.
      • Avamander 2y ago
        > So at a 47 day cadence, it's true we'll have to regularly maintain it: We'll need to hire another staff member to constantly do nothing but. (Most of the software we use does not support automated rotation yet. I assume some will due to this change, but certainly not 100%.) This is fundamentally a skill issue. If a human can replace the certificate, so can a machine. Write a script.
  • dextercd 2y ago
    CAs and certificate consumers (browsers) voted in favour of this change. They didn't do this because they're incompetent but because they think it'll improve security. It's really not that hard to automate renewals and monitor a system's certificate status from a different system, just in case the automation breaks and for things that require manual renewal steps. I get that it's harder in large organisations and that not everything can be automated yet, but you still have a year before the certificate lifetime goes down to 200 days, which IMO is pretty conservative. With a known timeline like this, customers/employees have ammunition to push their vendors/employers to invest into automation and monitoring.
    • xyzzy123 2y ago
      Can you point to a specific security problem this change is actually solving? For example, can we attribute any major security compromises in the last 5 years to TLS certificate lifetime? Are the security benefits really worth making anything with a valid TLS certificate stop working if it is air-gapped or offline for 48 days? > CAs and certificate consumers (browsers) voted in favour of this change. They didn't do this because they're incompetent but because they think it'll improve security. They're not incompetent and they're not "evil", and this change does improve some things. But the companies behind the top level CA ecosystem have their own interests which might not always align with those of end users.
      • sidewndr46 2y ago
        According to the article: "The goal is to minimize risks from outdated certificate data, deprecated cryptographic algorithms, and prolonged exposure to compromised credentials. It also encourages companies and developers to utilize automation to renew and rotate TLS certificates, making it less likely that sites will be running on expired certificates." I'm not even sure what "outdated certificate data" could be. The browser by default won't negotiate a connection with an expired certificate
        • xyzzy123 2y ago
          > I'm not even sure what "outdated certificate data" could be... Agree. > According to the article: Thanks, I did read that, it's not quite what I meant though. Suppose a security engineer at your company proposes that users should change their passwords every 49 days to "minimise prolonged exposure from compromised credentials" and encourage the uptake of password managers and passkeys. How to respond to that? It seems a noble endeavour. To prioritise, you would want to know (at least): a) What are the benefits - not mom & apple pie and the virtues of purity but as brass tacks - e.g: how many account compromises do you believe would be prevented by this change and what is the annual cost of those? How is that trending? b) What are the cons? What's going to be the impact of this change on our customers? How will this affect our support costs? User retention? I think I would have a harder time trying to justify the cert lifetime proposal than the "ridiculously frequent password changes" proposal. Sure, it's more hygenic but I can't easily point to any major compromises in the past 5 years that would have been prevented by shorter certificate lifetimes. Whereas I could at least handwave in the direction of users who got "password stuffed" to justify ridiculously frequent password changes. The analogy breaks down in a bad way when it comes to evaluating the cons. The groups proposing to decrease cert lifetimes bear nearly none of the costs of the proposal, for them it is externalised. They also have little to no interest in use cases that don't involve "big cloud" because those don't make them any money.
  • arp242 2y ago
    You can disagree with all of this, but calling for everyone involved to be fired is just ridiculous and mean-spirited.
    • rglover 2y ago
      Is it? This is the crux of the problem with a lot of institutions. There's little to no professional accountability for bad moves anymore. It used to be that doing a good job and taking pride in one's work was all you needed to do to keep your job. Now? It's a spaghetti of politics and emotional warfare. Grown adults who can't handle being told that they might not be up to the task and it's time to part ways. If that's the honest truth, it's not "mean," just not what that person would like to hear.
• jonathantf2 2y ago
  A welcome change if it gives some vendors a kick up the behind to implement ACME.
  • ShakataGaNai 2y ago
    There is no more choice. No one is going to buy from (example) GoDaddy if they have to login every 30 days to manually get a new certificate. Not when they can go to (example) digicert and it's all automatic. It goes from a "rather nice to have" to "effectively mandatory".
    • jonathantf2 2y ago
      I think GoDaddy supports ACME - but if you're using ACME you might as well use Let's Encrypt and stop paying for it.
      • schlauerfox 2y ago
        Depends on the kind of certificate you need.
• jsheard 2y ago
  This change will have a steady roll-out, but if you want to get ahead of the curve then Let's Encrypt will be offering 6 day certs as an option soon. https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued/ https://letsencrypt.org/2025/02/20/first-short-lived-cert-is...
• _bin_ 2y ago
  Is there an actual issue with widespread cert theft? That seems like the primary valid reason to do this, not forcing automation.
  • trothamel 2y ago
    I suspect it's to limit how long a malicious or compromised CA can impact security.
    • rat9988 2y ago
      I think op is asking has there been many real case scenarios in practice that pushed for this change?
    • hedora 2y ago
      Equivalently, it also maximizes the number of sites impacted when a CA is compromised. It also lowers the amount of time it’d take for a top-down change to compromise all outstanding certificates. (Which would seen paranoid if this wasn’t 2025.)
      • lokar 2y ago
        Mostly this. Today of a big CA is caught breaking the rules, actually enforcing repairs (eg prompt revocation ) is a hard pill to swallow.
  • chromanoid 2y ago
    I guess the main reason behind this move is platform capitalism. It's an easy way to cut off grassroots internet.
    • gjsman-1000 2y ago
      If that were true, we would not have Let's Encrypt and tools which can give us certificates in 30 seconds flat once we prove ownership. The real reason was Snowden. The jump in HTTPS adoption after the Snowden leaks was a virtual explosion; and set HTTPS as the standard for all new services. From there, it was just the rollout. (https://www.eff.org/deeplinks/2023/05/10-years-after-snowden-some-things-are-better-some-were-still-fighting https://www.eff.org/deeplinks/2023/05/10-years-after-snowden...) (Edit because I'm posting too fast, for the reply): > How do you enjoy being dependent on a 3rd party (even a well intentioned one) for being on the internet? Everyone is reliant on a 3rd party for the internet. It's called your ISP. They also take complaints and will shut you down if they don't like what you're doing. If you are using an online VPS, you have a second 3rd party, which also takes complaints, can see everything you do, and will also shut you down if they don't like what you're doing; and they have to, because they have an ISP to keep happy themselves. Networks integrating with 3rd party networks is literally the definition of the internet.
• trothamel 2y ago
  Question: Does anyone have a good solution for renewing letsencrypt certificates for websites hosted on multiple servers? Right now, I have one master server that the others forward the well-known requests too, and then I copy the certificate over when I'm done, but I'm wondering if there's a better way.
  • pornel 2y ago
    I copy the same certbot account settings and private key to all servers and they obtain the certs themselves. It is a bit funny that LetsEncrypt has non-expiring private keys for their accounts.
  • nullwarp 2y ago
    I use DNS verification for this then the server doesn't even need to be exposed to the internet.
    • magicalhippo 2y ago
      And if changing the DNS entry is problematic, for example the DNS provider used doesn't have an API, you can redirect the challenge to another (sub)domain which can be hosted by a provider that has an API. I've done this and it works very well. I had a Digital Ocean droplet so used their DNS service for the challenge domain. https://letsencrypt.org/docs/challenge-types/#dns-01-challenge https://letsencrypt.org/docs/challenge-types/#dns-01-challen...
    • samgranieri 2y ago
      I use dns01 in my homelab with step-ca. works like a charm, and it's my private certificate authority
  • deleted 2y ago
    [deleted]
  • navigate8310 2y ago
    Have you tried certbot? Or if you want a turnkey solution, you may try Caddy or Traefik that have their own automated certificate generation utility.
• 1970-01-01 2y ago
  Your 90-day snapshot backups will soon become 47-day backups. Take care!
  • belter 2y ago
    This is going to be one of the obvious traps.
    • DiggyJohnson 2y ago
      To care about stale certs on snapshots or the opposite?
      • belter 2y ago
        Both. One breaks your restore, the other breaks your trust chain.
  • gruez 2y ago
    ??? Do people really backup their https certificates? Can't you generate a new one after restoring from backup?
• iJohnDoe 2y ago
  Getting a bit ridiculous.
  • bayindirh 2y ago
    Why?
    • nottorp 2y ago
      The logical endgame is 30 second certificates...
      • bayindirh 2y ago
        For extremely sensitive systems, I think a more logical endgame is 30 minutes or so. 30 seconds is practically continuous generation. An semi-distributed (intercity) Kubernetes cluster can reasonably change its certificate chain every week, but it needs an HSM if it's done internally. Otherwise, for a website, once or twice a year makes sense if you don't store anything snatch-worthy.
        • panki27 2y ago
          That CRL is going to be HUGE.
          • psz 2y ago
            Why you think so? Keep in mind that revoked certs are not included in CRLs once expired (because they are not valid any more).
        • nottorp 2y ago
          > once or twice a year makes sense You don't say. Why are the defaults already 90 days or less then?
          • bayindirh 2y ago
• ghusto 2y ago
  I really wish encryption and identity weren't so tightly coupled in certificates. If I've issued a certificate, I _always_ care about encryption, but sometimes do not care about identity. For those times when I only care about encryption, I'm forced to take on the extra burden that caring about identity brings. Pet peeve.
  • panki27 2y ago
    Isn't this excatly the reason why LetsEncrypt was brought to life?
  • charcircuit 2y ago
    Having them always coupled disincentivizes bad ISP's from MITM the connection.
  • deleted 2y ago
    [deleted]
  • tptacek 2y ago
    There's minimal security in an unauthenticated encrypted connection, because an attacker can just MITM it.
    • jchw 2y ago
      I mean, we do TOFU for SSH server keys* and nobody really seems to bat an eye at that. Today if you want "insecure but encrypted" on the web the main way to go is self-signed which is both more annoying and less secure than TOFU for the same kind of use case. Admittedly, this is a little less concerning of an issue thanks to ACME providers. (But still annoying, especially for local development and intranet.) *I mistakenly wrote "certificate" here initially. Sorry.
      • pabs3 2y ago
        You don't have to TOFU SSH server keys, there is a DNSSEC option, or you can transfer the keys via a secure path, or you can sign the keys with a CA.
• pixl97 2y ago
  Heh, working with a number of large companies I've seen most of them moving to internally signed certs on everything because of ever shortening expiration times. They'll have public certs on edge devices/load balancers but internal services with have internal CA signed certs with long expire times because of the number of crappy apps that make using certs a pain in the ass.
  • xienze 2y ago
    > but internal services with have internal CA signed certs with long expire times because of the number of crappy apps that make using certs a pain in the ass. Introduce them to the idea of having something like Caddy sit in front of apps solely for the purpose of doing TLS termination... Caddy et al can update the certs automatically.
    • pixl97 2y ago
      Unless they are web/tech companies they aren't doing that. Banks, finance, large manufacturing are all terminating at F5's and AVI's. I'm pretty sure those update certs just fine, but it's not really what I do these days so I don't have a direct answer.
      • xienze 2y ago
        Sure. The point is, don't bother letting the apps themselves do TLS termination. Too much work that's better handled by something else.
        • hedora 2y ago
          Also, moving termination off the endpoint server makes it much easier for three letter agencies to intercept + log.
          • qmarchi 2y ago
            Most responsible orgs do TLS termination on the public side of a connection, but will still make a backend connection protected by TLS, just with a internal CA.
• junaru 2y ago
  > For this reason, and because even the 2027 changes to 100-day certificates will make manual procedures untenable, we expect rapid adoption of automation long before the 2029 changes. Oh yes, vendors will update their legacy NAS/IPMI/whatever to include certbot. This change will have the exact opposite effect - expired self signed certificates everywhere on the most critical infrastructure.
  • panki27 2y ago
    People will just roll out almost forever-lasting certificates through their internal CA for all systems that are not publicly reachable.
    • throw0101d 2y ago
      > through their internal CA Nope. People will create self-signed certs and tell people to just click "accept".
      • Avamander 2y ago
        They're doing it right now and they'll continue doing so. There are always scapegoats for not automating.
  • xnyanta 2y ago
    I have automated IPMI certificate rotation set-up through Let's Encrypt and ACME via the Redfish API. And this is on 15 year old gear running HP iLO4. There's no excuse for not automating things.
• captn3m0 2y ago
  This is great news. This would blow a hole in two interesting places where leaf-level certificate pinning is relied upon: 1. mobile apps. 2. enterprise APIs. I dealt with lots of companies that would pin the certs without informing us, and then complain when we'd rotate the cert. A 47-day window would force them to rotate their pins automatically, making it even worse of a security theater. Or hopefully, they switch rightly to CAA.
  • grishka 2y ago
    Isn't it usually the server's public key that's pinned? The key pair isn't regenerated when you renew the certificate.
    • toast0 2y ago
      Typical guidance is to pin the CA or intermediate, because in case of a key compromise, you're going to need to generate a new key. You should really generate a new key for each certificate, in case the old key is compromised and you don't know about it. What would really be nice, but is unlikely to happen would be if you could get a constrained CA certificate issued for your domain and pin that, then issue your own short term certificates from there. But if those are wide spread, they'd need to be short dated too, so you'd need to either pin the real CA or the public key and we're back to where we were.
      • nickf 2y ago
        I've said it up-thread, but never ever never never pin to anything public. Don't do it. It's bad. You, and even the CA have no control over the certificates and cannot rely on them remaining in any way constant. Don't do it. If you must pin, pin to private CAs you control. Otherwise, don't do it. Seriously. Don't.
        • einsteinx2 2y ago
          Repeating it doesn’t make it any more true. Cert providers publish their root certs, you pin those root certs, zero problems.
• belter 2y ago
  Are the 47 days to please the current US Administration?
  • eesmith 2y ago
    Based on the linked-to page, no: 47 days might seem like an arbitrary number, but it’s a simple cascade: * 200 days = 6 maximal month (184 days) + 1/2 30-day month (15 days) + 1 day wiggle room * 100 days = 3 maximal month (92 days) + ~1/4 30-day month (7 days) + 1 day wiggle room * 47 days = 1 maximal month (31 days) + 1/2 30-day month (15 days) + 1 day wiggle room
• aaomidi 2y ago
  Good. If you can't make this happen, don't use WebPKI and use internal PKI.
• throw0101b 2y ago
  Justification: > The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information. > The ballot also argues that the revocation system using CRLs and OCSP is unreliable. Indeed, browsers often ignore these features. The ballot has a long section on the failings of the certificate revocation system. Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA/B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support. Personally I don't really buy this argument. I don't think the web sites that most people visit (especially highly-sensitive ones like for e-mail, financial stuff, a good portion of shopping) change or become "less trustworthy" that quickly.
  • gruez 2y ago
    The "less trustworthy" refers to key compromise, not the e-shop going rogue and start scamming customers or whatever.
    • throw0101a 2y ago
      Okay, the key is compromised: that means they can MITM the trust relationship. But with modern algorithms you have forward security, so even if you've sniffed/captured the traffic it doesn't help. And I would argue that MITMing communications is a lot hard for (non-nation state) attackers than compromising a host, so trust compromise is a questionable worry.
      • gruez 2y ago
        >And I would argue that MITMing communications is a lot hard for (non-nation state) attackers than compromising a host, so trust compromise is a questionable worry. By that logic, we don't really need certificates, just TOFU.
        • throw0101d 2y ago
• greatgib 2y ago
  As I said in another thread, basically that will kill any possibility to do your own CA for your own subdomain. Only the big one embedded in browser will have the receive to have their own CA certificate with whatever period they want... And in term of security, I think that it is a double edged sword: - everyone will be so used to certificates changing all the time, and no certificate pinning anymore, so the day were China, a company or whoever serve you a fake certificate, you will be less able to notice it - Instead of having closed systems, readonly, having to connect outside and update only once per year or more to update the certificates, you will have now all machines around the world that will have to allow quasi permanent connections to random certificate servers for the updating the system all the time. If ever Digicert or Letsencrypt server, or the "cert updating client" is rooted or has a security issue, most servers around the world could be compromised in a very very short time. As a side note, I'm totally laughing at the following explanation in the article: 47 days might seem like an arbitrary number, but it’s a simple cascade: - 47 days = 1 maximal month (31 days) + 1/2 30-day month (15 days) + 1 day wiggle room So, 47 is not arbitrary, but 1 month, + 1/2 month, + 1 day are not arbitrary values...
  • gruez 2y ago
    >As I said in another thread, basically that will kill any possibility to do your own CA for your own subdomain. like, private CA? All of these restrictions are only applied for certificates issued under the webtrust program. Your private CA can still issue 100 year certificates.
    • greatgib 2y ago
      Let's suppose that I'm a competitor of Google and Amazon, and I want to have my Public root CA for mydomain.com to offer my clients subdomains like s3.customer1.mydomain.com, s3.customer2.mydomain.com,...
      • gruez 2y ago
        Why do you want this when there are wildcard certificates? That's how the hyperscalers do it as well. Amazon doesn't have a separate certificate for each s3 bucket, it's all under a wildcard certificate.
• raggi 2y ago
  It sure would be nice if we could actually fix dns.
• throwaway96751 2y ago
  Off-topic: What is a good learning resource about TLS? I've read the basics on Cloudflare's blog and MDN. But at my job, I encountered a need to upload a Let's encrypt public cert to the client's trusted store. Then I had to choose between Let's encrypt's root and intermediate certs, between key types RSA and ECDSA. I made it work, but it would be good to have an idea of what I'm doing. For example why root RSA key worked even though my server uses ECDSA cert. Before I added the root cert to a trusted store, clients used to add fullchain.pem from the server and it worked too — why?
  • dextercd 2y ago
    I learned a lot from TLS Mastery by Michael W. Lucas.
    • throwaway96751 2y ago
      Thanks, looks exactly like what I wanted
  • physicles 2y ago
    Use ECDSA if you can, since it reduces the size of the handshake on the wire (keys are smaller). Don’t bake in intermediate certs unless you have a very good reason. No idea why the RSA key worked even though the server used RSA — maybe check into the recent cross-signing shenanigans that Let’s Encrypt had to pull to extend support for very old Android versions.
    • deleted 2y ago
      [deleted]
    • throwaway96751 2y ago
      I've been reading a little since then, and I think it worked with RSA root cert because this cert was a trust anchor of the Chain of Trust of my server's ECDSA certificate.
  • bbkane 2y ago
    I wrote a list of resources that helped me at https://www.bbkane.com/blog/learn-ssl/ https://www.bbkane.com/blog/learn-ssl/
• zelon88 2y ago
  This naively (or maliciously perhaps) maintains that the "purpose" of the certificate is to identify an entity. While identity and safeguarding against MITM is important, identity is not the primary purpose certificates serve in the real world. At least that is not how they are used or why they are purchased. They are purchased to provide encryption. Nobody checks the details of a cert and even if they did they wouldn't know what to look for in a counterfeit anyway. This is just another gatekeeping measure to make standing up, administering, and operating private infrastructure difficult. "Just use Google / AWS / Azure instead."
  • chowells 2y ago
    I think it's absolutely critical when I'm sending a password to a site that it's actually the site it claims to be. That's identity. It matters a lot.
    • zelon88 2y ago
      Not to users. The user who types Wal-Mart into their address bar expects to communicate with Wal-Mart. They aren't going to check if the certificate matches. Only that the icon is green. This is where the disconnect comes in. Me and you know that the green icon doesn't prove identity. It proves certificate validity. But that's not what this is "sold as" by the browser or the security community as a whole. I can buy the domain Wаl-Mart right now and put a certificate on it that says Wаl-Mаrt and create the conditions for that little green icon to appear. Notice that I used U+0430 instead of the letter "a" that you're used to. And guess what... The identity would match and pass every single test you throw at it. I would get a little green icon in the browser and my certificate would be good. This attack fools even the brightest security professionals. So you see, Identity isn't the value that people expect from a certificate. It's the encryption. Users will allow a fake cert with a green checkmark all day. But a valid certificate with a yellow warning is going to make people stop and think.
      • chowells 2y ago
        Well, no. That's just not true. I care that when I type walmart.com, I'm actually talking to walmart.com. I don't look at the browser bar or symbols on it. I care what my bookmarks do, what URLs I grab from history do, what my open tabs do, and what happens when I type things in. Preventing local DNS servers from fucking with users is critical, as local DNS is the weakest link in a typical setup. They're often run by parties that must be treated as hostile - basically whenever you're on public wifi. Or hell, when I'm I'm using my own ISP's default configuration. I don't trust Comcast to not MitM my connection, given the opportunity. I trust technical controls to make their desire to do so irrelevant. Without the identity component, any DNS server provided by DHCP could be setting up a MitM attack against absolutely everything. With the identity component, they're restricted to DoS. That's a lot easier to detect, and gets a lot of very loud complaints.
• readthenotes1 2y ago
  I wonder how many forums run by the barely able are going to disappear or start charging. I fairly regularly get cert expired problems because the admin is doing it as the yak shaving for a secondary hobby
  • ezfe 2y ago
    Why would they start charging? Auto-renewing certificates with Let's Encrypt are easy to do.
    • dijit 2y ago
      as long as you only have a single server, or a DNS server that has an API. Even certbot got deprecated, so my IRC network has to use some janky shell scripts to rotate TLS… I’m considering going back to traditional certs because I geo-balance the DNS which doesn’t work for letsencrypt. The issue is actually that I have multiple domains handled multiple ways and they all need to be letsencrypt capable for it to work and generate a combined cert with SAN’s attached.
• zephius 2y ago
  Old SysAdmin and InfoSec Admin perspective: Dev guys think everything is solvable via code, but hardware guys know this isn't true. Hardware is stuck in fixed lifecycles and firmware is not updated by the vendors unless it has to be. And in many cases updated poorly. No hardware I've ever come across that supports SSL\TLS (and most do nowadays) offers any automation capability in updating certs. In most cases, certs are manually - and painfully - updated with esoteric CLI cantrips that require dancing while chanting to some ancient I.T. God for mercy because the process is poorly (if at all) documented and often broken. No API call or middelware is going to solve that problem unless the manufacturer puts it in. In particular, load balancers are some of the worst at cert management, and remember that not everyone uses F5 - there are tons of other cheaper and popular alternatives most of which are atrocious at security configuration management. It's already painful enough to manage certs in an enterprise and this 47 day lifecycle is going to break things. Hardware vendors are simply incompetent and slow to adapt to security changes. And not everyone is 100% in the cloud - most enterprises are only partially in that pool.
  • tptacek 2y ago
    I think everybody involved knows about the likelihood that things are going to break at enterprise shops with super-expensive commercial middleboxes. They just don't care anymore. We ran a PKI that cared deeply about the concerns of admins for a decade and a half, and it was a fiasco. The coders have taken over, and things are better.
    • zephius 2y ago
      That's great for shops with Dev teams and in house developed platforms. Those shops are rare outside Silicon Valley and fortune 500s and not likely to increase beyond that. For the rest of us, we are at the mercy of off the shelf products and 3rd party platforms.
      • tptacek 2y ago
        I suggest you buy products from vendors who care about the modern WebPKI. I don't think the browser root programs are going to back down on this stuff.
• nickf 2y ago
  Don't forget the lede buried here - you'll need to re-validate control over your DNS names more frequently too. Many enterprises are used to doing this once-per-year today, but by the time 47-day certs roll around, you'll be re-validating all of your domain control every 10 days (more likely every week).
• CommanderData 2y ago
  Why bother with such a long staggered approach? There should be 1 change from 365 to 47 days. This industry doesnt need constant changes, which will force everyone to automating renewals anyway.
  • datadrivenangel 2y ago
    Enterprises are like lobsters: You gotta crank the water temperature up slowly.
• xyst 2y ago
  I don’t see any issue here. I already automate with ACME so rotating certificates on an earlier basis is okay. This should be like breathing for app and service developers and infrastructure teams. Side note: I wonder how much pressure this puts on providers such as LetsEncrypt, especially with the move to validate IPs. And more specifically IPv6…
  • ShakataGaNai 2y ago
    Because there are lots of companies, large and small, which haven't gotten that far. Lots of legacy sites/services/applications. I don't disagree with you that it should be super common. But it's surprisingly not in many businesses. Heck, Okta (nominally a large security company) still sends out notifications every time they change certificates and publishes a copy of their current correct certs in github: https://github.com/okta/okta-pki https://github.com/okta/okta-pki - How they do the actual rotation? No idea, but... I'd guess it's not automatic with that level of manual notification/involvement. (Happy to be proven wrong though).
• vasilzhigilei 2y ago
  I'm on the SSL/TLS team @ Cloudflare. We have great managed certificate products that folks should consider using as certificate validity periods continue to shorten.
  • bambax 2y ago
    Simply having a domain managed by Cloudflare makes it magically https; yes, the traffic between the origin server and Cloudflare isn't encrypted, so it's not completely "secure", but for most uses it's good enough. It's also zero-maintenance and free. Keep up the good work! ;-)
    • vasilzhigilei 2y ago
      Thanks! You can also set up free origin certs to make Cloudflare edge to origin connections encrypted as well.
  • Lammy 2y ago
    SSL added and removed here ;-)
  • lucb1e 2y ago
    Is this a joke (as in, that you don't actually work there) to make CF look bad for posting product advertisements in comment threads, or is this legit?
    • vasilzhigilei 2y ago
      It's one of my first times posting on HN, thought this could be relevant helpful info for someone. Thanks for pointing out that it sounds salesy, rereading my comment I see it too now.
    • bambax 2y ago
      People who are proud of the work they do are rare enough that we shouldn't punish them for it.
  • tinix 2y ago
• Lammy 2y ago
  This sucks. I'm actually so sick of mandatory TLS. All we did was get Google Analytics and all the other spyware running “““securely””” while making it that much harder for any regular person to host anything online. This will push people even further into the arms of the walled gardens as they decide they don't want to deal with the churn and give up.
  • ShakataGaNai 2y ago
    First.... 99% of people have zero interest in hosting things themselves anyways. Like on their own server themselves. Geocities era was possibly the first and last time that "having your own page" was cool, and that was basically killed by social media. As for certs... maybe at the start it was hard, but it's really quite easy to host things online, with a valid certificate. There are many CDN services like Cloudflare which will handle it for you. There are also application proxies like Traefik and Caddy which will get certs for you. Most people who want their own site today, will use Kinsta or SquareSpace or GitHub pages any one of thousands of page/site hosting services. All of whom have a system for certificates that is so easy to use, most people don't even realize it is happening.
    • Lammy 2y ago
      lol at recommending Cloudflare and Microsoft (Github) in response to a comment decrying spyware Every single thing you mentioned is plugged in to the tier-1 surveillance brokers. I am talking plain files on single server shoved in a closet, or cheap VPS. I don't often say this but I really don't think you “get” it.
      • jonathantf2 2y ago
        A "regular person" won't/can't deal with a server, VPS, anything like that. They'll go to GoDaddy because they saw an advert on the TV for "websites".
        • Lammy 2y ago
          They absolutely can deal with the one-time setup of one single thing that's easy to set up auto-pay for. It's so many additional concepts when you add in the ACME challenge/response because now you have to learn sysadmin-type skills to care for a periodic process, users/groups for who-runs-what-process and who-owns-what-cert-files, software updates to chase LE/ACME changes or else all your stuff breaks, etc. Your attitude is so dismissive to the general public. We should be encouraging people to learn the little bits they want to learn to achieve something small, and instead we are building this ivory tower all-or-nothing stack. For what, job security? Bad mindset.
• peanut-walrus 2y ago
  So the assumption here is that somehow your private key is easier to compromise than whatever secret/mechanism you use to provision certs? Yeah not sure about that one...
• riffic 2y ago
  ah this is gonna piss off a few coworkers today but it's a good move either way.
• bob1029 2y ago
  What's the end game here? I agree with the dissent. Why not make it 30 seconds? Once we cross the threshold of "I absolutely have to automate everything or it's not viable to use TLS anymore", why do we care about providing anything beyond ~48 hours? I am willing to bet money this threshold will never be crossed. This feels like much more of an ideological mission than a practical one, unless I've missed some monetary/power advantage to forcing everyone to play musical chairs with their entire infra once a month...
  • woodruffw 2y ago
    The "end game" is mentioned explicitly in the article: > Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA/B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support. Shorter-lived certificates make OCSP and other revocation mechanisms less of a load-bearing component within the Web PKI. This is a good thing, since neither CAs nor browsers have managed to make timely revocation methods scale well. (I don't think there's any monetary or power advantage to doing this. The reason to do it is because shorter lifetimes make it harder for server operators to normalize deviant certificate operation practices. The reasoning there is the same as with backups or any other period operational task: critical processes must be continually tested and evaluated for correctness.)
    • sitkack 2y ago
      Don't lower cert times also get people to trust certs that were created just for their session to MITM them? That is the next step in nation state tapping of the internet.
      • ezfe 2y ago
        lol no? lower cert times still extend the root certificates that are already trusted. It is not a noticeable thing when browsing the web as a user. A MITM cert would need to be manually trusted, which is a completely different thing.
• bityard 2y ago
  I see that there is a timeline for progressive shortening, so if anyone has any "inside baseball" on this, I'm very curious to know: Given that the overarching rationale here is security, what made them stop at 47 days? If the concern is _actually_ security, allowing a compromised cert to exist for a month and a half is I guess better than 398 days, but why is 47 days "enough"? When will we see proposals for max cert lifetimes of 1 week? Or 1 day? Or 1 hour? What is the lower limit of the actual lifespan of a cert and why aren't we at that already? What will it take to get there? Why are we investing time and money in hatching schemes to continually ratchet the lifespan of certs back one more step instead of addressing the root problems, whatever those are?
  • dadrian 2y ago
    The root problem is certificate lifetimes are too long relative to the speed at which domains change, and the speed at which the PKI needs to change.
• rhodey 2y ago
  After EFF Lets Encrypt made the change to disable reminder emails I decided I would be moving my personal blog from my VPS to AWS specifically. I just today made the time to make the move and 10 minutes after I find this. I could have probably done more with Lets Encrypt automation to stay with my old VPS but given that all my professional work is with AWS its really less mental work to drop my old VPS. Times they are a changing
  • mystified5016 2y ago
    Why not just automate your LetsEncrypt keys like literally everyone else does? It's free and you have to go out of your way to do it manually. Or just pay Amazon, I guess. Easier than thinking.
• ori_b 2y ago
  Can someone point me to specific exploits that this key rotation schedule would have stopped? It seems to me like compromised keys are rare. It also seems like 47 days is low enough to be inconvenient, but not low enough to prevent significant numbers of people from being compromised if there is a compromised key.
  • Avamander 2y ago
    > Can someone point me to specific exploits that this key rotation schedule would have stopped? It's not only key mismanagement that is being mitigated. You also have to prove more frequently that you have control of the domain or IP in the certificate. In essence it brings a working method of revocation to WebPKI. > but not low enough to prevent significant numbers of people from being compromised if there is a compromised key. Compared to a year?
    • ori_b 2y ago
      > You also have to prove more frequently that you have control of the domain or IP in the certificate. That doesn't particularly matter; if someone takes over the domain but doesn't have a leaked key, they can't sign requests for the domain with my cert. It takes a leaked key for this to turn into a vulnerability. On the other hand, anyone that owns the domain can get a perfectly valid cert any time, no need to exploit anything. And given that nobody actually looks at the details of the cert owner in practice, that means that if you lose the domain, the new owner is, treated as legit. No compromises needed. The only way to prevent that is to pin the cert, which this short rotation schedule makes harder, or pin the public key and be very careful to not regenerate your keys when you submit a new CSR. In short: Don't lose your domain. > Compared to a year? Typically these kinds of things have an exponential dropoff, so most of the exploited folks would be soon after the compromise. I don't think that shortening to this long a period, rather than (say) 24h would make a material difference. But, again, I'm also not sure how many people were compromised via anything that this kind of rotation would prevent. It seems like most exploits depend on someone either losing control over the domain (again, don't do that; the current issuance model doesn't handle that), or just being phished via a valid cert on an unrelated domain. Do you have concrete examples of anyone being exploited via key mismanagement (or not proving often enough that they have control over a domain)?
• procaryote 2y ago
  If this is causing you pain, certbot with Acme DNS challenge is pretty easy to set up to get you certs for your internal services. There are tools for many different dns providers like route53 or cloudflare. I tend to have secondary scripts that checks if the cert in certbots dir is newer than whatever is installed for a service, and if so install it. Some services prefer the cert in certain formats, some services want to be reloaded to pick up a new cert etc, so I put that glue in my own script and run it from cron or a systemd timer.
  • merb 2y ago
    The problem is more or less devices that do not support dns challenges or only support letsencrypt and not the acme protocol (to chain acme servers, etc)
    • cpach 2y ago
      What kind of devices are you thinking of? Like switches and other network gear?
      • JackSlateur 2y ago
        I've deployed LE on IPMI (dell, supermicro), so that's not a good excuse ! As long as you have a way to "script" something on your devices (via ssh, API or whatever) .. you are good to go
        • merb 1y ago
          If you need to script things it will be a pain for a lot of people.
      • merb 2y ago
        FortiGate 50g (higher version than 7.0 probably fixes that, but no idea when that will be released), some synology nas and there are tons of other boxes like that.
  • AtNightWeCode 2y ago
• msie 2y ago
  Eff this shit. I'm getting out of sysadmin.
• deleted 2y ago
  [deleted]
• 0xbadcafebee 2y ago
  I hate this, but I'm also glad it's happening, because it will speed up the demise of Web PKI. CAs and web PKI are a bad joke. There's too many ways to compromise security, there's too many ways to break otherwise-valid web sites/apps/connections, there's too many organizations that can be tampered with, the whole process is too complex and bug-prone. What Web PKI actually does, in a nutshell, is prove cryptographically that at some point in the past, there was somebody who had control of either A) an e-mail address or B) a DNS record or C) some IP space or D) some other thing, and they generated a certificate through any of these methods with one of hundreds of organizations. OR it proves that they stole the keys of such a person. It doesn't prove that who you're communicating with right now is who they say they are. It only proves that it's someone who, at some point, got privileged access to something relating to a domain. That's not what we actually want. What we actually want is to be assured this remote host we're talking to now is genuine, and to keep our communication secret and safe. There are other ways to do that, that aren't as convoluted and vulnerable as the above. We don't have to twist ourselves into all these knots. I'm hopeful changes like these will result in a gradual catastrophy which will push industry to actually adopt simpler, saner, more secure solutions. I've proposed one years ago but nobody cares because I'm just some guy on the internet and not a company with a big name. Nothing will change until the people with all the money and power make it happen, and they don't give a shit.
• wnevets 2y ago
  Has anyone managed to calculate the increase power usage across the entire internet this change will cause? Well, I suppose the environment can take one more for the team.
  • margalabargala 2y ago
    The single use of AI to generate that video of Trump licking Elon Musk's feet, used significantly more power than this change will cause to be used over the next decade. It's great to be environmentally conscious, but if reducing carbon emissions is your goal, complaining about this is a lot like saying that people shouldn't run marathons, because physical activity causes humans to exhale more CO2.
    • wnevets 2y ago
      > The single use of AI to generate that video of Trump licking Elon Musk's feet, used significantly more power than this change will cause to be used over the next decade. We are effectively talking about the entire world wide web generating multiple highly secure cryptograph key pairs every 47 days. That is a lot of CPU cycles. Also you not picking up on the Futurama quote is disappointing.
      • margalabargala 2y ago
        > We are effectively talking about the entire world wide web generating multiple highly secure cryptograph key pairs every 47 days. That is a lot of CPU cycles. We aren't cracking highly secure key pairs. We're making them. On my computer, to create a new 4096-bit key takes about a second, in a single thread. For something I now have to do fewer than 8 times per year. On a 16-core CPU with a TDP of 65 watts, we can estimate that this took 0.0011 watt-hours. Yes, there are a lot of websites, close to a billion of them. No, this still is not some onerous use of electricity. For the whole world, this is an additional usage of a bit over 9000 kWh annually. Toss up a few solar panels and you've offset the whole planet.
        • 2y ago
• AlfeG 2y ago
  Will see how Azure FD will handle this. We opened more than expected tickets with support on certs not updating automatically...
• dsr_ 2y ago
  Daniel K Moran figured out the endgame: "Therefore, the Lunar Bureau of the United Nations Peace Keeping Force DataWatch has created the LINK, the Lunar Information Network Key. There are currently nine thousand, four hundred and two Boards on Luna; new Boards must be licensed before they can rent lasercable access. Every transaction--every single transaction--which takes place in the Lunar InfoNet is keyed and tracked on an item-by-item basis. The basis of this unprecedented degree of InfoNet security is the Lunar Information Network Key. The Key is an unbreakable encryption device which the DataWatch employs to validate and track every user in the Lunar InfoNet. Webdancers attempting unauthorized access, to logic, to data, to communications facilities, will be punished to the full extent of the law." from The Long Run (1989) Your browser won't access a site without TLS; this is for your own protection. TLS certificates are valid for one TCP session. All certs are issued by an organization reporting directly to a national information security office; if your website isn't in compliance with all mandates, you stop getting certs.
• aristofun 2y ago
  Oh no, Bunch of stupid bureacrats came up with another dumb idea. What a surprise!
• thyristan 2y ago
  semi-related question: where is the letsencrypt workalike for s/mime?
• avodonosov 2y ago
  First impression: with automation and short lived certificates, the Certifying Authorities become similar to Identity Providers / OpenID Provider in openid / openid-connect. The certificates are tokens. And significant part of security is concentrated around the way Certifying Authorities validate the domain ownership. (So called challenges). Next, maybe clients can run those challenges directly, instead of relying onto certificates? For example, when connecting a server, client client sends two unique values, and the server must create DNS record <unique-val-1>.server.com with record value of the <unique-val-2>. Client check that such record is created and thus the server has proven it controls the domain name. Auth through DNS, that's what it is. We will just need to speed up the DNS system.
  • fpoling 2y ago
    That does not work as DNS is insecure. DNSSEC is not there and may never will.
    • detaro 2y ago
      And would be replacing the CA PKI with an even more centralized PKI.
    • ryandv 2y ago
      But this is already basically how Let's Encrypt challenges certificate applicants over ACME DNS01 [0]. I would be more concerned about the number of certificates that would need to be issued and maintained over their lifecycle - which now scales with the number of unique clients challenging your server (or maybe I misunderstand, and maybe there aren't even certificates any more in this scheme). Not to mention the difficulties of assuring reasonable DNS response times and fresh, up-to-date results when querying a global eventually consistent database with multiple levels of caching... [0] https://letsencrypt.org/docs/challenge-types/#dns-01-challenge https://letsencrypt.org/docs/challenge-types/#dns-01-challen...
      • avodonosov 2y ago
        In the scheme I descrubed where client directly runs challenges the certificates are not issued at all. I am not saying this scheme is really practical currently. That's just an imaginary situation coming to mind, illustrating the increased importance of domain ownership validation procedures used by Certifying Authorities. Essentially the security now comes down to the domain ownership validation. Also a correction. The server not simply puts <unique-val-2>, it puts sha256(<unique-val-2> || '.' || <fingerprint of the public key of the account>). Yes, the ACME protocol uses some account keys. Private key signs a requests for new cert, and public key fingerprint during domain ownership validation confirms that the challenge response was intended for that specific account. I am not suggesting ACME can be trivially broken. I just realized that risks of TLS certs breaking is not just risk of public key crypto being broken, but also includes the risks of domain ownership validation protocols.
• philsnow 2y ago
  > As a certificate authority, one of the most common questions we hear from customers is whether they’ll be charged more to replace certificates more frequently. The answer is no. Cost is based on an annual subscription […] (emphasis added) Pump the brakes there, digicert. Price is based on an annual subscription. CA costs will actually go up an infinitesimal amount, but they’re already nearly zero to begin with. Running a CA has got to be one of the easiest rackets in the world.
  • jwnin 2y ago
    Costs to buy certs will not materially change. Costs to manage certs will increase.
• umvi 2y ago
  So does this mean all of our Chromecasts are going to stop working again once this takes effect since (judging by Google's response during the week long Chromecast outage earlier this year) Chromecast is run by a skeleton crew and won't have the resources to automate certificate renewal?
• Havoc 2y ago
  Continually surprised by how emotional people get about cert lifetimes. I get that there are some fringe cases where it’s not possible but for the rest - automate and forget.
  • lucb1e 2y ago
    If emotional reactions to a (likely intentional) annoyance factor surprises you, remember that people start wars for differing sets of beliefs! But there's also security implications: https://news.ycombinator.com/item?id=43708319 https://news.ycombinator.com/item?id=43708319
• compumike 2y ago
  (Shameless self-promotion) We set up our https://heiioncall.com/ https://heiioncall.com/ monitoring to give our on-call rotation a non-critical “it can wait until Monday” alert when there are 14 days or less left on our SSL certificates, and a critical alert “do-not-disturb be damned” when 48 hours left until expiry. Because cert-manager got into some weird state once a few years ago, and I’d rather find out well in advance next time. Edit: it’s configured under Trigger -> Outbound Probe -> “SSL Certificate Minimum Expiration Duration”
• deleted 2y ago
  [deleted]
• mystraline 2y ago
  I'm sure this will be buried, but SSL is supposed to provide encryption. That's it. Self-signed custom certs also does that. But those are demonized. Also SSL also tries to define a ip-dns certification of ownership, kind of. There's also a distinct difference between 'this cert expired last week' and 'this cert doesn't exist' and mitm attack. Expired? Just give a warning, not a scare screen. MITM? Sure give a big scary OHNOPE screen. But, yeah, 47 days is going to wreck havok on network and weird devices.
  • kbolino 2y ago
    If there was no IP/DNS ownership verification, how would you even know you had been MITMed? You think the attacker is going to set a flag to let you know the certificate is fake? The only real alternative to checking who signed a certificate is checking the certificate's fingerprint hash instead. With self-signed certificates, this is the only option. However, nobody does this. When presented with an unknown certificate, people will just blindly trust it. So self-signed certificates at scale are very susceptible to MITM. And again, you're not going to know it happened. Encryption without authentication prevents passive snooping but not active and/or targeted attacks. And the target may not be you, it may be the other side. You specifically might not be worth someone's time, but your bank and all of its other customers too, probably is. OCSP failed. CRLs are not always being checked. Shorter expiry largely makes up for the lack of proper revocation. But expiration must consequently be treated as no less severe than revocation.
    • mystraline 2y ago
      True, I get where you're coming from, but I think there's more problems even in those implied answers. Homoglyph attacks are a thing. And I can pay $10 for a homoglyph name. No issues. I can get a webserver on a VM and point DNS. From there I can get a Letsencrypt. Use Nginx to point towards real domain. Install a mailserver and send out spoofed mails. You can also even set up SPF/DKIM/DMARC and have a complete attested chain. And its all based on a fake DNS, using nothing more than things like a Cyrillic 'o'. And, the self-signed issue is also what we see with SSH. And it mostly just works too.
• curtisszmania 2y ago
  [dead]
• webprofusion 2y ago
  Pretty sure this only refers to publicly trusted certs. What percentage of public certs are still being manually managed? I've been in the cert automation industry for 8 years (https://certifytheweb.com https://certifytheweb.com) and I do still hear of manual work going on, but the majority of stuff can be automated. For stuff that genuinely cannot be automated (are you sure you're sure) these become monthly maintenance tasks, something cert management tools are also now starting to help with. We're planning to add tracking tasks for manual deployments to Certify Management Hub shortly (https://docs.certifytheweb.com/docs/hub/ https://docs.certifytheweb.com/docs/hub/), for those few remaining items that need manual intervention.
• iqandjoke 2y ago
  The poor vendor folk needs to come more often on site to fix the cert issue.
• paradite 2y ago
  All I care about as a certbot user is what do I need to do. Do I need to update certbot in all my servers? Or would they continue to work without the need to update?
• elric 2y ago
  This sounds an awful lot like security theatre. > The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information. This is patently nonsensical. There is hardly any information in a certificate that matters in practice, except for the subject, the issuer, and the expiration date. > Shorter lifetimes mitigate the effects of using potentially revoked certificates. Sure, and if you're worried about your certificates being stolen and not being correctly revoked, then by all means, use a shorter lifetime. But forcing shorter lifetimes on everyone won't end up being beneficial, and IMO will create a lot of pointless busywork at greater expense. Many issuers still don't support ACME.
• borgster 2y ago
  The ultimate internet "kill switch": revoke all certificates. Modern browsers refuse to render the page.
• arisudesu 2y ago
  Having short-lived certificates is good, replacing them too often is not. This is implemented trivially for single-host deployments which just run certbot or ACME each subdomains. But for sophisticated setups where a certificate for a domain (or multiple domains or a wildcard) must be shared across fleet of hosts, it is a burden. There are no ready-made tools available to automate such deployments. Especially if a certificate must be the same for each of the hosts, fingerprint included. Having a single, authoritative certificate for a domain and its wildcard subdomains deployed everywhere is much simpler to monitor. It does not expose internal subdomains in certificate transparency logs. Unfortunately, organizations (persons) involved in decisions, do not provide such tools in advance.
  • lo0dot0 2y ago
    I agree. There should be a process in place for checking if changes are ready to be rolled out, and one of the checks should be a working prototype implementation, that is open source, that shows that running your systems can still be managed.
• kevincox 2y ago
  To me I don't really care about the certificate lifetime, what I care about is the time between being allowed to renew and time until expiry. Right now Let's Encrypt recommends renewing your 90d certificates every 60 days, which means that there is a 30 day window between recommended to renew and expiry. This feels relatively comfortable to me. A long vacation may be longer than 30 days but it is rare and there is probably other maintenance that you should be doing in this time (although likely routine like security updates rather than exceptional like figuring out why your certificate isn't renewing). So if 47 days ends up meaning renew every 17 days and still have that 30 day buffer I would be quite happy. But what I fear is that they will recommend (and set rate limits based on) renewing every 30 days with a 17 day buffer which is getting a little short for comfort IMHO. While big organizations will have a 24h oncall and medium organizations will have many business hours to figure it out is sucks for individuals who what to go away for a few weeks without worrying about debugging their certificate renewal until they get home.
• rfmoz 2y ago
  This could be addressed in a more progressive way. For example, EV carts had the green bar that was a soft way to promote their presence/use over the normal ones. That bar, started as a strong evidence on the url box and lost that look with the time. Something like that let the owner to decide and, maybe, the user push their use because it feels more secure, not directly the CA.
• jezek2 2y ago
  Thanks for the heads up. I will adjust my cron jobs to run every week instead of every month. I need it more frequently to get more time in case there is an error as I tend to ignore the error e-mails for multiple weeks due to my fatigue from handling of various kinds of certificates. Personally I also have an HTTP mirror for my more important projects when availability is more important than security of the connection.
• PixelPaul 2y ago
  Petition to Remove members voting rights from the CABForum who have a commercial interest: https://chng.it/WcR6t2WQd2 https://chng.it/WcR6t2WQd2
• hackcoughgasp 1y ago
  I know this thread is over, but it's important to understand that it's the browsers who have all the power in CABF and they were the drivers behind this change. Apple proposed it and Google voted yes within minutes of the voting period opening. It was unanimous among CAs too (with 5 abstentions), and nobody really disagrees with it, but it was the browsers who started the initiative now. The article links to the vote thread: https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/bvWh5RN6tYI https://groups.google.com/a/groups.cabforum.org/g/servercert... And here's the CABF discussion before the vote: https://github.com/cabforum/servercert/pull/553/commits/69cea5473f20e6ea518dbec8ac549d88f8a35830 https://github.com/cabforum/servercert/pull/553/commits/69ce...
  • nickf 1y ago
    It wasn't just the browsers. Some CAs supported this for a long time, and even directly endorsed the ballot. You're not wrong about the browsers having 'the power', but then again - they are the representatives of billions of relying parties, so it's expected.