Exchange 2007, ActiveSync and SSL certificates

We're currently rebuilding our entire serverpark at work, and making the transition from Windows Server 2003 and Exchange 2003 over to Windows Server 2008 and Exchange 2007.

One of the features we want to implement is the ability to have secure communication between our mobilephones and Exchange. This means moving the traffic from port 80 over to port 443 using a SSL certificate.

After googling around we decided to purchase a SSL Certificate from GoDaddy.com. It's a horrible, horrible website, but the certificate is only 30$/year.

The experience of getting a Certificate, and installing it on the Exchange server is like poking a thorn in your eye. After combatting our way through the GoDaddy site we finally got our .crt file.

From the net we found out that we need to run PowerShell commands on our Exchange server to install the new certificate. At this point we used a while to understand that there is a difference between the PowerShell that is native to Windows Server 2008, and the PowerShell found in Start->Programs->Microsoft Exchange Server 2007->Exchange Management Shell.

In that shell we used the following commands:

Import-ExchangeCertificate -path C:\SSL\secure.oursite.no.crt

dir cert:\LocalMachine\My | fl

From the last command we copy the thumbprint to the clipboard, and use it in the next command.

Enable-ExchangeCertificate -thumbprint A3E7DCBF02A0DA34...removed...AB  -services "IIS,SMTP"

Also we made some changes in Exchange Management Console according to this article.

On our mobilephones we've changed the address to secure.oursite.no, and ticket on the SSL checkbox. The first time we sync the phone it asks if it's ok to use secure features, and after accepting it works just fine.

Edit:
After starting up the Outlook client we started getting warningmessages that the sertificate on the server did not not match the URL we used to access the server.

The problem was that the server was handing out the secure.oursite.no certificate, but out mail clients were connecting to the internal servername, exchange.geas.local. The problem was fixed by telling the Exchange server to use our external name instead.

We followed the approach described by John Webber in this forumthread.