This week, while helping a customer onboard to Azure AD Connect, we ran into an interesting error:

Azure Service Connectivity Failed, Unable to proceed
The on-premises synchronization service is not able to connect to Azure Active Directory. Updating the proxy settings for the ADSync service account may resolve this issue.
Extended Message: System.Net.WebException: The underlying connect was closed: Cloud not establish trust relationship for the SSL/TLS secure channel. –> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

What to do, what to do, what to do?

Background

After receiving this error, my immediate reaction was to respond to the error and suggestion presented: Updating the proxy settings for the ADSync service account may resolve this issue.  Many of my customers use some sort of proxy or security appliance between their server environment and the internet.  We have many suggestions and recommendations, such as “bypass the proxy for Office 365 services” and, if that isn’t possible, set the machine proxy using Netsh.

Diagnostics

In this case, I recommended the customer download my troubleshooting/diagnostic tool at http://aka.ms/aadnetwork and send the log over.  Both fortunately (and unfortunately, from the troubleshooting perspective), the report was green checkmarks all the way down (or, in the case of a TXT file, [success] messages).  What next?

Resolution

At first, my shoot-from-the-hip answer was the server can’t verify the issuer’s certificate revocation list.  As per the x.509 RFC, a CRL is used to verify that a device, service, or application certificate is still valid.  To perform this check, a client queries the a service’s certificate issuer’s revocation list on port 80 and looks for the certificate that was presented to it.  Among other data, the CRL lists the certificate’s common name and it’s validity dates.  If the certificate is no longer valid (say, it was revoked because the key was compromised or the service is no longer in use), the CRL will return a status indicated that the certificate is no longer valid.  If the certificate passes the validity test, the client can proceed with its transaction.

I have several customers that have blocked outbound access on port 80 from server environments, which prevents CRL lookups from performing normally.  In this case, the result from the AAD Network test tool verified that the server could reach the necessary CRLs on port 80.

After reviewing the customer’s AAD Connect installation log, I located the last web service call invoked during the error:

Tracking back to the previous error message, I noticed the item:

Could not establish trust relationship for the SL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

I browsed to the site and then checked the SSL/TLS properties of the page.  I asked the customer to verify that the certificate issuer for https://adminwebservice.microsoftonline.com (DigiCert) was in the server’s trusted root certification store. The certificate chain is as follows:

The customer reported that it was not.  After the customer installed the certificate, installation was able to complete successfully.

The political maxim may say “Trust, but verify,” but TLS says “Verify, then trust.”