Forum Discussion
is the Microsoft Remote Connectivity Analyzer broken?
I am having issues configuring my autodiscover configuration after an exchange server rebuild (Single exchange server which failed and had to be rebuilt using the setup.exe /m:recover option) and it's not working.
I go across the the normally faithful connectivity analyzer and I get the following results:
Testing TCP port 443 on host <correct DNS for autodiscover> to ensure it's listening and open.
The port was opened successfully.
The port was opened successfully.
Testing the SSL certificate to make sure it's valid.The SSL certificate failed one or more certificate validation checks.
Test Steps
Test Steps
The Microsoft Connectivity Analyzer is probing the TCP endpoint <correct IP address> on port 443 to detect which SSL/TLS protocols and cipher suites are enabled.
We were able to detect the enabled protocols and cipher suites.
Additional Details
Checking that your server supports modern TLS protocols and cipher suites. Your server supports modern TLS protocols and cipher suites; it should be compatible with Microsoft 365 services.
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server <correct DNS name for autodiscover> on port 443.The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate.
Additional Details
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
Clearly its not a network error. So there is something wrong with my certificate? What could be wrong? It is a GoDaddy SAN cert.
- I set up my own autodiscover host and ran into the same issue. I managed to pinpoint the cause: it's caused by HTTP/2! When I disable HTTP/2 on my webserver (or rather my reverse proxy that is in front of the autodiscover host), it suddenly works. Enabling HTTP/2 once again breaks the test ("wasn't able to obtain the remote SSL certificate"). bradhugh
- I have just rebuilt my Exchange environment and needed to once again test Autodiscover to find out why it wasn't working. For anyone attempting to test autodiscover, I have found a free tool https://www.priasoft.com/autodiscover-testing-tool/ that successfully tests the autodiscover phase. Unfortunately, it doesn't help with a full end-to-end test as the Remote Connectivitiy Tool did but gets you part way there.
NOTE: I am not connected to Priasoft in any way, I just found this tool and it sorted me out. Seeing the same issue here now for a week or so (used to test fine). Exchange 2019/CU12 DAG behind an F5 load balancer.
Seems this issue is still there... I am getting it with a GlobalSign wildcard cert
- Same thing is happening today with our Sectigo Wildcard Cert.
- Hi Brent,
We are experiencing the same issue. We are running Exchange Server 2016 CU21 (15.1.2308.8) on our server. This happens on domains using the autodiscover.contoso.com method and using the DNS SRV method (other ones we dont use). Outlook connect just fine remotely. Before the test was fine. We use Sectigo (former Comodo) certificates. This is a full on-prem environment.
