EDIT 10/4/2007: Since this post has been published, we have updated the Exchange 2007 Autodiscover Service whitepaper to include this information. Please consult the whitepaper for most up-to-date information.
In reviewing all of the certificate data out there, Jim and I noticed that the information is fragmented into smaller topics and widely distributed. We wanted to supplement previous blog posts on this topic (this one and this one) with an overview of how Exchange 2007 uses certificates and a walk-though of how a typical small company might think about this topic.
Exchange is now using certificates for more than just web, POP3, or IMAP. In addition to securing web services, Exchange 2007 has also incorporated Transport Layer Security (TLS) for session based authentication and encryption. TLS has been around for a while but the Exchange 2007 implementation is able to mutually authenticate with external transport servers, internal servers and Outlook 2007 clients. TLS as implemented in Exchange 2007 is an effective alternative to S/MIME and is much easier to administer. 'Domain Security in Exchange 2007' is an excellent whitepaper on Exchange 2007 and TLS so we aren't going to reproduce it in this post, but we wanted to give mention to this new change and point everyone in a direction to read more on this topic. You can download it here:
http://technet.microsoft.com/en-us/library/bb266978.aspx
Since Exchange 2007 shipped, we in Support Services have been helping a lot of customers navigate the process of obtaining and installing certificates. The following scenario comprises the majority of our experiences:
Tom works for a company, Contoso Inc. Let's also say that Tom just put a default install of Exchange 2007 on a server called SERVER01 which makes its internal FQDN SERVER01.contoso.local since he also implemented split DNS. Tom wants to make sure he takes all of the correct steps in order for his External Outlook Anywhere 2007 clients to function correctly. He wants his users to be able to access OWA using https://mail.contoso.com. He has also read enough Microsoft documentation to know that the Outlook 2007 Auto-discover feature will attempt to find my auto-discover service at the following locations (in order from top to bottom):
Service Connection Point (SCP) – client communicates directly to AD
https://contoso.com
https://autodiscover.contoso.com
http://contoso.com
http://autodiscover.contoso.com
Tom doesn't want his users to get "invalid certificate" errors nor does he want to affect his clients with redirection requests.
Tom has just one more decision to make and then its implementation time. Does he go with the recommended solution of a certificate with Subject Alternative Names (SAN) – also known as Unified Communications Certificates or with individual certificates?
SAN Cert (Microsoft recommended solution)
Pro – Simple to administer on the server
Con – If you are purchasing the cert from a 3rd party it can be expensive (up to 10x more than a classic SSL cert)
Con – If you generate this cert with your internal MS certificate server, external clients/devices must be configured to trust this internal CA which may involve configuring many devices (Outlook clients, mobile devices, etc).
Con – not all CA's support this type of certificate. See this article for a list of CA's that do:
929395 Description of the Exchange-specific Web sites that are provided by X.509 certification authorities
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929395
Classic 3rd party SSL cert
Pro – inexpensive
Pro – most clients will trust the CA by default
Con – can complicates deployment on the server or require the use of an unfamiliar alias
The decision on this is your's (Tom's) hands so we'll cover both here:
The SAN cert method
You will need to contact a 3rd party CA that supports these types of certs (see link to KB929395 above)
Next, you need to know all of the Subject Alternative Names that you need to register. Here is the list that applies in Tom's scenario (for the '-domainname' parameter):
mail.contoso.com
contoso.com
contoso.local
autodiscover.contoso.com
Server01.contoso.local
Server01
Officially, the NetBIOS names of the server are not required. But many users and admins like to use OWA internally and this will prevent unnecessary warnings about the cert when they log on. There are no ill effects from adding internal names but they are not necessary.
This is the Exchange Management Shell (EMS) command Tom would enter to generate the cert request to be provided to the 3rd party CA in order to generate the actual certificate:
New-Exchangecertificate -domainname mail.contoso.com, contoso.com, contoso.local, autodiscover.contoso.com, server01.contoso.local, server01 -Friendlyname contosoinc -generaterequest:$true -keysize 1024 -path c:\certrequest.req -privatekeyexportable:$true –subjectname "c=US o=contoso inc, CN=server01.contoso.com"
We have found that the '–subjectname' option is the most confusing. The help contents in EMS are vague as well. The best description is found in the TLS whitepaper mentioned at the beginning of this post so we're not going to reproduce it here.
As we just stated, the above command will generate a certificate request file you can then submit to the CA of your choosing. Once they have processed your request and you have the cert, you need to install it onto your default web site. You don't install the certificate using the IIS Admin Console, you need to do it using the management shell.
First you have to import it:
Import-exchangecertificate –path <full path to cert file>
Then enable it:
Enable-exchangecertificate
When you run the above command you will be prompted to enter the name of the service you want to enable this certificate for. You can enable the cert for IIS, POP3, IMAP, SMTP, or UM depending on your circumstance. You can enable it for multiple services with the enable command by adding the following parameter:
-services IMAP, POP, UM, IIS, SMTP
After that it will prompt you for the thumbprint, so just copy and paste it from the results of the import procedure mentioned above. If for some reason you don't have the thumbprint in the same window you can get it by typing the following monad command:
Get-Exchangecertificate
You can also specify the thumbprint when you execute the 'enable-exchangecertificate' command by adding this parameter:
-thumbprint D75305BEF8175570EB6E03BA6FF4372D05ACE39F4
Combined it would look like this:
Enable-exchangecertificate –services IIS, UM, SMTP –thumbprint D75305BEF8175570EB6E03BA6FF4372D05ACE39F4
Make sure you copy the correct thumbprint if you have more than one. You can tell by running the 'get-exchangecertificate' PowerShell command and match up the subject with the correct thumbprint.
Next you need external DNS records that point to the IP address of your CAS server for any external name mapped to this certificate.
The other method
Jim and I are also hearing "These 3rd party companies want to charge me a lot of money for this SAN cert thing, is there another method?"
Why yes there are a couple of alternatives and here they are:
Alternative 1
Get a normal SSL certificate for the autodiscover namespace (autodiscover.contoso.com in the scenario). If you plan on using TLS you'll need to make sure to follow the instructions above but for subjectname you only need to specify the one namespace. The steps are no different to import and install at that point.
For this first example users will enter the following url for Outlook Anywhere or ActiveSync:
They would use this url to get to OWA:
Alternative 2
This alternative addresses users that may not be as open to learning a new URL for OWA, activesync, or other web services they may already have configured. Get 2 certs, one for mail.contoso.com and one for autodiscover.contoso.com. Mail.contoso.com cert goes on your default web site.
Next, create a new Web site from within IIS manager called AutoDiscover.
Right click, "Web Sites", choose "Web Site", make the description AutoDiscover, assign a new dedicated IP to this web site, use the default port of 80, don't enter a host header, for the Path, point to the same directory as your default web site
c:\inetpub\wwwroot
Also accept the default permissions.
Right click this web site, get properties, and go to Directory Security. Assign the autodiscover.contoso.com cert here.
From the Exchange Command Shell, run the following command:
New-AutodiscoverVirtualDirectory –WebSiteName AutoDiscover –BasicAuthentication $true –WindowsAuthentication $true
Note that the web site name parameter is case sensitive.
Go back to IIS manager, confirm the creation of your new AutoDiscover Virtual Directory. You can delete the autodiscover virtual directory from the default web site but it's not necessary and there is no additional risk by leaving it there. Finally, make sure external DNS have A or CNAME records for the following:
mail.contoso.com pointed to the external IP of Default Web Site
autodiscover.contoso.com pointed to the external IP of the AutoDiscover web site
Now that you have your cert installed, now what? Default certs issued by a MS certificate authority are valid for 2 years. The length of 3rd party certificate validity depends on your agreement with them. You can use the certificate manager addin for the local computer to renew these certs when the time comes or you can also repeat the steps above to get a new cert from another CA if you like. There are several ways to do this and the choice is yours to make as to how you accomplish the renewal.
Caveats
If you choose to install and use your own CA, you will have to ensure that clients, servers, and devices that access any secured site trust your CA as a root. This is actually a minor procedure but depending on the technical ability of your users or in large deployments it can become quite complicated.
Also, if you plan to incorporate an SSL accelerator or ISA server located in a DMZ you need to make sure that you export the private key of the certificate (pfx file). You can do this from the IIS administrator program once the certificate has been installed following the previous procedure.
Here are some links on that process:
299875 How to implement SSL in IIS
http://support.microsoft.com/default.aspx?scid=kb;EN-US;299875915840 How to install root certificates on a Windows Mobile-based device
http://support.microsoft.com/default.aspx?scid=kb;EN-US;915840297681 Error Message: This Security Certificate Was Issued by a Company that You Have Not Chosen to Trust
http://support.microsoft.com/default.aspx?scid=kb;EN-US;297681332077 IIS 6.0: Computer must trust all certification authorities trusted by individual sites
http://support.microsoft.com/default.aspx?scid=kb;EN-US;332077Certificates for Windows Mobile 5.0 and Windows Mobile 6
http://www.microsoft.com/technet/solutionaccelerators/mobile/maintain/SecModel/bd8cc6b6-0038-4e56-b1d4-b7b9af9ea6ef.mspx?mfr=true
