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