ActiveSync, Intermediate Certificates and You

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:

Capture1 - Ano

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:

CertChain

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.

CertIntermediate

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.

Mac Outlook 2011 & Exchange 2003

There are still a lot of questions and tweets on Mac’s Outlook 2011, Exchange 2003 and why that combination doesn’t work. I can only assume people overlooked the system requirement in the Apple store, which clearly states “Exchange support in Outlook 2011 requires connectivity to Microsoft Exchange 2007 SP1 RU4 or later”.

The reason for lack of support lies in the fact that Outlook 2011 connects to Exchange Server using what is called Exchange Web Services. These services were introduced with Exchange 2007 (and thus are also available in Exchange 2010). The result is that Office 2011 can’t synchronize information, like e-mail, contacts and calendar, with Exchange 2003.

On a side note, you could use Entourage 2008 which utilizes the WebDAV protocol. This is supported by Exchange 2003 as well as 2007, but was discontinued in Exchange 2010.

Is this bad? I think not. Apart from the requirement, which is clearly mentioned, Exchange 2003 is almost 8 years old now. Products evolve and mainstream support has already ended for Exchange 2003. Even if Exchange 2003 is running rock solid, organizations should be considering on what to do with their Exchange 2003 environments as part of the IT life cycle management process.