21st April 2011
An Updated and revised version of this article can be found on our main site here: http://exchange.sembee.info/2007/install/sbs2008ssl.asp
In recent months I seem to have spent longer with SBS deployments, rather than Exchange 2007 or 2010. Therefore I have had lots of time to get annoyed with how SBS 2008 works with SSL certificates.
Exchange 2007 is very dependant on SSL certificates, which is something I have posted about in the past. However throw in the customisations to IIS that SBS 2008 makes and it gets much harder.
The SBS team have attempted to simplify the process, but for most people they have actually made it worse.
The major problem with SBS 2008 and SSL certificates is twofold.
1. SBS 2008 presumes that your external DNS provider supports SRV records. Their DNS partners that are pushed in the wizard do of course, but most do not.
SRV records are one of the methods that Outlook 2007 can use for autodiscover. Autodiscover is connected to the availability service. Therefore that means if you are using Outlook Anywhere, without autodiscover working correctly, the client doesn't work.
It can also cause problems internally, but the wizard does actually make the required changes for that.
I can see why the SBS team used the SRV record method, as it allows a standard single name SSL certificate to be used - usually remote.example.com . The wizard then makes the requires changes to Exchange and the domain to allow this method to work correctly. Using a single name SSL certificate keeps the costs down, as anyone who has worked with SBS user will know - getting the typical customer to pay for a certificate can be difficult, particularly when there is a "free" certificate in the product.
The comments in this article from Sean Daniel clearly show the presumption of SRV records use. In my opinion this is a very poor decision from Microsoft, when the wizard could easily automatically enter the additional names that are required and generate the relevant request.
http://sbs.seandaniel.com/2009/02/installing-godaddy-standard-ssl.html
2. The second issue is that SBS 2008 sets up additional web sites and uses them for external traffic. If you install and enable the certificate in the usual way for Exchange 2007, then you break those sites. That causes a mess, which can be resolved, does make extra work.
However, it is possible to get the certificate in place, in a way that is acceptable to both Exchange 2007 and SBS 2008. Whatever you do, DO NOT use IIS to generate and manipulate the certificate.
Preparation Work
To ensure that you work with the common configuration for SBS 2008, some DNS entries need to be made on the internet facing DNS services (usually your DNS provider).
Specifically these are
remote.example.com and autodiscover.example.com
(where example.com is your domain after the @).
These should point to your public static external IP address. If you cannot use a static IP address, then use a dynamic DNS provider to setup a host. Then create a CNAME for each of the above hosts and point them to then dynamic DNS host name.
While you can use another host name instead of remote.example.com, but everything in SBS seems to be orientated towards that name. Therefore I usually also use that host name for the MX records for the server as well, and get the ISP to setup the reverse DNS (aka PTR) record.
Certificate Request Generation and Response Installation
To generate the request, follow my guide elsewhere on this blog: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx
However, add the name "Sites" to the list of domains that you include. That makes the full list:
remote.example.com
autodiscover.example.com
server.domain.local (the server's internal FQDN)
server (the server's NETBIOS name)
sites
When you get the response back from your provider, continue to follow my blog article up to the point about installing the response. DO NOT use the enable-exchangecertificate command.
By using the Exchange Management Shell to do the request you do not put the current self generated certificate at risk, because the request and response doesn't touch it. The certificate is only changed later on in the process.
Activating the Certificate
Now this is where things get different to Exchange 2007 full product installation.
In the SBS Management Console, start the SSL certificate. Select the option to use an existing certificate. Your new UCC certificate with the additional names should be listed. Select it and then complete the wizard. SBS will install the certificate in to the web sites correctly for you.
You should then be able to browse to https ://remote.example.com/remote and use the full feature set.
You can verify the certificate is installed correctly by using the Fix my Network wizard, which shouldn't touch the certificate installation - or by running the SBS Best Practises tool. The link to that is on my list of Exchange resources at http://exbpa.com/
Conclusion
With care, you can deploy a commercial certificate on to SBS server, without breaking any of the functionality of the server. This provides a more professional looking deployment for everyone involved, and no need to tell users to ignore certificate prompts.
