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/multiplenamessl.asp
Back in January 2007, shortly after the release of Exchange 2007, I wrote an article on how to use single name SSL certificates with Exchange 2007. This was because at the time the preferred SAN/UC certificates were retailing at something like $400 a year.
The market has moved on and you can now pick up the UCC certificates from around $60/year (at the time of writing) from places such as http://certificatesforexchange.com/
Furthermore the process I wrote about in Jan 2007 doesn’t work on Windows 2008 and Outlook Anywhere is not supported outside of the default web site. Therefore its value has become less.
However administrators still seem to be having problems with SSL certificates. A lot of this comes down to the URLs being used. This blog post will try and clear up the confusion and guide you through a quick and easy process to get the certificates, without wanting to poke out your eyes with a spoon. *
The URLs to use.
The first question is the URLs to use. This seems to where a lot of admins are having problems.
The recommendation I make and use on all of my deployments is as follows:
mail.example.com (this is the common name, the name that your MX records point to will be used for OWA,IMAP/POP3/SMTP and Exchange ActiveSync - plus it is the reverse DNS record on your static IP address)
autodiscover.example.com (self explanatory)
server.example.local (this is the Exchange server's real internal name)
server (this is the Exchange server's NETBIOS name).
"mail.example.com" is the primary name so that it appears on the certificate if a user clicks on it, and ensures that anything external that is connecting to the server without support for SAN/UC certificates.
(SAN is Subject Alternative Name, UC is Unified Communications - they are basically the same thing).
The server name is used internally. If you have UM installed then UM will not use the certificate unless it has the server's real name in its SAN list.
I have seen some people also recommend that example.com (ie nothing in front of the domain) is also included in the list. That is not something I would recommend. In my opinion the root of the domain (example.com) should point to the public web site, not a private resource like OWA. Many people have stopped entering www in front of the domain - look at the number of adverts that do not feature it.
DNS Setup
The next common mistake that is being made is not getting the DNS setup correctly.
Ensure that your network is setup so that the above URLs all resolve INTERNALLY to the Exchange server's INTERNAL IP address. That will mean setting up a split DNS system. I will not go through that here, instead point you to here: http://www.amset.info/netadmin/split-dns.asp
The Certificate Request.
This is where most admins have a breakdown, as the command required is a real pig. Get one character wrong and you will not know until you try and request the certificate. The easy way is to use the wizard that the nice people at Digicert have posted: https://www.digicert.com/easy-csr/exchange2007.htm
You don't have to use them for the certificate, but the script it generates is good for all suppliers. They also have some good explanations on the SAN certificates.
The Certificate Import.
Again another nice Microsoft article that can be shortened to something quite simple.
http://technet.microsoft.com/en-us/library/bb124424.aspx
The command you need for a certificate when it arrives from a commercial supplier?
Import-ExchangeCertificate -Path c:\SSL\result.pfx
URL Changes to Exchange.
The last area that can cause a problem is getting the URLs correct.
Unlike Exchange 2003, where you could address the server by any name that you liked as long as it resolved, Exchange 2007 is a little more picky. Therefore you have to ensure that the URLs are set correctly in the application.
The Full To Do List.
After my waffle above, what do you need to do?
- Setup the DNS names that you need to use, both internally and externally.
- Generate the request here: https://www.digicert.com/easy-csr/exchange2007.htm
- Post the resulting script in to an Exchange Management Shell command.
- Use the Certificate Request file with your preferred SSL certificate supplier (such as http://certificatesforexchange.com/ )
- When you get the response back, save off the SSL file to the server. If you have used the above site to get the certificate, install the root and intermediate certificate as per the instructions that you have been supplied with.
- Use the EMS command to import the Certificate Result file:
Import-ExchangeCertificate -Path c:\SSL\result.pfx
(where the certificate result is in C:\SSL and is called result.pfx)
- Run get-exchangecertificate from the shell and you should see your new certificate listed. However you will notice that under "Services" it should be "….." . That is because the certificate is not enabled for any services.
Before you can enable the certificate, you need its thumb print. That will be shown in the output of the get-exchangecertificate command that you have already run. It looks like a long series of random characters. Highlight the thumb print and then press enter to copy it.
- Restart the Microsoft Exchange Transport Service if the server holds the Hub Transport role and run IISRESET if the server holds the Client Access Role. This will mean the certificate can be enabled immediately. If you cannot do either you will need to wait for Exchange to internally update before you can enable certificate.
- To enable the certificate, run the following command:
Enable-exchangecertificate -thumbprint xxxxxx -services SMTP,IIS,POP,IMAP
Run get-exchangecertificate again to confirm the certificate is enabled for the four services.
If you are using the UM role, then you should also add UM to the above list.
As an alternative, you can run the command for each service as a separate item
Enable-exchangecertificate -thumbprint xxxxxx -services SMTP
You can also use PowerGui http://www.powergui.org/ to enable the services for you. With PowerGui you need to do each service one at a time.
- Adjust the External URLs in Exchange to match the name of the certificate that you have purchased. You can also change the internal URLs as well (which is what I do) so that the same names work everywhere:
In EMC, change: OWA virtual directory, EAS virtual Directory, Outlook Anywhere, OAB virtual directory
In EMS (where EXCH is the server's real name)
Web Services
Set-WebServicesVirtualDirectory -identity "EXCH\EWS (Default Web Site)" -internalurl https://mail.example.com/EWS/Exchange.asmx -WindowsAuthentication:$True
Set-WebServicesVirtualDirectory -identity "EXCH\EWS (Default Web Site)" -externalurl https://mail.example.com/EWS/Exchange.asmx -WindowsAuthentication:$True
Unified Messaging (if installed)
Set-UMVirtualDirectory -identity "EXCH\UnifiedMessaging (Default Web Site)" -externalurl https://mail.example.com/UnifiedMessaging/Service.asmx -BasicAuthentication:$True
If I have missed a URL to change - please drop me a note at the business contact address. However I don't think I have missed any - there are a lot.
- Restart the Exchange services on all servers to allow the change to take effect. Outlook users, particularly those on Outlook Anywhere in Outlook 2007 should be asked to restart their session.
If you have changed the external name being used by RPC over HTTPS users on Outlook 2003 then they will have to change the configuration manually.
Once complete, test it using Outlook 2007. Hold down CTRL and right click on the Outlook icon in the system tray. Choose Test Autodiscover and run the tests to see what URLs are being issued.
For external testing, use the https://testexchangeconnectivity.com/ web site from Microsoft.
Hopefully this has explained what needs to be done to get SSL certificates configured correctly on your server, at a cost effective price and with little downtime.
Article Update Information
28th January 2009 - Since the change a few people have reported the certificate cannot be enabled. It would seem that certificate is not immediately available to Exchange after being installed. This wasn't a problem with the previous version of these instructions because most people would have to go and get PowerGui. Therefore I have added a step to ensure the certificate is available immediately.
26th January 2009 - I have updated the article slightly to include the enable certificate commands, rather than use PowerGui. This provides a complete method without installing anything extra on to your server.
Related Posts (added Jan 2009)
Unified Messaging Requires the Server Name in the SSL Certificate
http://blog.sembee.co.uk/archive/2008/06/02/79.aspx
Exchange 2007 with a Single Name SSL Certificate - if you must
http://blog.sembee.co.uk/archive/2008/06/09/80.aspx
More on SSL Certificates with Exchange 2007 - includes details on what is supported
http://blog.sembee.co.uk/archive/2008/10/16/87.aspx
* Credit to fellow Exchange MVP Lee Mackay for that colourful phrase.
