Handshake failure with Microsoft SSL Server Test

[HLFH]

Is it caused by Let's Encrypt expired root CA and a wrong SSL implementation on Microsoft's side?
Other example of issues with this expired root CA: transmission/transmission#1876 and this and that.
Theory: the SSL/TLS library used by Microsoft Remote Connectivity Analyzer has a TLS validation policy which will cause it to always fail if one of the intermediate paths fails, in our case the path using DST Root CA X3 because it is expired.

Microsoft Handshake failure with: https://testconnectivity.microsoft.com/tests/SslServer/input
Might be related to the root CA: https://stackoverflow.com/questions/6353849/received-fatal-alert-handshake-failure-through-sslhandshakeexception
The DST Root CA X3 expired in 09/2021: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/.
Microsoft Outlook Connectivity test requests a HTTPS address.

ssldump repo
Notes on ssldump ClientHello versions
Some ssldump review
Some TLS handshake failure guide

Solution: being added to the Production ECDSA allow-list takes time (at least one week) but that may solve the TLS handshake failure issue... This will make us switch to the ISRG Root X2 cross-signed by ISRG Root X1 when we renew ECDSA certificates which makes the chain of trust fine. But ECDSA ciphers are not supported by Microsoft.

[HLFH]

CPanel info:

The Autodiscover feature doesn’t work with email addresses that you add in the following mail clients:
Microsoft Outlook 2016
Microsoft Outlook 2019
Microsoft Outlook for Office 365
Any mobile mail client.

Some Plesk Obsidian threads with this one
Some Plesk FAQ

The famous Plesk Obsidian changelog says:

Mail Autodiscover is no longer supported for Microsoft Outlook 2019 and O365 versions. These mail clients use Microsoft proxy servers for autodiscover requests, and this configuration is not supported in Plesk.

The question is: are these web hosting control panels not working with Autodiscover because of:

1. SSL/TLS policy of Microsoft proxy servers ;
2. Expired Let's Encrypt Root CA DST Root CA X3 ;
3. Let's Encrypt is deployed on their servers.

Answer: Microsoft proxy servers only seem to communicate well with MS Exchange Servers, not third-party mail servers, regardless of the TLS setup.

Again, migrating to the ISRG Root X2 cross-signed by ISRG Root X1 would have been a step forward if ECDSA ciphers were supported by MS but it is not.

[HLFH]

Python 3.10 and above with increased security of TLS settings should not be an issue with Nginx as a reverse proxy: python/cpython#88164.

[HLFH]

I contacted the Microsoft Remove Connectivity Analyzer team. We'll see.
Linked to: https://learn.microsoft.com/en-us/connectivity-analyzer/ssl-certificate-trust-failure
Issue is:

the toll must trust the root Certificate Authority (CA) that issued the certificate. If the tool cannot follow the certificate chain to the trusted root, it displays an error indicating that the certificate is not trusted.

1. The root should not have expired ;
2. The certificates should be RSA ;
3. The ciphers should be RSA ciphers.

Let's Encrypt cannot provide that.
They either provide:

• an ECDSA root with ECDSA certificates & ciphers not supported by Microsoft ;
• a RSA intermediate cross-signed by a RSA root that has expired.

Tasks:

• Chase Microsoft RCA team by email ;
• Chase Microsoft RCA team on a support page ; EDIT: cancelled, no need, SSL/TLS setup solved.
• Chase Let's Encrypt team ;
• Migrate to another no-cost ACME CA for autodiscover domains such as ZeroSSL ; EDIT: cancelled because certbot works with the --preferred-chain parameter ;
• Test autodiscover requests with MS Exchange Servers > cancelled, duplicate of Support Autodiscover MS-OXDSCLI (21.0) #9

[HLFH]

Solved:

1. Use certbot --preferred-chain parameter to remove DST Root CA X3
2. Use RSA ciphers supported by MS > well, no, I prefer ECDSA, and it is not the main issue.

But I prefer not to use any more the MS SSL Server Test due to lack of support of ECDSA ciphers.