Multiple Name SSL Certificate Request and Installation
Exchange 2007 is designed to be used with Unified Communications (also referred to as SAN (subject alternative name) or multiple domain certificate). This is different to a wild card certificate as it allows different domains to be used in the same certificate, such as example.com and example.co.uk.
A version of this article originally appeared on our director's blog.
September 2012: This information has changed significantly from the advice that has been given out since early 2007 with the release of Exchange 2007.
This is because the SSL vendors consortium has decided to stop issuing SSL certificates that expire after November 2015 to non FQDNs (eg server), non public host names (eg server.example.local) and to private IP addresses.
Therefore the names that you need to include are reduced.
Note: Our screenshots may still include the old naming convention until they can be updated.
However because of the way that SSL certificates are managed, this has caused some confusion for Exchange administrators, particularly those that have come from Exchange 2003, where it is simply done through IIS. In Exchange 2007, SSL is integrated in to the product.
When Exchange 2007 is installed, it will install a self signed certificate. This should be considered a place holder for a commercial trusted certificate. The self signed certificate that is installed is not supported for use with either Outlook Anywhere or Exchange ActiveSync.
Throughout this article the following domains are used as examples:
This is a public facing registered domain name
This is a private domain, or your internal domain name.
However if your public and internal domain name are one and the same, then this isn't a problem, it just means one less name on the certificate.
Read through this entire article before starting the process. It covers the steps required in some depth, along with a complete list of what to do in which order.
The URLs to use
The first thing to consider is what URLs to use. This has caused some confusion for Exchange administrators in the past.
The most straight forward scheme is to use the same names for as many services as possible. This reduces the confusion for the end users and limits the number of names you have to put in to the certificate.
Therefore you have four names:
This is the common name and appears in the SSL certificate. If it is used for the MX records then it will allow your server to accept TLS (aka SSL over SMTP) traffic inbound. Also use it for the address for OWA, IMAP, POP3, Exchange ActiveSync (EAS) and Outlook Anywhere. Set this name as your PTR (aka reverse DNS) on your external public IP address.
By having this name as the public face of your Exchange server, it will ensure that anything that doesn't support the additional names of the certificate can continue to work. A good example is RPC over HTTPS for Outlook 2003.
If the server is going to support more than one domain, where users have the domain as their primary email address, then that needs to be included as well. The autodiscover process simply tries to use autodiscover.example.com - where example.com is the domain after the @ sign in the email address.
If you are installing the certificate on an SBS 2008 system, then you should also include the host name "sites". Full instructions on setting up a commercial SSL certificate are here.
Names You do NOT have to include
You may also see recommendations that "example.com" (ie nothing in front of the domain) is also included in the list. This doesn't really achieve a great deal, as for most sites 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 - this is clearly shown by the number of adverts in media that do not feature the "www".
This isn't required as internal users will get their autodiscover information from the domain.
Once you have decided on the URLs to use, you need to configure DNS.
All of the external URLs (anything ending in example.com) will need to resolve internally as well. This allows the URls to work both internally and externally, but without any complex firewall changes to allow the external IP address to work internally.
The usual way to ensure the URLs resolve correctly is to configure a split DNS system.
The Certificate Request.
The certificate request is an Exchange Management Shell (EMS) command and can therefore be very complex to configure and get correct. However Digicert have created a web page that will create the command for you, which can be found here. Create the command and then copy and paste it in to a EMS window.
You do not have to use them for the SSL certificate itself.
Once the command has been run, it will generate a certificate request. You need to open that in notepad and copy and paste the complete request in to the window as per the instructions from the SSL certificate supplier. You will then get a response back to import.
The Certificate Import
Again another nice Microsoft article that can be shortened to something quite simple.
This is the command that you need to use to import the certificate response that you have received from your supplier:
You may have additional instructions from the supplier, such as root and intermediate certificate installation which should be completed before importing the certificate response.
URL Changes within 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 requires things to match. Therefore you have to ensure that the URLs are set correctly in the application for the virtual directories, connectors etc.
The Full To Do List for Certificates on Exchange 2007
After the explanations of what needs to be done, what is the full list?
- 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/ (use coupon code 50CN10 for 10% off the price of the multiple name certificate).
- When you get the response back, save the 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:
(where the certificate result is in C:\SSL and is called result.cer)
- Run get-exchangecertificate from the shell and you should see your new certificate listed. However you will notice that under "Services" it will be "....." . That is because the certificate is not enabled for any services.
- 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. This can take 20 minutes or so.
If you are installing the certificate on SBS 2008, do NOT proceed any further, but refer to the dedicated SBS 2008 instructions here.
- To enable the certificate, run the following command:
To get the thumb print, run get-exchangecertificate. It looks like a long series of random characters. Highlight the thumb print and then press enter to copy it.
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
- Adjust the External URLs in Exchange to match the name of the certificate that you have purchased - more details
In EMC, change: OWA virtual directory, EAS virtual Directory, Outlook Anywhere, OAB virtual directory
In EMS (where EXCH is the server's real name)
Unified Messaging (if installed)
These usually do not have to be changed because the FQDN value will match the server's real name and therefore that is included in the additional names of the certificate.
Again, no change required because any SSL certificate used for sending email comes from the remote server.
- 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.
Outlook 2003 RPC over HTTPS
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 Test Exchange Connectivity Site web site from Microsoft.