Digital certificates are an important way to secure Exchange Server. Because administrators have a number of choices when it comes to assigning digital certificates, it's important to understand the effect each certificate type will have on an Exchange 2013 installment.
Exchange certificate option #1: Self-signed certificates
Self-signed certificates have been part of Exchange Server for several years. They were originally intended to provide basic out-of-the-box security, but Microsoft recommended replacing them with certificates generated in-house or commercial certificates before placing the server into production. With
It's safe to use self-signed certificates in Exchange 2013 on mailbox servers, regardless of organization size. The mailbox server only communicates with the Client Access Server, so there's no need to replace the self-signed certificate.
Additionally, self-signed certificates don't work with Outlook Anywhere, but they can be used with Outlook Web App and with ActiveSync.
Exchange certificate option #2: Generate certificates yourself
Admins can also generate certificates using an in-house enterprise certificate authority (CA). Windows Server includes everything you need to build a homegrown CA, and certificates created in-house can support all Exchange 2013 services.
But there are two issues with homegrown certificates. The first issue is complexity; if you want to create your own certificates, you have to deploy and maintain an enterprise CA. You'll also have to constantly work to keep those servers secure so your certificates aren't compromised. You must also be obsessive about backing up and protecting enterprise CA servers because losing the certificate store can have catastrophic consequences.
Exchange certificate option #3: Commercial certificates
Purchasing an Exchange certificate from a commercial CA is the third option. This is usually considered the best option, but it's expensive.
The main advantage of purchasing certificates from a commercial CA is compatibility. Exchange Server communications can only be encrypted when both Exchange and the client trust the digital certificate. Self-signed certificates and homegrown certificates aren't trusted by default.
For a client device to trust a certificate, the device must trust the CA that issued the certificate. This means importing a CA certificate into the device's certificate store. Unfortunately, the certificate store isn't exposed on all device types, so it can be difficult to add trusts to certain devices. On the other hand, most client devices already trust well-known commercial CAs by default.
If you decide to use a commercial CA, you'll need to decide whether you want a single name certificate, a subject alternate name (SAN) certificate or a wildcard certificate. Microsoft generally recommends using a SAN certificate because multiple names can bind to a single certificate, making it easy to adapt the certificate to complex namespaces. But it's worth noting that some CAs don't issue SAN certificates, or they may limit the number of names you can associate with a SAN certificate.
Wildcard certificates also work well with Exchange Server because the certificate is based on a domain name rather than an individual resource name. But wildcard certificates can be a security risk; any host bound to your domain name could theoretically use a wildcard certificate.
If you purchase a SAN certificate, it's extremely important to include all necessary host names when registering it, otherwise it won't work. There are some commercial CAs that offer a grace period after a SAN certificate is issued. If an organization discovers they made an error when registering the certificate, they can get a replacement certificate. Otherwise an organization would have to purchase a new certificate if there was an omission or a misspelling during registration.
It's best to use the Certificate Wizard when requesting a SAN certificate, which is accessible through the Exchange Administration Center, to compile a list of names included in the certificate request. It should run in each Active Directory site where Exchange is deployed. The wizard is simple and straightforward, and it can keep you from making a costly mistake.
About the author:
Brien Posey is an eight-time Microsoft MVP for his work with Windows Server, IIS, Exchange Server and file system storage technologies. Brien has served as CIO for a nationwide chain of hospitals and health care facilities, and was once responsible for IT operations at Fort Knox. He has also served as a network administrator for some of the nation's largest insurance companies.
This was first published in February 2014