Pros and cons of 90-day certificate lifetimes


#404

The message from jsha didn’t seem to sink in.

In your opinion.

Tell McDonalds to stop advertising. We’ve heard their message before. Pounding it into our brain adds nothing to their sales. You obviously don’t get the concept of persuasion and the power of persistence. Or maybe you do and it is concerning to you that it may get traction and be successful against your desires. So you try to discourage it with nonsense like you just posted.


#405

I agree that repeating the same arguments over and over again isn’t going to lead anywhere. Derailing the discussion with meta-posts is not really a contribution to the discussion either.

This is obviously not an issue with simple black-and-white logic. There are tradeoffs and priorities involved. This thread exists so that we can discuss these tradeoffs, find use-cases from various perspectives where short-lived certificates can be problematic, and determine whether supporting these use-cases is worthwhile in exchange for the added security benefits of short-lived certificates and the push towards automation. It is not a place for propaganda and/or brigading, nor is it a place to exchange personal attacks. I hope all participants in this discussion can accept that.


#406

Just to re-iterate my concern from an earlier comment here (Pros and cons of 90-day certificate lifetimes)

The current implementation of the clients and behavior of the registry does not offer a commitment or expectation to keep things backwards compatible for a window of time. This can be somewhat scary when you have 90day certifications and need to rely on automated systems that routinely update against something that could break.

Within the next 90 days, the intermediate signing authority could change – and it could be changed to a root that is not enabled on our test devices or production clients by default.

It would be great if there were some sort of compatibility commitment, and a notification system that people can opt-into for upcoming platform changes (such as cycling keys).


#407

Major changes will be announced to subscribers via email, that’s why those addresses are being collected (plus expiration mails, of course). Protocol changes are always done with backwards compatibility in mind - new ACME versions, for example, will run on a new API endpoint.

Regarding key rollover, I agree that this can be problematic. The nice bit about ACME is that all these things are first-party components of the protocol - issuer certificates are part of it, and there’s even supports multiple issuer certificates so that clients can pick one that it thinks works best, or just serve all of them. The Integration Guide has a section called “Plan for Change” which captures this sentiment quite nicely.

There are always going to be things that break in unexpected ways (like the Windows bug that was triggered when the issuer certificate was changed), but as a whole the ecosystem should become more stable and reliable as a result of this. There are a lot of parallels to the DevOps vs. traditional sysadmin discussion, I think.


#408

I can see that. My concern though is that short expiry means frequent automatic certificate updates, which means there is another component that might break. Alerting a “major change” might not be good enough – moderate changes might be a better plan until things are more stable and predictable. In this MS case, a minor change had profound effects.

In any event, there should also be some sort of official statement on the backwards compatibility - and this is from a product management, not engineering standpoint (which might be why I’m having trouble conveying my concern, so I’ll rephrase). The short lifetime and current auto-renew practice means there is a 60-day lifetime (with 30 day grace) on a given cert. In 60 days time, the next cert I get is not guaranteed to work with the same devices or browsers because the signing key and it’s inheritance chain might change. That is what worries me.

I’m fine with a 90 day - or even 10 day - expiration on the certificate. What I’m not fine with, is that there is no official policy on how long I can reliably depend on renewals targeting currently compatible browsers and devices. This currently requires a leap-of-faith.

Using a (bad) analogy, pretend that LetsEncrypt is a javascript library that works by including a link to a versionless ‘head’ url. This is great, as the url always has the fastest, lightest, best version. Right now, the library works with ie5 – and there is no policy that says how long it will work with ie5, or if support might just disappear and ie10 is the new minimum.


#409

Why would browser compatibility change? The thing I mentioned about multiple issuer certificates was specifically for this point: The current cross-signing intermediate (as in: any intermediate leading up to the DST root, not this specific instance of a cert) is going to be around for a long time, it’ll take years till ISRG is recognised by the majority of users. Sure, there might be a key rollover, additional issuer certs could be added, but that does not break anything as long as you implement ACME correctly and follow best practices. I would also expect there to be a lot of compatibility testing in case any of the X509 fields are changed for future issuer certificates after seeing how XP was initially affected by a subtle bug triggered by the X1/X2 certificates, with the baseline being the currently supported devices. This part of the Integration Guide would apply here, I think, in case there are any backwards-incompatible changes:

To make a reference back to “traditional” CAs, it turns out Let’s Encrypt wasn’t the first CA to trigger the IIS bug that caused issues during the X1 -> X3 migration (there are some old Stack Overflow questions on this topic, I believe one of the affected CAs was StartCom). Even traditional CAs don’t typically guarantee which intermediate certificate is going to be used, and you’re not safe from subtle bugs like that one. There’s a good chance an issue like that (where the correct intermediate certificate is missing) wouldn’t have been noticed during testing even for manual certificate deployments as those are cached by browsers and there’s a good chance you’d have visited a site with that intermediate before … so would you really be off any better with a manual system (not that you’re making that argument, but in an attempt to weigh the risk you’re mentioning)? :smile:


#410

I’m not talking about breaking ACME or code or developer tools, I’m talking about breaking penetration.

So I’ll try this again…

The intermediate cross-signing certificate could change. It’s incredibly unlikely to change, but it could change. It is currently cross-signed by a specific IdenTrust root that has certain penetration and compatibility.

Future “business” issues could require working with another vendor to cross-sign, or staying with IdenTrust but being cross-signed by another one of their roots. That potential other certificate would not necessarily have the same penetration for browser/device/operating system.

Between the 90 expiry date (with 60 day renewal) and a lack of a “target platforms” commitment, that leaves this situation possible:

  1. CertA could be usable by 100% of my target audience, then auto-renew to CertB which might only work for 99% of my audience on Day60.
  2. If I roll-back to CertA, I have 30 days to find a new CA that is compatible with my entire audience, and convert my infrastructure to them.

This is somewhat scary. Without some sort of official commitment to attempt maintaining compatibility if an alternate upstream CAs is needed, using LetsEncrypt means there will be several-chances each year that a nightmarish situation could happen. This only happens once per-year (or two) with longer certificate lifetimes.

This is a variant of weighing having to wonder “What if LetsEncrypt goes out of business?” every other month against a longer term CA.

absolutely not. I’m simply addressing a con of the 90-day certificate lifetime being compounded by an automatic system that renews at day 60.

This could, I stress, be handled quite simply by a bulletpoint in the policy that states something like “if we begin signing with new keys for any reason, we will strive to use options that have equal distribution/compatibility.” Perhaps also promise trying to give 6mos or 1yr notice if the upstream vendor will change to something that is known to be incompatible.

I know that these things can’t be guaranteed and I don’t expect them to. I do expect LetsEncrypt to be prepared for things like this.

I was once the head of tech & product at a major publisher with tens of millions of monthly visitors, using every mix of browser, os or device imaginable. The combination of a short certificate span, a background cronjob with the lack of an official policy that states “we’ll try to not break this for your users” is the sort of thing that would make LetsEncrypt not a viable option for me in certain contexts.


#413

Short of IdenTrust’s (offline) root key being compromised (i.e. the “security flaw/short-term fix” case), I don’t see a switch like that happening without significant advance notice. There’s no real SLA, so from a business/legal point of view it wouldn’t make much of a difference (not a bad topic for discussion, but to be honest I haven’t seen much regarding SLAs in the CA industry in general).

It comes down to what’s being promised here and in the documentation. I think a significant change like that would definitely fall into the “advance notice” category. As an example for the commitment on backwards compatibility, an upcoming change in boulder that could break renewal for about 0.1% of all domains Let’s Encrypt has issued certificates for was implemented with an exception list for all affected domains in order to prevent that.


#414

This is an excellent point, @jvanasco, and you’ve crystallized it quite well. I agree that Let’s Encrypt should provide more formal guidance on which platforms we intend to support, and how much advance warning we’ll give when that is going to change. I’ll talk with the team about what that guidance should be. It may take a little while to finalize it.

Thanks,
Jacob


#416

I don’t either. But there’s a difference between “what an established community member feels an official rep’s blog post means” and “a bulletpoint on the policy page of the dot-org”. There’s also a difference between how developers commit to backwards compatibility in practice, and what the org’s stated protocols are. Finally, IdenTrust could potentially immediately end the relationship from their end, and possibly even revoke ISRG’s certs - which would create a window that is at-most 60-90 days.

ISRG is unofficially doing many things the right way, but should be making those practices official policies.

You said that way better than I did. I’m glad I got this point across!

Just for a bit more perspective on this – keep in mind that there are massive secondary markets for mobile devices and computers in other parts of the world. A lot of companies now take a US/Euro centric approach and don’t support things that are more than a few years old, and that can disproportionately limit benefit to these areas.


#417

3 posts were split to a new topic: Let’s Monitor site


#418

Side mention: I think that “Reply as linked topic” button is not visible to new users.


#419

6 posts were split to a new topic: Automating issuance with Kubernetes


Automating issuance with Kubernetes
#420

This thread, again, got far too long to read it completely.

As far as I see there never was any response of the responsible people, right?

There may be many advantages of this “auto renew” thing but even if they exist, this mechanism shouldn’t be forced.

There are many users that can’t use this auto renew process (as they are not allowed to install such services in shared hosting, for example) or don’t want to do as they want to do such administrative tasks on their own without trusting some automatic process.

If you really want to help to encrypt all pages on the web you should make this as easy as possible. This also includes to help people that don’t want the automatic update process by allowing longer certificate lifetimes.


#421

This situation shouldn’t exist, cPanel/WHM now support LE with the AutoSSL feature. The onus is on hosting providers to keep up with this or lose customers.


#422

I don’t think so. At least for me HTTPS is not a that big priority. I could use it if it would be easy to use, but I won’t change my hoster just for LE. The idea behind LE is great (free certificates for everyone) but at least for me it is a bad decision to force people into the automatic certificate generation process.


Automating issuance with Kubernetes
#423

Obviously, or you’d have seen that the issue you raised has already been discussed ad nauseum. Automation is central to Let’s Encrypt’s model. If you are unable or (more likely) unwilling to use an automated solution for cert issuance and renewal, Let’s Encrypt just isn’t for you.


#424

Just to state, I use LE for my websites and I still renew them manually every 89 days. It’s a pain, but I do it only manually and not automatically.


#425

Wow. I’ve been aware of Let’s Encrypt for a while but came to take a better look at it due to Mozilla killing off StartCom certs. I had no idea this 90 day time limit was such an embattled issue. Personally, I’ve got no problem with automating 90 day rotating certs on systems that are open enough to do so. And if you can convince hardware manufacturers to implement let’s encrypt clients into their devices, more power to you. But I’ve got this nice Brother laser printer I bought last year with a StartSSL cert that needs replacing. And it’s a serious PITA to install certs on it. And it will never have a let’s encrypt client on it. The same can be said for a fair number of embedded devices in my house from my zigbee electric meter reader to my environmental sensor system. And if Let’s Encrypt decides they only want to secure general purpose web servers and not special purpose/embedded web servers, or even SSL applications that aren’t web servers, because they don’t fit their model of how they think certificate deployment should work, well, I guess that’s their privilege given it’s their service. It doesn’t really seem those bits are any less worthy of being protected on the wire though… And it’s not like the use cases are going to go away just because you don’t like them. I can’t even get HP to support loading intermediate certificates on their embedded iLO server management interfaces, I would love to hear somebody try to talk to them about including a let’s encypt client ;).

So, anybody know of a StartSSL replacement without so much of an agenda? Not looking to change the world at this point, just want to encrypt stuff without paying through the nose to the snake oil companies.

Thanks…


#426

Part of the point of LE is to make certificate replacement more automated so it’s much easier to do for every interface. It’s not going to happen overnight, but maybe with some time and more support from other providers, makers may move in this direction.

Alternately, you could see if there is a way to program (or hire someone to program) a tool that would automatically update the certs by emulating the right interactions.

If you don’t need public access to your devices, you could always make your own internal CA and issue five year (or ten or more) certs to your devices. You’d just need to add trust for your private CA to avoid certificate warnings.

I’m not aware of any widely-supported option. There’s CACert, but they’ve had unending problems passing the audits needed to be added to many certificate stores.

Alternately, you can find some resellers (like NameCheap / SSLs.com) that issue basic single-domain certificates for $10/yr or less. If you need a certificate with public acceptance and LE won’t work for you, it’s not a high price.