package.elm-lang.org uses expired DST Root X3 certificate #355
Comments
|
For completeness the chain as offered up by the server is as follows, the offending (signed by expired root) cert being the last one: |
|
Could you provide more details about "use of this chain causes problems on many non-Android OSes" and "this configuration causes breaks in other people's infrastructure" with some sources please? |
|
These issues are well-documented. An announcement from LE: https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816, more info: https://medium.com/geekculture/will-you-be-impacted-by-letsencrypt-dst-root-ca-x3-expiration-d54a018df257 The gist of it is that clients using older versions of TLS libraries such as OpenSSL < 1.1 do not correctly verify the chain of trust by default (and client software does not generally configure the library to do it correctly), meaning that if the expired root is present in the chain they fail the verification rather than noticing that one of the intermediate certs is also a root in and of itself. While the most up-to-date versions of said libraries do not have this problem, use of the older libraries is still widespread and those clients will now not be able to connect to package.elm-lang.org securely until they are updated, which it is not always possible for everyone to do. Since the reason for serving this chain with an expired root by Let's Encrypt is compatibility with a mobile OS that is not relevant to the service, use of the shorter, non-cross-signed chain is more appropriate. |
|
Thank you. Do you have some examples of applications using package.elm-lang.org with OpenSSL < 1.1? Also is there some evidence that using the default chain breaks more clients (using OpenSSL < 1.1) than using the "ISRG Root X1" one (breaking older Android versions)? |
|
Well l figured it out because my CI process using an older version of NodeJS broke unexplainedly. The new ISRG X1 root (short chain) only breaks on clients that do not have that certificate in their store. The long chain breaks on older clients that do not verify the chain correctly, even if they have the new root in their store. I don't have numbers but here's a table of breakage: Old client, ISRG Root not in store, short chain: Breaks (untrusted, expected) In summary: clients (except Android) without the ISRG root in their store are broken regardless and will need the new root cert added to their trust store. Old clients with the cert will work with the short chain but not the long one. New clients will work with either. The only OS that benefits from using the long chain is Android 4 through 7.1 which I maintain is completely irrelevant to this service. So changing to the short chain only breaks access by this irrelevant OS, while fixing access by relevant-but-not-updated clients. |
Hi,
As of this moment, package.elm-lang.org is configured to use the Let's Encrypt default chain which includes the expired root certificate mentioned in the title. Let's Encrypt uses this to provide compatibility with Android 7 and earlier (which does not check the notAfter date on trust anchor certs), but use of this chain causes problems on many non-Android OSes.
Since Android compatibility is not a necessity for this service and this configuration causes breaks in other people's infrastructure, I suggest that Certbot be set (using
--preferred-chain "ISRG Root X1") to use the short ISRG Root X1 chain instead. This should not cause issues as systems without that root in their trust stores will not accept the expired DST root either, but it will solve breakage for those of us with systems that reject the certificate chain upon encountering the expired root.The text was updated successfully, but these errors were encountered: