Starting with Exchange Server 2007, each Exchange server creates a default self-signed certificate. These out-of-the-box self-signed certificates unfortunately don't allow production Exchange servers to communicate with clients or third-party applications. Consequently, Exchange administrators must deploy additional certificates from either a commercial or internal CA. This tip examines the pros and cons of the PKI deployment options available.
It's not wise to dismiss the importance of digital certificates in Exchange Server. They help secure various connections and can also protect data. However, improperly deployed certificates cause problems with Exchange, as well as with clients and integrated applications, such as Lync and SharePoint.
Through Exchange Server 2003, administrators only had native Windows and IIS certificate management tools. Exchange 2007 and later versions use advanced certificate functions and offer self-signed certificates and management tools out of the box.
Because Exchange depends on healthy digital certificates for all aspects of operation, administrators must determine what kind of
Whether you use a commercial or internal CA, several common PKI components must be present in order for digital certificates to work properly:
- A root certificate authority server. Commercial root CAs do not directly issue Exchange Server certificates. They should not be used to do so in an internal PKI deployment.
- A self-signed root CA certificate. All devices that publish or access Exchange with a certificate from this CA need the certificate in the appropriate repository.
- One or more intermediate certificate authority servers. While not required in an internal CA deployment, intermediate CA servers give you better operational flexibility and resilience.
- The CA's certificate revocation list (CRL). This list is used to publish the IDs of revoked certificates and should be accessible to all client devices via HTTP.
- One intermediate CA certificate for each intermediate CA in the certificate chain that's signed by the root CA. Exchange servers and publishing devices, such as reverse proxies and load balancers, need these certificates. Clients can retrieve missing certificates from the server as long as the root CA is trusted.
- The Exchange server certificate. This certificate can be per server, per site or even per organization. It will probably need to be a SAN certificate that has an associated private key.
Commercial certificate authorities
Public CAs are popular with smaller organizations because client and device certificate management is simplified. These CAs have already distributed the appropriate root and intermediate CA certificates to modern operating system and mobile device manufacturers; therefore, they're included on new computers and devices by default. Exchange administrators don't have to manually provision these certificates to new mobile devices, laptops and desktops.
Public CAs also come with a combination of cost, support and reputation. Additionally, certain public CAs offer certificates that provide visible trust notifications in Web browsers. That said, they are generally overkill for Exchange Server -- unless OWA is extremely important to your company.
With a large number of servers and certificates to manage, the per-certificate cost and management complexity can become prohibitive, especially for email security features such as S/MIME. Also, many Exchange organizations do not adequately back up their certificates or plan for the delays a public CA can introduce.
Internal certificate authorities
An internal CA deployment may seem like an easy decision as Windows Active Directory Certificate Services (AD-CS) offers a sophisticated set of certificate creation and management functions. If you don’t want to use AD-CS, a number of third-party vendors offer their own CA products. However, ensuring that client devices trust internal CA certificates can prove challenging.
For corporate-provided assets, this can be part of the build process. However, for mobile devices and BYOD programs, provisioning and support can eliminate cost savings. Internal certificates limit the ability to secure traffic to other systems on the Internet that do not trust the internal CA root certificates.
Deploying internal CAs can also create a single point of failure if done incorrectly. Using a root CA to generate certificates seems easier than a two-tier PKI using intermediate CAs, but a server outage or decommissioning a server may require you to reissue a large number of certificates. If the CRL is not published to the Internet, external users and systems will experience problems.
Hybrid PKI deployment approaches
The right answer might actually be to combine the approaches described above. There are two primary ways to do this:
- Use a commercially purchased CA certificate. Many public CAs sell CA certificates, although they are considerably more expensive than server certificates. These intermediate CA certificates are then used with the internal CAs instead of generating your own CA certificates. The root CA is publicly available and trusted by client devices.
- Use public certificates for publishing and internal certificates for everything else. This option assigns public certificates for the handful of public-facing names and roles, such as reverse proxies, load balancers and externally-facing bridgeheads (see Figure 1).
All other server certificates are created from the internal PKI. This approach is effective because it uses the strengths of one type of CA to offset the weaknesses of the other.
Whichever option you choose, make sure your planning addresses the security, backup and redundancy of your certificate data and systems.
About the author
Devin Ganger is a messaging architect and technical writer with more than 15 years of experience in administering messaging systems, Windows, Unix and TCP/IP networks. Today, he works primarily with Exchange Server, Windows Active Directory and related Microsoft and third-party technologies. Ganger was recognized as a Microsoft MVP for Exchange Server from 2007 to 2011.
This was first published in January 2013