Exchange 2007 SSL Certificate Setup

SSL certificates have become a standard in Exchange deployments. These allow you to encrypt the communication passing between the clients and your server environment. They can be used with OWA, Outlook Anywhere, ActiveSync and the Autodiscover Service.

In Exchange 2003, setting up SSL certificates was fairly simple and straight forward. You would simply request and deploy and certificate with your external FQDN (Fully Qualified Domain Name). If you wanted the same name to work inside your network, you would simply configure split DNS.

With the advent of Exchange 2007, things get a little more complicated. When you install Exchange 2007, the installation wizard creates a self generated SSL certificate for the default IIS website. This works fine for setup and testing, but once you move into production with external clients a commercial certificate is a must.

Removing the self generated installed with Exchange 2007 will initially work. For any Outlook 2003 clients you will probably not see any issues at all. Outlook 2007 clients will immediately start to see issues without the certificate installed.

Outlook 2007 supports the new web based method of Address Book distribution. Older versions of Outlook only used the public folder infrastructure in Exchange to support Address Books. With Exchange 2007 and Outlook 2007 Microsoft is moving toward their stated goal of removing Public Folders from Exchange.

Best practices for certificates are to use a generic external name. Your internal server name may be exchange.internal.local, while you use owa.external.com for your public facing name. Replacing the SSL certificate with ont that uses this generic external name will cause Outlook 2007 to generate certificate warnings when it connects to your server on the LAN. It expects the certificate to match the servers internal name.

To resolve this issue you need a certificate that supports hosting your external generic name (owa.external.com) and your internal name (exchange.internal.local) on the same certificate.

Add to this that the autodiscover service, which is new for Outlook 2007, connects to autodiscover.domain.com (autodiscover.external.com). This adds an additional name that your certificate must support.

Some of you may currently be using the same domain internally for Active Directory as you use externally. You may be thinking that just purchasing a wildcard certificate for *.domain.com would work. This will work if you do not plan on supporting Windows Mobile devices. Windows Mobile devices do not support wildcard certificates.

There are two potential solutions to the problems presented above. The first would be to purchase an SSL certificate that supports multiple names. These certificates can often cost in excess of $600. Paying this much money just for OWA seems excessive.

The second solution to this problem is much more economical and not very difficult to implement. You can use multiple websites to host the different functions in IIS that require differing names. This just requires purchasing separate low cost certificates for each name and then hosting the different services in different IIS sites.

Below are the steps necessary to implement this solution:

1. Setup Outlook Anywhere as normal (This is the one service that cannot have its virtual directory recreated using the Exchange Management Shell)
2. Add an additional internal IP address to your Exchange server’s network card that is in the same subnet as the primary address.
3. Modify the default IIS website so that the primary IP address is bound to the default website. You are changing is from “All unassigned” to a specific IP.
4. Create a new website in IIS. The name is not important. Use the same path as the default website when asked for the location (C:\Inetpub\wwwroot is the usual path). In the permissions dialog set the site to Read and Run Scripts only. You need to bind this site to the new IP address we added in step 2.
5. Using the Exchange Management Shell, run the following commands:

a. If you are hosting Exchange 2007 mailboxes only:

New-OWAVirtualDirectory -OwaVersion:Exchange2007 -Name "owa" -WebSite "External"

b. If you are also hosting Exchange 2003 mailboxes, run these additional commands:

New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exchange" -WebSite "External" -VirtualDirectoryType:Mailboxes

New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Public" -WebSite "External" -VirtualDirectoryType:PublicFolders

New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exadmin" -WebSite "External" -VirtualDirectoryType:Exadmin

New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exchweb" -WebSite "External" -VirtualDirectoryType:Exchweb

c. For ActiveSync, run the following command:

New-ActiveSyncVirtualDirectory -WebSiteName "External"

d. Refresh the display in the Exchange Management Console to now show two sets of virtual directories under Server Configuration, Client Access, Outlook Web Access and Exchange ActiveSync.

6. Adding Outlook Anywhere to the website is now a simple process:

a. In IIS Manager, under the default website locate the /rpc virtual directory and right click on it.

b. Select All Tasks from the menu and Save Configuration to File…

c. Save this configuration to a file location.

d. On the new website we created above, right click on the root and choose New, Virtual Directory (from file)…

e. Select the file you exported from the default website.

f. Important Note - any configuration changes to Outlook Anywhere after the export will not be reflected in the secondary website, so it is important that any configuration is done before the export/import. If you make any changes to the Outlook Anywhere configuration then the export/import will need to be repeated. Delete the imported virtual directory and replace it with a freshly exported configuration file.

7. After creating the virtual directories, you can apply the SSL certificate to the new website for the external name and point external users to that IP address. Leave the self generated certificate on the default website.

Autodiscover Service

There are two options for Autodiscover.

1. You can repeat the above process with a new dedicated website for autodiscover. The shell command to create a new virtual directory is
New-AutodiscoverVirtualDirectory -Websitename Autodiscover -BasicAuthentication:$true -WindowsAuthentication:$true

You can now apply a new certificate to this website. This works well for environments that have different email and web services domains. The autodiscover service uses the same domain as your email.

2. If you have multiple domains for email you need to use this redirect method.

You will add the Autodiscover virtual directory to the external website (New-AutodiscoverVirtualDirectory -Websitename External -BasicAuthentication:$true -WindowsAuthentication:$true) and then configure a redirect.

The redirection configuration is very important to ensure that it works correctly. The redirection method requires port 80 (http) traffic to come in. For internal traffic that is fine, but for external traffic you may want to look at a way of configuring the redirection using a public web site.

http://technet.microsoft.com/en-us/library/bb332063.aspx#Scenario4

In Conclusion, Exchange 2007 gives you much more granular control over the use of SSL than Exchange 2003. Most of the functionality is included natively in Exchange 2007 giving you the confidence that it will work as expected.