Recently, a customer called with ActiveSync issues. They had installed the certificate with the proper Subject and SAN entries on the Exchange server, but were unable to synchronize their Windows Phone 7 devices with Exchange 2010; iPhone and Android device encountered no issues.
A quick run of the Exchange Remote Connectivity Analyzer (ExRCA) showed the following:
As ExRCA discovered, not all certificates of the certificate chain were offered by the server. A quick inspection of the certificate showed the following certification path:
In this example, the certificate authority (CA), GlobalSign, uses an intermediate CA, GlobalSign Domain Validation CA – G2, to delegate the process of creating UC certificates. Consequence is that the certificate of the root CA, in this example GlobalSign, as well as the certificate of the intermediate CA, here , must be present on the device or should be offered when setting up the connection so the client can validate them.
Inspection of the Exchange server showed that the intermediate certificate was properly installed on the Exchange server, after the customer imported the Personal Information Exchange File (.pfx) file, provided by the CA as part of the certificate package, which contained all certificates in the chain: root CA, intermediate CA and the UC certificate.
Then, investigation moved to the reverse proxy, in this case ISA Server 2006 SP1. It turned out the intermediate certificate on the ISA server, or rather the lack of it, was causing the issue. The customer had imported the individual UC certificate on the ISA server. Because the ISA server didn’t contain the intermediate certificate, it couldn’t send it to the client as part of the certificate chain. After importing the intermediate certificate on the ISA server, ActiveSync started working.
Generally speaking, Windows Mobile or Windows Phone devices don’t contain intermediate certificates so be sure to install them on your Exchange servers as well as on your reverse proxies. Checking and validating intermediate certificates is a client thing and in this case the intermediate CA was available on the non-Windows Phone devices which explained the difference in behavior between Windows Phone, iPhone and Android devices.
Note that, depending on your situation, you may have never seen the above issue before. |This could be the case when you’ve been using certificates directly provided a root CA so far. When selecting your CA, this might be something to take into account as not all mobile devices behave identical as you’ve seen. Also, although lifetime of root and intermediate certificates is quite long, it is something you should manage properly in your environment as you have to an additional certifiate to watch (which might expire or be revoked). Also, depending on volume and mobile costs, sending down extra traffic through the wire/air could be something to take into account. If you don’t think this could be an issue because certificates are relatively small, there’s a reason Mini OWA’s so popular in some regions. Distributing certificates to clients might become a better alternative in those circumstances.
Finally, I want to recommend the excellent SSL Certificate Management & Troubleshooting Tool, provided by DigiCert. It cannot only indicate potential certificate issues like these, or wrongly imported certificates (e.g. user store instead of computer store), but also fix them. As an alternative to ExRCA, you could use the online SSLchecker provided here.
EighTwOne (821) 