SEMblog

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?

1. Setup the DNS names that you need to use, both internally and externally.
2. Generate the request here: https://www.digicert.com/easy-csr/exchange2007.htm
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 http://certificatesforexchange.com/  )
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 http://www.powergui.org/ 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 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.
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 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.

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. https://www.testexchangeconnectivity.com/ 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 http://CertificatesForExchange.com) 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.

https://www.testexchangeconnectivity.com/

This is another post in my serious of articles on why you shouldn't use certain features in Exchange, even though they are there. As with the other articles, the article does NOT tell you how to enable the feature in question.

The other articles in this series to date are:

• why you shouldn't enable the POP3 Server (http://blog.sembee.co.uk/archive/2008/03/03/71.aspx)
• why you shouldn't use the POP3 connector (http://blog.sembee.co.uk/archive/2006/09/25/28.aspx)
• why you shouldn't use a self generated SSL certificate (http://blog.sembee.co.uk/archive/2006/03/05/9.aspx)
• why you shouldn't put Exchange 2003 in to a DMZ (http://blog.sembee.co.uk/archive/2006/02/23/7.aspx)

For this article I am going to outline why logos in an email signatures are a bad idea. This also applies to stationery as well.

Why would you use a logo?

Almost certainly the desire to use a logo in the signature will come from either upper management or marketing. They are proud of the logo and want to see it everywhere, and see email as an extension of the marketing exercise. Often it will come after a name change, merger or new look launched. However I also call it a "boredom idea" as it is usually suggested when someone is looking for idea during a meeting on how to improve the company visibility (or some such nonsense) and cannot think of anything original.

Why you shouldn't use a logo

Trying to argue against the use of a logo in email, particularly if the request has come from a senior figure in the company can be an uphill battle. However the reasons for it are sound.

1. Makes the message larger, therefore increase the size of your Exchange store and the recipient's store.
   Every recipient will get a copy of the logo, on every message. If your logo is 10k, then every message you send is at least 10k, even if it has "hello" on it, and nothing else. You send ten messages to a client, that is 100k. 10 messages a day every day (which is not unusual) then that is 700k a week, which quickly builds up. 
2. It can increase the likelihood of your message being flagged as spam, or as least suspicious.
   Everyone will have been plagued by the image spam. Therefore if your email contains an image embedded in the message, then it could get flagged.
   
   If you are looking to have the image stored remotely to avoid that and the increase in size, then that will not help either. The image could be flagged as a web bug and get the message flagged as spam.
3. You cannot control how the message will be displayed at the other end, or what the recipient is using.
   If you are downloading the logo from a web page, then you are presuming that the recipient has access to the internet when the message is viewed. They may not.
   
   The recipient could be using a PDA or collecting email over a low bandwidth connection. They will not appreciate the additional bulk of your message and the logo just to have someone say "Thanks".
   
   Once you start moving away from plain text formatting you also have the problem of display at the other end. You cannot guarantee how it will look at the end, even whether the image will remain embedded in the message or appear as an attachment. Different clients will use different ways to render the message format - ask any web developers about the problems they have with getting a web site to look the same in the various browsers in use. 
   
   Finally, to use a logo that means you have to use one of the rich formatted messages - HTML or rich text. Plain text is out of the question.
   
   If you force the use of the logo at the server using a third party tool then any recipient of email sent using plain text may well find that the message format will be changed.
4. Do large companies send emails with logos?
   The final point to put across is how many large companies do you see using a logo? The answer will be none. Where a logo is used it will be something the sender themselves has done, not something that is being done centrally. It is only ever small companies that do these sorts of things - and most managers do not want to be seen as a "small company".

Logos in signatures is something that you should try and avoid where possible for the health of the server, and to try and ensure that your email is not blocked or be unwelcome by the recipients.

I have blogged in the past about the Windows Mobile emulator, as I have found it an excellent tool when testing new solutions, looking at problems and generally getting to grips with the mobile side of Exchange. It also means that I can leave my own PDA alone rather than using it for testing.

Microsoft have now made available emulator images for Windows Mobile 6.1. While these are primarily designed for developers, they will run standalone with the Windows Mobile emulator.

For those of you using Exchange 2007 this release also gives you the opportunity to test out the new policies that were introduced with Exchange 2007 SP1 which bring the functionality of Windows Mobile closer to that of Blackberry , with control over the devices and the features that are enabled. (More information on those polices here: http://blogs.msdn.com/jasonlan/archive/2007/12/04/exchange-activesync-policies-summary.aspx)

Network Support

I tried to get these images to work on my Vista machine, using the now withdrawn network driver. However the network driver would not install on to the machine. Instead I had to download and install Virtual PC on to my machine (something that I was hoping to avoid).
On my Windows XP machine the network driver would install fine and worked well with these images.

Download Links

You need to download both parts, although if you already have the emulator installed then these new images will work with it fine.

Windows Mobile Emulator 3.0:
http://www.microsoft.com/downloads/details.aspx?familyid=A6F6ADAF-12E3-4B2F-A394-356E2C2FB114

Windows Mobile 6.1 Emulator Images Download:
http://www.microsoft.com/downloads/details.aspx?FamilyID=3d6f581e-c093-4b15-ab0c-a2ce5bffdb47

Windows Mobile 6.0 Emulator Images Download:
http://www.microsoft.com/downloads/details.aspx?familyid=38C46AA8-1DD7-426F-A913-4F370A65A582

Last year I wrote about how I was caught out with detecting Vista in login scripts (http://blog.sembee.co.uk/archive/2007/01/06/31.aspx).

Following the release of Service Pack 1 for Windows Vista, I was caught out again as the version number has changed. In my login scripts I use the output of the command "ver" to detect the operating system.

With Windows Vista RTM it was 6.0.6000. With Windows Vista SP1 it is 6.0.6001. Therefore any login scripts that detect Vista need to be updated to include both version types.

This is easily done and should not mean too much additional code.
If you have used the method in my examples and put the script commands in to sections, you simply need to add a line to the detect the later version:

findstr "6000" %systemdrive%\ver.txt
if not errorlevel 1 goto vista
findstr "6001" %systemdrive%\ver.txt
if not errorlevel 1 goto vista

:vista
rem vista commands here

By grouping them together the same commands can be used for both RTM and SP1 versions of Vista, unless you need to use different commands for the different versions.