I have a customer who has been using a neglected Exchange 2003 server for at least 10 years. I'm in the middle of a migration to Exchange 2010. Pretty much done, actually. The only thing left on my checklist is Activesync. My mobile device won't connect to the new server's Activesync unless it's on the internal WLAN. I'm suspecting that this is because name on the self-signed SSL cert doesn't match the external Activesync URL. Microsoft's testexchangeconnectivity tool seems to confirm this.
The 2003 server has been using an expired self-signed cert for about six years. Activesync worked; it just gave users a certificate warning during the initial connection, and they were forced to accept the cert. While researching my problem, I've found some sources that hint that Exchange 2007/2010 Activesync simply won't work with the default self-signed cert. Is this true? If so, does anyone know why? I'm just confused about why the server would check it's own SSL cert. I wouldn't expect the server to care about the self-signing or the name mismatch. As long as the clients are accepting the certificate, I figured Activesync would work.
I can probably convince the customer to get a UCC, but the AD domain is a .local one. I won't be able to include the internal hostnames as SANs on the UCC. This will likely cause certificate warnings for users on the LAN, which is something that I'd like to avoid. Unfortunately, I'm too far along in the Exchange migration to move AD to a new domain that can be included as a SAN. (I can revisit that option during the migration to Exchange 2013, but it's too late to do it now.) I suppose that the other option is to set up my own CA and create my cert... but then I'll have to install certs on every mobile device in the company.
