If it is your first time working with Exchange Server 2010 then you will quickly realise that you need to learn about the relationship between Exchange 2010 and SSL certificates.
SSL Requirements in Exchange Server 2010
Prior to Exchange Server 2007 an Exchange server could be deployed and by default would not require SSL for any of its communications. The wise move when deploying Exchange Server 2003 (for example) was to install an SSL certificate for IIS and use SSL for external access (eg Outlook Web Access and ActiveSync).
However this was not mandatory and it certainly isn’t unusual to encounter legacy Exchange environments that allow external access over insecure HTTP connections.
For Exchange Server 2007, and then again with Exchange Server 2010, Microsoft changed the default behaviour so that SSL was required for many services, even when they are only used internally. So a newly installed Exchange Server 2010 server that hosted the Client Access server role would have SSL enforced for services such as:
- Outlook Web App
- Exchange Web Services
- Outlook Anywhere
The administrator could disable that SSL requirement, but again the wise move is to protect Exchange Server 2010 communications with SSL encryption rather than allow them over insecure HTTP connections.
Because the SSL requirement is on by default the Exchange 2007 and Exchange 2010 servers are installed with a self-signed SSL certificate. This self-signed certificate does the job of securing any SSL connections, however because it is self-signed no connecting clients or devices will trust it, so it is unsuitable for long term use. The administrator needs to install a new SSL certificate for Exchange Server 2010.
If you’re using an internal DNS namespace that you don’t own or is not valid (eg, .local) you may also need to read How to Deal with SSL Requirements for Exchange when Certificate Authorities Won’t Issue You a Certificate
Exchange 2010 SAN Certificates
Administrators who have installed SSL certificates for Exchange before may be familiar with the general process involved. But they might not be familiar with the SSL certificate requirements for Exchange Server 2010.
In short, Exchange Server 2010 will respond to connections on multiple names. These names typically include:
- The fully qualified domain name (FQDN) of the Exchange server, eg ex2.exchangeserverpro.net
- DNS aliases for external access, eg mail.exchangeserverpro.net or webmail.exchangeserverpro.net
- The Autodiscover name of each SMTP namespace in the organization, eg autodiscover.exchangeserverpro.net
This makes a standard single-name SSL certificate unsuitable. Instead, Exchange Server 2010 must be installed with a SAN certificate.
SAN stands for Subject Alternative Names and is a type of SSL certificate that has an attribute that stores additional names for the SSL certificate to apply to. For example, here is the certificate used to secure Outlook Web App for Microsoft.
In Exchange Server 2007 it was possible to make a series of configuration changes so that a single-name SSL certificate would work. However these changes were complex, especially in larger environments, and the cost to perform and maintain them (in terms of administrative time spent) far outweighed the cost of a genuine SAN certificate from a commercial Certificate Authority.
Where to Buy SSL Certificates for Exchange 2010
There are lots of commercial Certificate Authorities to choose from when buying an SSL certificate for your Exchange Server 2010 servers.
My recommendation is to use Digicert’s Unified Communications Certificate, which I like for the pricing, generous licensing terms, and support such as unlimited reissues of the certificate (if for example you forget one of the alternative names the first time you request the certificate).
How to Install an SSL Certificate for Exchange Server 2010
The process to acquire and install an Exchange 2010 SSL certificate is as follows.
- Generate a new certificate request using the wizard built in to Exchange Server 2010
- Submit the certificate request to your chosen Certificate Authority
- Install the issued SSL certificate on the Exchange 2010 server
- Assign the new SSL certificate to the appropriate services on the Exchange 2010 server
The complete process is demonstrated in this article:
If you are performing these steps for training or demo lab purposes you may wish to save money and issue the certificate from a private Certificate Authority instead. If that is the case then follow the steps in this article:
When using private Certificate Authorities you can potentially encounter trust issues that prevent Exchange 2010 from using the certificate. See this article for details of how to fix this problem:
And finally, in some network environments with restricted access to the internet you may find the new SSL certificate can’t be used by Exchange 2010 because it can’t check it against the certificate revocation list. If that happens to you follow the steps in this article to solve the problem: