I am having problems with the certificate chain served by Azure App Services.
I have issued a completely standard Let's Encrypt certificate for a (sub) domain mitid.oxhoej.dk.
The certificate is issued with the default "long chain" which ends in an ISRG Root X1, cross-signed by DST Root CA X3, so should work with old pre-7.1.1 Android phones. Extending Android Device Compatibility for Let's Encrypt Certificates
I followed the instructions on Securing your Azure Web App with Let's Encrypt. to generate the .pfx file, and upload it as the certificate to use for the "SSL Binding" of the App Service.
Checking the certificates in the .pfx file with "openssl pkcs12 -in certificate.pfx -info" shows that the .pfx file does indeed contain all 3 expected certificates in the chain:
subject=CN = mitid.oxhoej.dk
issuer=C = US, O = Let's Encrypt, CN = R3
---
subject=C = US, O = Let's Encrypt, CN = R3
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
issuer=O = Digital Signature Trust Co., CN = DST Root CA X3
Azure App Services is important in this context because it means OP does not have any control over the underlying IIS web server.
Unfortunately, my understanding is that Azure App Services (much like IIS on Windows) doesn't provide fine-grained control over the chain being served by the underlying web server. And since the underlying web server appears to be IIS on Windows, it will default to the short chain.
There does appear to be an offering for Azure App Services running on Linux. But I don't know whether it provides more control over the chain. You might be better off terminating your TLS traffic against something like a reverse proxy or load balancer sitting in front of the Azure App Service.
Yeah it's not worth the hassle, you can get the old chain to be served if you put application gateway (or Azure Front Door) in front (because it's not using IIS), or switch your app service to linux, but really the simplest thing is just to switch to ZeroSSL or other CA. I think azure do certificates as well.
[Edit: also worth pointing out that there are only 2 years left of the android compatible chain before the intermediate expires]
Seems like a pretty strange and unfortunate behaviour by IIS
But it definitely seems like the way forward is to "just" use a certificate from another ACME-compatible CA: Automatic Certificate Management Environment
ACME service providers
Providers which support no-cost or low-cost ACME based certificate services include Let's Encrypt, Buypass Go SSL,[11] ZeroSSL[12] and SSL.com.[13] A number of other Certificate Authorities and software vendors provide ACME services as part of paid PKI solutions such as Entrust and DigiCert.
Now just to find a reliable, trustworth, and preferably free one
Here's a comparison of the currently available free ACME CAs.
The closest in features to what Let's Encrypt offers is probably ZeroSSL or Google. But both require setting up an account on their websites first and using External Account Binding (EAB) with your ACME client. The ZeroSSL site has a lot of verbiage that tries to imply there's a limit on free certs, but there's not as long as you use purely ACME. It's a bit easier to setup than Google's CA which requires creating a Google Cloud account and possibly associating a CC with it (not positive) even though the certs are free.
I think it depends on your definition of "a valid chain"
As Scott Helme writes in his blog post Working around expired Root Certificates, OpenSSL has not validated root certificates from the local trust store since 2009 - as it doesn't make sense.
IIS - and preferably Azure - should at least have a "manual override", to enable people-who-know-what-they-are-doing to solve problems like this
Again, it's a matter of opinion - the entity creating the root also set the expiry date, presumably expecting the expiry to be honoured. I agree it should be optional in windows (for services using TLS) - there are workarounds (like untrusting the self-signed ISRG Root X1) and there may be registry changes you can apply, but not in Azure.
Obviously clients would still use their own validation logic, and the 1.4 billion instances of Windows just don't trust that chain, but luckily most instances (but not all) know how to resolve the alternate chain automatically.
Another alternative is to proxy your app behind something else (like yarp or many other reverse proxies).
