is the Microsoft Remote Connectivity Analyzer broken?

[BrentStobbs]

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.

Testing the SSL certificate to make sure it's valid.The SSL certificate failed one or more certificate validation checks.

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.

[#2]

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.

[#3]

@BasL86 Thanks for this feedback. We're investigating the problem.

[#4]

Hello, any update on this issue? I am doing some autodiscover testing for my exchange 2013 server on-prem, and seem to be getting the same issue.

[#5]

@mohsan466 - yes, sorry for the delay. We released a new deployment which seems to have resolved the issue. If you are still having problems, send mail using the feedback link in the footer of the site with your specific issue and someone can take a look.

[#6]

@bradhugh Hi Brad, the update seems to have solved our issues. Thank you! Great tool!

[#7]

@bradhugh I can't agree with @BasL86 the Remote Connectivity Analyzer shows with Sectico Certificate still the Same result and issue that 

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.

[#8]

@gabrielsix - Our telemetry has shown a drastic drop of this error after our latest deployment. Can you send me a private message with your URL (assuming it's accessible from the internet)? I can try to see if I can figure out what's going wrong.

[#9]

Hello, I am having the same issue with a Digicert certificate

[#10]

Same thing is happening today with our Sectigo Wildcard Cert.

[#11]

hi@BrentStobbs 

Seems this issue is still there... I am getting it with a GlobalSign wildcard cert 

[#12]

I'm currently seeing this with a Network Solutions cert. Qualys gives the server an A rating, Can I PM you the URL?

[#13]

This is still an issue for me. Since the error message suggests that the cert could not be obtained (as opposed to: could not be validated), the issuing CA should be irrelevant, but as others mentioned theirs: We are using LetsEncrypt certs. The server is also behind a reverse proxy, but that should not play a role either until a specific URL is requested (hence *after* TLS negotiation)

[#14]

@bradleysp - sure, PM me the URL I can try to see what's up. We know one scenario is that certain firewalls block TLS scanners and these catch ours where they may not catch the Qualys scanner. Otherwise, this is fixed for the vast majority of folks.

[#15]

@bradhugh 

Hola, tengo el mismo error, y estamos utilizando Exchange server 2016 CU21, y sobre los servidores para el balanceo de peticiones tenemos un f5, y nos genera el error mencionado.

[#16]

Seeing the same issue here now for a week or so (used to test fine). Exchange 2019/CU12 DAG behind an F5 load balancer.

[#17]

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.

[#18]

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