SEMblog

30th May 2008
There is a new post elsewhere on this blog that I believe makes this post redudant. As SAN/UC certificates have come down in price it makes more sense to use those rather than the method I have outlined below. Furthermore this process does not work on Windows 2008 and Microsoft do not support Outlook Anywhere outside of the default web site.
To see the updated blog posting click here: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx 

I will leave this post here for reference, but I suggest that you deploy a SAN/UC certificate using the guide I have written above.

1st October 2007
I am aware that at least one SSL vendor is sending some customers to this blog posting when asked about deploying their certificates with Exchange 2007. If you have been sent here by a vendor, then you should ask them why they are sending you to a blog rather than assisting you with resolving the problem.

Remember that this is one solution to the problem, and it is not a solution that Microsoft recommend. I have found that it works, but that does not mean it is the ONLY solution.

As of the time of writing this section (1st October 2007) it is still the way that I deploy Exchange 2007 and have found that it works. I constantly review my techniques and will change the article if I believe there is a better way.

If you care about network security, you will want to use SSL certificates with your Exchange deployment. SSL certificates could be used with OWA, Outlook Anywhere, ActiveSync and the Autodiscover Service.
However as you will quickly find, SSL Certificates for use with Exchange 2007 is a mess.

When Exchange 2007 is initially installed, the installation wizard creates a self generated SSL certificate for the default web site. While this is fine for initial use, you will quickly want to replace it with a commercial certificate to avoid certificate warnings when users browse to the OWA site and to avoid complications deploying Windows Mobile handhelds.

(I have discussed the reasons to use a commercial SSL certificate on my blog last year: http://blog.sembee.co.uk/archive/2006/03/05/Self-Generated-versus-Commercial-SSL-Certificates.aspx).

With Exchange 2003 it was quite simple to deploy a commercial certificate, simply request and deploy a certificate with your chosen external name. If you wanted the same name to work inside, then you would also configure split DNS (http://www.amset.info/netadmin/split-dns.asp).

If you remove the default certificate with Exchange 2007, it will initially appear to work. If your clients are on Outlook 2003, then most things will work correctly.

However when you introduce Outlook 2007, the complications start.

Outlook 2007 is the first client to support the new web based method of Address Book distribution. Previous versions of Outlook used system folders, part of the public folder structure. Microsoft have made no secret of their desire to kill off public folders and the change in address book distribution is a key step towards that goal.

If you replace the SSL certificate with a certificate that does not match the server's real name, then Outlook 2007 generates a certificate warning when it connects to your server on the LAN. It is expecting the SSL certificate to be on the server's real name.
However best practise for certificates is to use a generic name. You may also be in a position where the server's real name ends in .local.

Therefore you need a certificate that supports the additional name.

On a side issue - you will note that Outlook does not generate a warning message on your self generated certificate, which will not be trusted by the client. It has been confirmed that Outlook does not check the trust status when connecting to Exchange on the internal network.

Then you get the complication of the autodiscover service, which is new for Outlook 2007. That connects to autodiscover.domain.com (where domain.com is the domain name in your email address). Therefore your SSL certificate on host.domain.com will not be accepted because it doesn't match the address being accessed.

If you are fortunate enough to be using the same domain name for your AD domain, as your primary email domain, which is also accessible from outside (domain.com), then you might be thinking at this point to purchase a wildcard certificate - so that *.domain.com would work.
That would be fine, but if you want to support Windows Mobile devices, then you will need to think again, as Windows Mobile does not support wildcard SSL certificates.

Therefore what is the solution?

You could look to purchase an SSL certificate that supports the additional names. However none of the cheap SSL certificate providers (RapidSSL and GoDaddy) issue certificates that allow you to have the additional names. The only certificate that I have found that does is one of the US$600 certificates from Geotrust. Having to pay $600 for a certificate just to secure OWA seems very expensive and is not something that many sites will accept.

Therefore the resolution to this problem I have found is to use multiple web sites.

This isn't as hard as it may sound and I will give you the brief steps here. (More comprehensive instructions will appear on the amset.info web site at some point in the future).

1. Setup Outlook Anywhere as required. This is important as it is the one feature that cannot have its virtual directory recreated using the Exchange Management Shell.
   
2. Add an additional internal IP addresses to your Exchange server's network card. For example, if 192.168.1.1 was the default address for the server, you would add 192.168.1.2 as an additional address. It does not have to be the next address, just as long as it is on the same subnet (192.168.1.x)
   You need additional IP addresses as you cannot use host headers with SSL.
   
3. Adjust the configuration of IIS so that the default IP address is bound to the default web site. This is a change from the "All unassigned" setting.
   
4. Create a new web site in IIS Manager. In this example I will call it External. Set it to use the additional IP address, using the default ports. When asked for the path, use the same as the default (C:\Inetpub\wwwroot). When asked for permissions, select Read and Run Scripts only.
   
5. Open the Exchange Management Shell and run the following commands:
   If you are supporting Exchange 2007 Mailboxes ONLY:
   
   New-OWAVirtualDirectory -OwaVersion:Exchange2007 -Name "owa" -WebSite "External"
   
   If you are also supporting Exchange 2003 mailboxes, then you need to 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
   
   For ActiveSync, run the following command:
   
   New-ActiveSyncVirtualDirectory -WebSiteName "External"
   
   When you refresh the configuration in Exchange Management Console, you should see two sets of virtual directories under Server Configuration, Client Access, Outlook Web Access and Exchange ActiveSync.
   
6. To add Outlook Anywhere to the web site, open up IIS Manager. In the default web site, find the /rpc virtual directory. Right click on it and choose All Tasks, Save Configuration to a File… and save the configuration.
   Then on the new web site that you have just created, right click on the root and choose New, Virtual Directory (from file)…
   When prompted select the file that you exported from the default web site.
   
   Important note - any configuration changes to Outlook Anywhere do not appear to be reflected in this exported file, 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. Once you have created the virtual directories, you can then put an SSL certificate on to the new web site and then point external traffic to that address.
   Internal traffic can also be pointed to the new web site.
   Leave the self generated certificate on the default web site, as Outlook 2007 will continue to connect to it.

Autodiscover Service

For Autodiscover, you actually have two options.

1. Repeat the above process, with a new dedicated web site for autodiscover.
   The command for a new Autodiscover virtual directory is
   
   New-AutodiscoverVirtualDirectory -Websitename Autodiscover -BasicAuthentication:$true -WindowsAuthentication:$true
   
   That web site can then get its own SSL certificate.
   This could be useful if you use two different domains, one for email and one for external facing web services. Autodiscover uses the same domain as your email.
   However if you have multiple domains for email, you will need to use the redirect method.
   
2. Add to the external web site and configure a redirect.

To add the Autodiscover virtual directory to the External web site created in above:

New-AutodiscoverVirtualDirectory -Websitename External -BasicAuthentication:$true -WindowsAuthentication:$true

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.

At the time of writing, this is Microsoft's article on redirection. It is covered under the section Hosted Environments and the Autodiscover Service, but would also be useful if you have more than one domain, or you use a different domain for email than you do for external facing web services.

http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/4172728f-bb70-4579-9d5d-fccdd4afcd80.mspx?mfr=true

Conclusion

Your control over the web services of Exchange 2007 provides you with many more options for using SSL than Exchange 2003. Unlike Exchange 2003, with the exception of Outlook Anywhere, these options are provided as part of the product, allowing you to use them with the confidence that they should work as expected and can be managed with other features of Exchange.