There are many reasons why now is the right time to make the move to Microsoft Exchange Server 2010, including a host of administration and security improvements. However, as with Microsoft Exchange Server 2007, Exchange 2010 requires SSL certificates to ensure the security of all connections to the email server. This guide from Thawte is designed to take the guesswork out of implementing SSL for Exchange 2010, making it easier than ever to get the SSL certificate you need for a successful and secure Exchange implementation, and to take advantage of powerful capabilities such as Subject Alternative Names (SANs).
An SSL certificate is a bit of code that provides security for online communications. When a web browser contacts your secured web site or application server, they use the SSL certificate to enable an encrypted connection. It’s kind of like sealing a letter in an envelope before sending it through the mail. SSL certificates also inspire trust because each SSL certificate contains identification information. When you request an SSL certificate, a third party (such as Thawte) verifies your organization’s information and issues a unique certificate to you incorporating that information. This is known as the authentication process.
There are three types of SSL certificates you can use to secure your Exchange infrastructure: self-signed that you create yourself; Windows Public Key Infrastructure (PKI) certificates; and certificates from trusted, independent Certificate Authorities (sometimes referred to as Public Certificates). Microsoft recommends that you use an SSL certificate from a trusted, independent third-party certification authority (CA) before
putting a new email server into production1. If you use a certificate from a well-established CA, you can a void the
hassles of installing your own root certificate on every client that will access your Exchange server. (Your help desk will thank you for this since they will be fielding configuration requests every time a new mobile or browser client tries to connect)2. Also be aware that the Outlook Anywhere protocol will not work with
Before you purchase and install your SSL certificates, you must identify the fully qualified domain name (FQDN, sometimes referred to as the URL or common name) for your server, and add this name to the Trusted Server list in Active Directory. Your FQDN would look something like this: mail.yourserver.com
You will need more than a single FQDN for your server. Your server will likely be responsible for multiple services, and you will need to identify every possible name that may be used by another server or client when pointing to your Exchange server. Keeping your Exchange common names in FQDN format is a good idea, but be aware that there are a few limitations. Common names can be no longer than 64 characters, and if your FQDN naming schema runs long, you will not be able to fit your full FQDN into the common name standard. Common names support Unicode, whereas an FQDN is limited to a subset of ASCII characters. That said, if you can use your FQDN as your common name, it may make your ultimate configuration easier.
There are a few instances where you must use the FQDN as the common name – such as when you secure an Edge Transport server that performs Simple Mail Transfer Protocol SSL (SMTPS) over the Internet. In this case, you must use the same FQDN as is published in that server’s “A” record on the public Internet DNS server. If using the FQDN is not possible or not desired, many administrators use the shorter domain name form of the FQDN for their common names. Here is a sample set of common names that might be associated with a single Exchange server:
You will need to secure and authenticate each of your common names with SSL because any device needing to point to your server will need to use exactly these same names. Many IT professionals have dealt with problem scenarios where their Exchange implementation wasn’t working due to misunderstandings about the server common name. Creating a solid naming schema for your Exchange environment will help you to avoid many major problems down the road.
Each of your common names needs to be authenticated by SSL, but it would be unnecessarily cumbersome and costly if you actually had to purchase and install a separa te SSL certificate for each of your common names. Don’t worry ─ there is a much easier method.
The solution to securing multiple common names for a single server, such as is necessary for an Exchange server, is getting a certificate with multiple SANs (subject alternative names). The SAN field extension in an SSL certificate has been part of the SSL certificate standard for more than a decade. This SAN-enabled certificate works just like a regular SSL certificate in nearly every way. It offers the same level of encryption and authentication; the only difference is that it protects multiple common names with a single SSL certificate. The SAN field extension is very flexible and works with virtually all browsers
and mobile devices. By using the SAN field extension you
can use a single certificate to protect different domains,
IP addresses, server names and more – perfect for securing
your Exchange server.
Use the “Certificate Principal Name” configured for your Outlook Anywhere connection in the Outlook profile as the Subject Name in your SSL certificate. Include the Fully Qualified Internet Domain Name (FQDN) for your server as a common name in your certificate. Also note that the autodiscover service (if you use it) must be listed as a SAN – autodiscover.yourserver.com. All the common names for the various services you use with your Exchange implementation must be listed in your SAN. The most typical services used are Outlook Web App (OWA), ActiveSync, and Outlook Anywhere. If you have deployed one or more Client Access Servers (CAS) you will also need to include all those FQDNs in your SAN list.
Wildcard certificates are different than SAN certificates. Wildcard certificates can protect an unlimited number of subdomains.
For instance, a wildcard certificate for *.yourdomain.com,
secures sub-domains such as info. yourdomain.com and
shop.yourdomain.com. However, wildcards are also limited because they must share the same domain and the same number of levels. In addition, you cannot secure the Exchange autodiscover service with a wildcard SSL certificate.
Setting up domain names for your Exchange Server 2010 is potentially simpler than ever with the new Exchange Certificate wizard. Its new graphical user interface acts as an alternative to the Exchange Power Shell. The Exchange Configuration option will set up a standard server configuration designed to be used when ordering an SSL certificate. This is a convenient option but double check the default configuration options against your actual deployment ─ you don’t want to order the wrong SANs for your SSL certificate because your naming is not the same as the default Exchange configuration.