Microsoft Exchange and Blackberry Server Specialists


Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Exchange 2007 and SSL Certificates - Take 2

21st April 2011

An Updated and revised version of this article can be found on our main site here:

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
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: (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) (self explanatory)
server.example.local (this is the Exchange server's real internal name)
server (this is the Exchange server's NETBIOS name).

"" 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 (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 ( 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:

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:
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.
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?

  1. Setup the DNS names that you need to use, both internally and externally.
  2. Generate the request here:
  3. Post the resulting script in to an Exchange Management Shell command.
  4. Use the Certificate Request file with your preferred SSL certificate supplier (such as  )
  5. 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.
  6. 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)
  7. 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.
  8. 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.
  9. 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 to enable the services for you. With PowerGui you need to do each service one at a time.
  10. 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 -WindowsAuthentication:$True

    Set-WebServicesVirtualDirectory -identity "EXCH\EWS (Default Web Site)" -externalurl -WindowsAuthentication:$True

    Unified Messaging (if installed)

    Set-UMVirtualDirectory -identity "EXCH\UnifiedMessaging (Default Web Site)" -externalurl  -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.
  11. 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 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

Exchange 2007 with a Single Name SSL Certificate - if you must

More on SSL Certificates with Exchange 2007 - includes details on what is supported

* Credit to fellow Exchange MVP Lee Mackay for that colourful phrase.

New Online Testing Tool from the Microsoft Exchange team

So you have setup your Exchange 2007 server and now wonder whether it works correctly.
The DNS changes are in place, the SSL certificate works, but how do you test it?

Or your server isn't working correct and you want to test it from an external host - but how can you do that quickly and easily?

A new tool from the Microsoft Exchange team, currently in prototype/development may well be something to help you. can currently test Autodiscover, Outlook Anywhere (which should work for Exchange 2003 and Exchange 2007), ActiveSync and inbound SMTP.
Inbound SMTP can obviously be used to test any server.

For the tests that require accounts, I would suggest configuring a test account which can be disposed of later, although Microsoft do state (on the "Is this secure" link) "

Passwords gathered using this tool are not stored by the server.  Passwords are encrypted in memory inside of the user's browser using a key only known to this server.  When passwords are transmitted to the server, they are encrypted using the server key and only transmitted to the server over a Secure Sockets Layer (SSL) connection.  As always however, it is recommend that you use a disposable test account for any testing done over the Internet."

The tool runs over SSL (using the same type of certificates available from so you should be able to use it from the Exchange server itself.
It does require the relevant ports to be open and information in the public DNS records, so no use for test environments that are not exposed to the internet and anything that is exposed will have to be secure. However for the final test before going live it is ideal.