Upcoming Changes to Let's Encrypt Certificates

I'm quite surprised the CA/Browser Forum went for this.

Nobody's paying for EV certificates now browsers don't display the EV details. The only reason to pay for a certificate is if you're rotating certificates manually, and the 90 day expiry of Lets Encrypt certificates is a hassle.

If the CA/Browser Forum is forcing everyone to run ACME clients (or outsource to a managed provider like AWS or Cloudflare) doesn't that eliminate the last substantial reason to give money to a CA?

They won't adopt Acme, as once a customer adopts it, the effort to transition to a new (free) provider is almost zero.

I expect they will introduce new, "more secure", proprietary methods, and ride the vendor lock-in until the paid certificate industries death.

I hope everyone will adopt ACME I still have to send CSR to the customers and they send me cert back. It is okish once a year.

There are 2 and GTS is also technically free. Just hard to use.

> If you use Caddy that's even the default behavior - it tries ZeroSSL first and automatically falls back to Let's Encrypt if that fails for whatever reason.

No, that's false. It's the other way around.

“If Caddy cannot get a certificate from Let's Encrypt, it will try with ZeroSSL”. Source: https://caddyserver.com/docs/automatic-https#issuer-fallback

Which makes sense, since the ACME access to ZeroSSL must go through an account created by a manual registration step. Unless the landscape changed very recently, LE is still the only free ACME that does not require registration. Source: https://poshac.me/docs/v4/Guides/ACME-CA-Comparison/#acme-ca...

LE has some gnarly rate limiting rules, so I use ZeroSSL. Works out great for my purposes.

How are all those free CAs financed?

Man, I agree. The whole thing sucks so much. We started building a centralized way to do this internally last year to get better visibility into renewals and expirations:

We're doing a beta of it for some other groups now. https://www.certkit.io/

It's fine for fintechs and social accounts to require SSL, but do blogs really need certs? You know what blogs I'm reading from my DNS requests anyway. I doubt anyone is going to MITM my access to an art historian's personal website. There is zero need for security theater here.

All of these required, complex, constantly moving components mean we're beholden to larger tech companies and can't do things by ourselves anymore without increasing effort. It also makes it easier for central government to start revoking access once they put a thumb on cert issuance. Parties that the powers don't like can be pruned through cert revocation. In the future issuance may be limited to parties with state IDs.

And because mainstream tech is now incompatible with any other distribution method, you suddenly lose the ability to broadcast ideas if you fall out of compliance. The levers of 1984.

Thanks for this history, I wasn't aware. It's an interesting point that if this is happening anyways by Apple's fiat, it's in the legacy CAs' interest to even further accelerate the mandatory timeline, so they can pivot to consulting services for their existing customers.

I do still feel that "that blog/publication that had immense cultural impact years ago, that was acquired/put on life support with annual certificate updates, will now be taken offline rather than migrated to a system that can support ACME automations, because the consultants charge more than the ad revenue" will be an unfortunate class of casualty. But that's progress, I suppose.

It's interesting that this is pretty much identical to the WHATWG/W3C situation: there is theoretically a standards body, but in practice it's defunct; the browsers announce what they will ship, and the "standards body" can do nothing but meekly comply.

The difference being that there's at least a little bit of popular dissatisfaction with the status quo of browsers unilaterally dictating web standards, whereas no one came to the defense of CAs, since everybody hated them. A useful lesson that you need to do reputation management even if you're running a successful racket, since if people hate you enough they might not stick up for you even if someone comes for you "illegally".

You have a different definition of soon than me.

Paid certs are valid for 1-year from the $$ CAs. LE certs are only good for ~3-4 months before they have to be reissued. If there's no easy way to do an automated ACME setup to handle the renewal, being able to defer that for a year is worth the $20 or $70 for a wildcard.

If paid certs drop in max validity period, then yeah, zero reason to burn money for no reason.

New web features are https-only by default, since a few years ago. So if your site uses any recent APIs, dropping encryption is not an option.

You assume it’s just the certs being purchased - and not support, SLAs, other related products, management platforms, private PKI and more. If all you do is public TLS, sure, that might be an issue.

PCI still recommends 90 day password changes. Luckily they've softened their stance to allow zero-trust to be used instead. They're not really equivalent controls, but clearly laid out as 'OR' in 8.3.9 regardless.

But that would mean doing less, and that's by default bad. We must take action! Think of the children!

I tried at my workplace to get them to stop mandatory rotation when that research came out. My request was shot down without any attempt at justification. I don't know if it's fear of liability or if the cyber insurers are requiring it, but by gum we're going to rotate passwords until the sun burns out.

The problem is when the automation fails, you're back to manual. And decreasing the period between updates means more chances for failure. I've been flamed by HN for admitting this, but I've never gotten automated L.E. certificate renewal to work reliably. Something always fails. Fortunately I just host a handful of hobby and club domains and personal E-mail, and don't rely on my domains for income. Now, I know it's been 90 days because one of my web sites fails or E-mail starts to complain about the certificate being bad, and I have to ssh into my VPS to muck around. This news seems to indicate that I get to babysit certbot even more frequently in the future.

Except this isn't really viable for any kind of internal certs, where random internal teams don't have access to modify the corporate DNS. TLS is already a horrible system to deal with for internal software, and browsers keep making it worse and worse.

Not to mention that the WEBPKI has made it completely unviable to deliver any kind of consumer software as an offline personal web server, since people are not going to be buying their own DNS domains just to get their browser to stop complaining that accessing local software is insecure. So, you either teach your users to ignore insecure browser warnings, or you tie the server to some kind of online subscription that you manage and generate fake certificates for your customer's private IPs just to get the browsers to shut up.

Enforcing an arbitrary mitigation to a problem the industry does not know how to solve doesn't make it a good solution. It's just a solution the corporate world prefers.

It costs more to let's encrypt.

It’s a stupid policy. To solve the non-existent problem with certificates, we are pushing the problem to demonstrating that we have access to a DNS registrar’s service portal.

It also ignores the real world as the CA/Browser forum admits they don't understand how certificates are actually used in the real world. They're just breaking shit to make the world a worse place.

I fear this reflects two misunderstandings.

First, one of the purposes of shorter certificates is to make revocation easier in the case of misissuance. Just having certificates issued to you be shorter-lived doesn't address this, because the attacker can ask for a longer-lived certificate.

Second, creating a new browser wouldn't address the issue because sites need to have their certificates be acceptable to basically every browser, and so as long as a big fraction of the browser market (e.g., Chrome) insists on certificates being shorter-lived and will reject certificates with longer lifetimes, sites will need to get short-lived certificates, even if some other browser would accept longer lifetimes.

You can have more than one CAA record, so it should be possible to configure backup certificate authorities. It's probably a good idea to do that for important sites.

Name one, baseide the NSA run Cloudflare.

Doesn't matter. This is a push by the CA/Browser Forum. Google, Mozilla, and all the CAs got together and said, "hey, what if we just made certificates shorter because we're too stupid to figure out a revocation mechanism that actually works other than expiration." They've tried this shit before, but saner heads prevailed. This time they did not.

You say it like it’s a bad thing. Do you donate to them? I do !

Shorter lifetimes means more renewal events, which means more individual occasions in which LE (or whatever other cert authority) simply must be available before sites start falling off the internet for lack of ability to renew in time.

We're not quite there yet, but the logical progression of shorter and shorter certificate lifetimes to obviate the problems related to revocation lists would suggest that we eventually end up in a place where the major ACME CAs join the list of heavily-centralized companies which are dependencies of "the internet", alongside AWS, Cloudflare, and friends. With cert lifetimes measured in years or months, the CA can have a bad day and as long as you didn't wait until the last possible minute to renew, you're unimpacted. With cert lifetimes trending towards days or less, now your CA really does need institutionally important levels of high availability.

Its less that LE becomes more of a single point of failure than it is that the concept of ACME CAs in general join the list of critically available things required to keep a site online.

Because when they eventually get their wet dream of 7-day renewals, everyone replies upon them once a week. LE being down for 48-hours could take out a big chunk of the Internet.

Certificates have historically been a "fire and forget" but constant re-issuance will make LE as important as DNS and web hosting.

Increasing the number of touchpoints dramatically increases the probability that the service will be unavailable and and a service impact.

Yeah, doesn't the ACME bot defaults have it trying to renew the cert when it has like 30% of its life time left? Which means the CA would have to be down for Days/Weeks fo it to impact production.

Oh and you would definitely know about this outage because you would hear about it in your news, and the monitoring you already have set up to yell at you when you cert is about to retire (you already have that right? Right?). And you can STILL trivially switch to another CA that supports ACME.

Sectigo is also going to be forced into issuing short-lived certificates. This is a CA/Browser Forum decision that is binding on all member CAs.

Actalis is European, Italian to be more precise, owned by Aruba (if that last thing is good or not can be probably discussed, though).

serious q: maybe not 60 sec, but why 45 days instead of ~1 day or even hours? at 45 days, it pretty much has to be automated.

asynchronous revocation check would be far superior option; I'm sad industry abandoned trying to make it work.

[flagged]

Basically OCSP stapling (more specifically must-staple) is isomorphic to short-lived certificates.

Have you heard the good news of Merkle Tree Certificates[1,2]? They include the transparency cryptography directly in the certificate issuance pipeline. This has multiple benefits, one of them being way smaller transparency logs.

1: https://www.youtube.com/watch?v=uSP9uT_wBDw A great explainer of how they work and why they're better.

2: https://davidben.github.io/merkle-tree-certs/draft-davidben-... The current working draft

I am a CT log operator and I hands down support short-lived certificates. Automation and short lifetimes solve a lot of the pain points of the WebPKI.

We can solve the storage requirements, it’s fine.

Is there a big use case for permanent CT logs of long-expired certificate?

Where did you get 17 days from?

Not precise, but for example if it's been over a day since the last time update, i start getting errors on various sites, including virtually every site behind cloudflare. (assuming you're referring to the initial issue I mentioned).

One of the setups that gives me issues is machines that are resumed from a historical snapshot and start doing things immediately, if the NTP date hasn't been updated since the last snapshot you start getting issues (despite snapshots being updated after every daily run). Most sites won't break (especially with a 24h window, although longer always have issues), but enough sites change their certs so frequently now, it's a constant issue.

Even with a 10 year cert, if you access at the right time you'll have issues, the difference now is it isn't a once in a 10 year event, but once in every few days some times.

Perhaps if TLS clients requesting a time update to the OS was a standardized thing and if NTP client daemons supported that method it would be a lot less painful?

Should we remove anything that was at some point misconfigured somewhere?

> The certificate offered from server to client and the certificate the server expects from the client do not need to share a CA.

Sure, but it seems like all the CAs are stopping issuing certificates with the client EKU. At least LetsEncrypt and DigiCert, since by the Google requirement they can't do that and normal certs, and I guess there's not enough market to have one just for that.

> You might do that if you're using the host HTTPS certificates handed out by certbot or other CAs as mTLS client certificate

Sure, what's wrong with that?

> You can still generate your own mTLS key pairs and use them to authenticate over a connection whose hostname is verified with Let's Encrypt, which is what most people will be doing.

That lets the client verify the host, but the server doesn't know where the connection is coming from. Generating mTLS pairs means pinning and coordinated rotation and all that. Currently servers can simply keep an up to date CA store (which is common and easy), and check the subject name, freeing the client to easily rotate their cert.

If you mean that sites with expired certificates may technically be accessible if one jumps through enough hoops and ignores scary warnings - yes, of course you’re right.

Maybe this will just teach everyone to click through SSL warnings the same way they click through GDPR popups - for better or worse.