SSL certificates with Exchange 2007 continue to be a reoccurring question on forums, and I have recently had some common points continue to come up.
If you are looking for my guide on SSL certificate requests for Exchange 2007 then it is here: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx
The Self Signed Certificate
As Exchange starts to mature, and installations have been in place for over 12 months, the question of renewing the self signed certificate comes up.
What these people do not seem to realise is that they shouldn't even be using the self signed certificate. It is designed for interim use only and should be replaced with a commercial SAN/UC certificate as soon as possible.
This is Microsoft's official stance on the use of the self signed certificate: http://technet.microsoft.com/en-us/library/bb851554(EXCHG.80).aspx
One of the key lines is this:
"Important: The self-signed certificate is not supported for use with Outlook Anywhere or Exchange ActiveSync. "
Therefore if you are using either of those features with a self signed certificate you are actually in an unsupported environment.
The fact that getting the certificate to work for those two features can be tricky at the best of times, makes it even more pointless to continue to try and use self signed certificates.
The main argument for not using a commercial certificate is the cost and the perceived complexity of the certificate acquisition. When Exchange 2007 was first released the first UC/SAN certificates were expensive. However with vendors releasing low cost certificates for US$60/year (http://DomainsForExchange.net/ for example) that has now changed.
As for the perception of complexity for the purchase, I outlined what required in a previous blog posting: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx
SAN/UC Certificates and Outlook Anywhere
The other thing that appears to be catching people out is when using Outlook Anywhere (aka RPC over HTTPS) with SAN/UC certificates.
When you setting up Outlook Anywhere in the client, if you choose to enable the "mutual authentication" option then you cannot use one of the alternative names on the certificate - you must use the primary common name. For most people this shouldn't be a problem, particularly if you follow the recommendation to put the most common name that will be used (the URL used for OWA) in as the common name and the other URLs (auto discover, the server's FQDN and real name) as additional names.
However if you have used SAN/UC certificates to support multiple domains on the same server, then it could cause you a problem.
The answer of course is to disable that option. Outlook Anywhere will continue to work correctly without that option enabled, although users may get authentication prompts. The most likely scenario where you would disable that option is when hosting, so the clients are likely to be off your domain anyway.
SAN/UC Certificates and POP3/SMTP/TLS
Similar to the issue above, to ensure maximum compatibility, the primary name on your certificate should also match your MX record. Therefore what I am recommending is the same URL is used for OWA, Outlook Anywhere and the MX records - usually mail.example.net
Certificate Prompts where the Certificate is Issued to Another Domain Entirely
Another issue I have seen a few reports of is Outlook 2007 generating a certificate prompt, and when you look at the certificate it is issued to someone else.
The cause of this is a combination of a missing URL and a wildcard on your DNS.
If you have not configured a split DNS system on your public domain for internal use, then Outlook 2007 will attempt to connect to autodiscover.example.com as part of its startup process. If you have a wildcard DNS entry on your public DNS (so *.example.com resolves) which resolves to your public web server, AND you do not have autodiscover.example.com defined, then you may get the prompt if your public web server has an SSL certificate protected site on it.
Always define autodiscover.example.com and preferably setup a split DNS system so that you can point autodiscover.example.com to your Exchange server. http://www.amset.info/netadmin/split-dns.asp
Certificates when Using Unified Messaging
You can also run in to problems when you are using Unified Messaging. I have blogged on that subject before: http://blog.sembee.co.uk/archive/2008/06/02/79.aspx
