[System.Net.WebException]: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. Inner error [System.Security.Authentication.AuthenticationException]: The remote certificate is invalid according to the validation procedure.
There is generally three causes for this problem:
1) Name mismatch - make sure the site name matches exactly as it is in the cert. If there is a "Subject Alternative Name" (SAN) on the details tab, then make sure the name is in that list (note: subject name must also be included in the SAN). Some applications don't supports SANs, but most do. Also note that site1 and site1.domain.com are not the same - this is the most common mistake.
2) Untrusted - you need to install the root certificate into the trusted root certificate store. If this app uses the Microsoft root store, you can check Certificates MMC to see if it shows up. If not, view the details of the certificate from the error box, go to the certification path tab and double click the topmost certificate, go to details tab and Copy to File button to export it, then from your saved copy you can import it to the trusted root store.
3) Expired or not yet valid - usually from the cert expiring - renew it. Can also happen if the time/time zone/date/year is off in the client OS - if this is ok, try also checking the same in BIOS.
Name mismatch is generally the one that catches people out. If you simply run Test-ActiveSyncConnectivity the Exchange 2010 server will not use a trusted URL on your SAN certificate. Make sure you specify the URL on the Test command for example:
Test-ActiveSyncConnectivity -URL "https://mail.contoso.com/Microsoft-Server-ActiveSync"
Check if the URL Re-write module is available in IIS on the CRM website and has the rule that rewrites the URL to handlers/FederationMetadata.ashx when FederationMetadata/2007-06/FederationMetadata.xml is requested.
ReplyDeleteerror503 , error21
Using Go Daddy Certificates?
ReplyDeleteWhen you look at the Go Daddy Certification Path of that certificate on the web server, do you see Go Daddy Class xxx or Starfield Class xxx ?
And from your non-legacy client i.e Windows Vista upwards, what does the Go Daddy Certification Path display? Go Daddy Class xxx or Starfield Class xxx ?
And these clients that get the warning, are they legacy clients? i.e WinXP and older?
Root Certificate updates works differently as of Windows Vista.
http://support.microsoft.com/kb/931125
Root certificates on Windows Vista and later are distributed via the automatic root update mechanism – that is, per root certificate. When a user visits a secure Web site (by using HTTPS SSL), reads a secure email (S/MIME), or downloads an ActiveX control that is signed (code signing) and encounters a new root certificate, the Windows certificate chain verification software checks Microsoft Update for the root certificate. If it finds it, it downloads the current Certificate Trust List (CTL) containing the list of all trusted root certificates in the Program, and verifies that the root certificate is listed there; it then downloads the specified root certificate to the system and installs it in the Windows Trusted Root Certification Authorities Store.
You'll probably find that your Go Daddy Certification Path on the web server thinks it's Starfield Class 2 instead of Go Daddy Class 2 so you installed the wrong root certificate. It caught me out as when you view in on the web server it doesn't display a root certificate warning, download and install the Do Daddy class 2 root cert and remove the Starfield one and your problem should dissapear.
nice one
ReplyDeleteI know this is old, but the GoDaddy vs Starfield still tripped me up. Ugh, changed to GoDaddy class and SBS is much happier.
ReplyDelete