Pros and cons of 90-day certificate lifetimes


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.


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:


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.


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.


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.



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.


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


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


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

Automating issuance with Kubernetes

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.


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.


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

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.


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.


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.



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 / 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.


I’ll add another problem with the 90-day lifetime. I have the following:

  1. Linux Server with Apache which uses: PEM, CERT, CHAIN
  2. Within my Linux server I have several Java programs which use: JKS
  3. A Windows Server - PFX (with password for private key)
  4. A media server on a different Windows 10 machine - PFX (no password)

As I’m sure you can imagine, I’m not really interested in keeping these various parts updated every 90 days.

The problem, to me, is that the Let’s Encrypt use case is a single server or, I guess, many servers all running the same operating system and all referencing the exact same SSL certificate. In that case, sure, there’s no big deal for a 90-day auto renew.

But what about my use case? Multiple machines with different OSes none of which speak the same SSL language. All of a sudden, it’s not such an automatic process at all but rather a tedious manual one.

For the automation to work, at least in my case, Let’s Encrypt would need to not only renew the certificates but convert and properly propagate them as well. As this seems like a large ask at this point, a longer timeframe seems like a reasonable alternative. Doing this once every two or three years, okay. Every 3 months? Ugh, forget it.


I have similar scenarios @mobamoba and I’ve automated it with scripts. It takes a little longer to do first time, but then it’s automated and has worked automatically for many months now ( coming up to 12 months in many of my cases).


@serverco If you feel comfortable sharing those scripts, I’d appreciate it as maybe they could help me get started on my own. If I recall, the conversions were hair pulling (the JKS was especially bad in my memory). It’s too much of a fantasy I guess to hope that there could just be a single format for SSL that every operating system could understand. Sigh, one day…


A single storage format would be ideal lol (but that’s way beyond Let’s Encrypt :wink: ) - I don’t mind sharing scripts - I’ll PM you.