Public Poll: Which should be the default certificate chain issued by Let's Encrypt?



Which should be the default certificate chain issued by Let's Encrypt?

0 voters


I think that ship has already sailed. I don't think ISRG is going to change their minds on that. The decision was that Let's Encrypt should serve the most users by default, and that means Android.


This is just for curiosity of public opinion. I doubt it will result in change. I believe there were many circumstances that were not fully foreseen/weighed.


But it is still sailing... and can always change its' course.
But that is not what this is about.

This poll simply asks: What do you think should be ... ?
[and counts those votes]

Regardless of the outcome - I would like to see many votes and its' result.


Personally I can't refer people to use the long chain due to lack of compatibility with windows servers. There's not so many of those, but the ones that do exist are often serving really major services (like the CMS for an entire US state etc), unfortunately the workarounds are not so reliable or easy and I generally have to recommend a CA change for those with compatibility issues (even then that leads to a different set of compatibility issues).

If root certs expired more often (like, a root lasts exactly one year), operating systems that access the internet would be forced to include robust update processes by default, instead of relying on user intervention. The current process for updating devices is not working well enough to be sustainable.


If there were a choice between technical correctness and compatibility, I could see an argument either way. But both options present incompatibility problems with different software. For me, technically correct and incompatible with some things beats technically wrong and still incompatible with some things.


My own preference for Centmin Mod LEMP stack and its users was to switch to the shorter chain

Reason why is due to CentOS 7 and Openssl 1.0.2 usage. The DST ROOT CA X3 expiration can potentially break wget, curl and openssl and other unforeseen usage on connected systems. Breaking the relatively smaller amount of old device usage does not seem as big a deal. And even then, I've outlined to my users how to switch from Letsencrypt SSL certificates to ZeroSSL SSL certificates which use Sectigo and have a crossed signed AAA Certificate Services CA root which has older device compatibility all the way back to Android 2.3 and macOS 10.4


Interested to hear what do you consider 'technical correctness' here? Both of Let's Encrypts chains are technically correct - it is completly valid to serve a chain leading up to an expired root, because chains are not singular linear paths, they're graphs (or trees) where multiple paths can exist - no one ever stated that all possible paths have to be valid*.

The implementations often get this wrong, which is why they now have problems with Let's Encrypts chain. So what is 'technical correct' here?

*Ryan Sleevi has a good post about this: Path Building vs Path Verifying: The Chain of Pain | by Ryan Sleevi | Medium


The tricky part is that which default is "obviously" better depends a lot on whether you primarily work on systems that serve content to "other systems" (API-type stuff, where openssl compatibility would clearly be more important), or primarily work on systems that serve content to "average users who might be browsing on their phones" (web pages, where old-Android compatibility would clearly be more important). I'm guessing (or maybe hoping?) that Let's Encrypt had data that the latter types of servers were much more common, even though for me personally the kinds of things I work on are more often in first camp.

I do think it would have been good (in retrospect) for the Let's Encrypt API endpoint itself to have switched to the alternate chain significantly before the expiration, just because I think there were some issues some people had connecting to Let's Encrypt at all because their servers weren't using an updated trust store themselves, and it would have been good to spread out that type of trouble to a different timeframe.


The more implementation problems I encounter with using the long chain, the more uneasy I get about it being the default. I just found out that using the long chain in GoDaddy cPanel shared hosting blows up IMAP/POP3 support.


These be uncharted waters we be wading through now...
Cartographers take note!
[cryptographers too]


I'd like to add here that "some older Android devices" happens to include brand new (as of two weeks ago) issued phones (at least one of which I have access to for testing) for those who are eligible for the Federal Lifeline program.
Lifeline Program for Low-Income Consumers | Federal Communications Commission (

For some (API's and such), this won't matter at all. But before you decide who you're okay with cutting off, be sure you're okay with cutting off the already underserved. It sure would suck if you're on welfare and trying to apply for a job, but can't because your only access to the internet can't even view the website.

I'm no law-doctor, but if you're a government agency serving up public information, cutting off these specific users may be considered a civil rights violation. I recommend getting your legal department involved.


I don't know much about this stuff. Could anyone explain what is the purpose of still including the expired DST root certificate? Since it is now expired, what good does it do?


Welcome to the community!
Here is the explanation:

Shortly: it gives old Android version ( =< 7 ) compatibility.


First off, "brand new" could mean multiple things so I'll clarify: it is a device not previously opened or used. Who knows how long it was sitting in their inventory. My point is, the government is shipping these devices out for welfare recipients to use as their access to the internet - as recently as two weeks ago.

Secondly, there's a nice page with community guidelines that somebody went to great effort creating so that this place remains amicable.
I'm open to constructive criticism, however I won't tolerate abuse or unprovoked attitude.

Lastly, I don't owe you anything. If you want the make/model of the device, you can ask for it respectfully.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.