When we compare the SSL hadnshake between a client your domain, with that to one from "university.webflow.com" which uses X1 there is a difference in the certificates sent by the server during SSL handshake.
We see that for your test domain the server never sends the X1 certificate in the handshake (only the domain + R3), but for the webflow it sends the ISRG Root X1 and it lists is signed by DST Root CA (domain + R3 + ISRG Root X1). Your test URL works in old OpenSSL, Webflow does not.
Based on webflow.com they are following your instructions: "We have been following the advice from LetsEncrypt at OpenSSL Client Compatibility Changes for Let’s Encrypt Certificates which is to use their default chain. This is the one where Android phones and tablets can continue to work, but where older versions of OpenSSL will not."
The question is why cannot everyone do what you are doing for your test domain? Is this a misunderstanding of your instructions, or is your test domain not following the instructions you are providing to the community?
The test domain https://valid-isrgrootx1.letsencrypt.org/ is specifically required by the Baseline Requirements that all CAs follow to be chained up to the ISRG Root X1 root. So, yes, it uses the "alternate" rather than the "default" chain, since its purpose is to test compatibility with systems trusting ISRG Root X1.
If you're looking for an "official" test site with the default chain (that includes compatibility for old Android), I believe that's https://helloworld.letsencrypt.org. This test site isn't "required" by the Baseline Requirements, though, so I don't know if Let's Encrypt might be testing other things with that site at various times.
"Everyone" can choose whether to use the default chain on the alternate chain on their own site, depending on whether they want to break old Android or break old Openssl.
That's probably due to university.webflow.com not supporting TLS 1.0, and I'm guessing an Android that old doesn't support TLS 1.2.
Yes, that's what I was trying to say, that helloworld uses the "default" long chain that supports old Android.
Yes, Android that old doesn't work with either DST Root CA X3 or ISRG Root X1. The Certificate Compaibility page says that Android before 2.3.6 doesn't handle Let's Encrypt certificates in any way.
You probably need to enable TLS 1.2 (if that's even possible) on an Android that old in order to get to most web sites nowadays. It's not a certificate issue, it's just that it needs to speak a current HTTPS protocol.
For 4.1 <= Android <= Kitkat, TLS v1.2 can be manually enabled by the application, but I don't think the inbuild browser features such an option.
Apps that only use higher-level stacks can also patch the Security Provider via Google Play, though again I don't think this is done by the inbuild browser of such an old OS. I don't even have confirmed reports that patching the security provider provides major upgrades, such as the TLS version.
For such old devices, TLS 1.0 must be enabled server-side.
So if these sites will not work on Android 4.0 and earlier because of the TSL version support, why wouldn't the recommendation be use alternate path like https://valid-isrgrootx1.letsencrypt.org/ since that will work on all the more modern HTTP clients.
It seems a lot of vendors just assumed use the "default" chain, but I am not sure i see the value of doing that - if nothing will work on Android 4.0 and earlier.
This isn't true. While many servers have TLS 1.0 (and 1.1) turned off nowadays for security reasons, there's no requirement to do so (well, apart from random policies maybe). For example, libraries like OpenSSL still support TLS 1.0 and large CDNs often also. You can simply re-enable TLS 1.0 serverside. Let's Encrypts certificates are not bound to the TLS version and can be used with any protocol using X.509 certificates.
It's just a fact that most servers have that old protocol disabled, but they could re-enable it, if they wanted to. So there is no Let's Encrypt incompatibility with Android < 4.0. There seems to be some incompatibility with devices < Android 2.3.6, but not 4.0.
https://valid-isrgrootx1.letsencrypt.org/ on the other hand is only compatible with Android devices running version 7.1 or higher. That's quite a gap to 2.3/4.0. Those devices are incompatible with the alternate chain, but are compatible with the default chain.
This policy ensures maximum compatibility with legacy systems; it is less secure and it includes support for TLS 1.0, TLS 1.1, and SSH2 protocols or later. The algorithms DSA, 3DES, and RC4 are allowed, while RSA and Diffie-Hellman parameters are accepted if larger than 1023-bits.
DEFAULT
The DEFAULT policy is a reasonable default policy for today's standards, aimed for a balance between usability and security. It allows the TLS 1.2 and 1.3 protocols, as well as IKEv2 and SSH2. The RSA and Diffie-Hellman parameters are accepted if larger than 2047-bits.
FUTURE
A conservative security level that is believed to withstand any near-term future attacks. The purpose of the policy is for testing infrastructure and applications for their readiness for future strengthening of requirements. The policy is not supposed to be used for general purpose systems. This level does not allow the use of SHA-1 in signature algorithms. The RSA and Diffie-Hellman parameters are accepted if larger than 3071-bits.
FIPS
A level that conforms to the FIPS140-2 requirements. This policy is used internally by the fips-mode-setup tool which can switch the RHEL system into FIPS140 mode.
