Exchange Server 2016 communicates with clients, applications and other servers over a variety of network protocols such as HTTPS, SMTP, IMAP and POP. Much of this communication, particularly clients and applications, involves username and password-based authentication. When user credentials are sent over the network they are sent “in the clear”, meaning they can potentially be intercepted and read by an attacker. Other information transmitted during the session may also be sensitive and prone to abuse if interception was possible.
To secure these communications Exchange Server 2016 uses SSL certificates to encrypt the network traffic between the server, clients and applications. This includes:
- Outlook connecting to Outlook Anywhere (RPC-over-HTTP) or MAPI-over-HTTP
- Web browsers connecting to Outlook on the web (OWA)
- Mobile devices connecting to ActiveSync to access mailboxes and calendars
- Applications connecting to Exchange Web Services (EWS) for free/busy and other lookups
- Email clients connecting to secure POP or IMAP
- TLS encrypted SMTP between Exchange servers or other email servers
When Exchange Server 2016 is first installed it generates a self-signed SSL certificate that is then enabled for IIS (HTTPS services like OWA, EWS and ActiveSync), SMTP, POP and IMAP. The self-signed certificate allows the server to be “secure by default” and begin encrypting network communications right from the start, but it is only intended to be used temporarily while you provision the correct SSL certificates for your environment.
When deploying Exchange Server 2016 you should plan to replace the self-signed certificate with a valid SSL certificate for your deployment scenario. This involves an investment of anywhere from $99 to several thousand dollars depending on your Client Access namespace scenario, the type of certificate you purchase, and which certificate authority you purchase it from.
If you’re tempted to stick with the self-signed certificate, or to try and disable SSL requirements on Exchange services, I strongly recommend you do not do those things.
- Deliberately trying to reduce the security of your Exchange environment is unwise
- The hours you’ll spend configuring and troubleshooting your attempted workarounds is more costly than just buying the correct SSL certificate
- Some stuff just flat out won’t work if you try to work around SSL requirements
Exchange Server 2016 SSL Certificate Requirements
There are three basic requirements for an SSL certificate in an Exchange Server 2016 deployment.
- Correct server/domain names – the SSL certificate must contain the namespaces (aka, URLs, aliases, domain names) to match the names that clients will be connecting to (for example, users typing “mail.exchange2016demo.com” in their web browser to access Outlook on the web)
- Certificate validity period – each SSL certificate has a fixed period of time during which it can be considered valid. When the SSL certificate reaches its expiry date it will need to be renewed to continue working.
- Trusted certificate authority – clients will only trust SSL certificates that have been issued by a certificate authority that they already trust. This is one reason that the self-signed certificate is not suitable for general production use, because your clients will not trust certificates issued by the Exchange server itself. There are a wide range of certificate authorities available to purchase certificates from that your client operating systems and devices will trust. I generally recommend using Digicert.
Choosing a certificate authority is simple enough, and the validity period will be determined by how long you purchase the certificate for (usually a minimum of 12 months, but the longer the validity period the less the certificate tends to cost per year). That leaves the server/domain names (or namespaces) as the main decision point when planning your SSL certificates.
Namespaces for Exchange Server 2016 SSL Certificates
The simplest approach to namespaces for Exchange Server 2016 is to use a single namespace for all HTTPS services. An example of this approach can be seen at the following article:
In addition to the HTTPS namespace it is also common to use a separate namespace for each of the SMTP, POP and IMAP services, although it is certainly not required to do so. There is also the Autodiscover CNAME to consider, and the root domain as well.
In a simple environment where the domain name used for email addresses is exchange2016demo.com, and taking all of the above into consideration, the namespaces could be planned as:
- mail.exchange2016demo.com (for all HTTPS, SMTP, POP and IMAP)
- autodiscover.exchange2016demo.com (for the Autodiscover CNAME)
- exchange2016demo.com (for root domain Autodiscover lookups)
For Exchange Server 2010 to 2016 migration scenarios the certificate may also need to include a legacy name, such as “legacy.exchange2016demo.com”, for the co-existence period. Other than that I am going with the simplest certificate in this example, by using one name “mail.exchange2016demo.com” for HTTPS, SMTP, POP and IMAP.
The recommended practice is to only include aliases as namespaces on SSL certificates, and not any server fully-qualified domain names (real server names). Due to recent changes to certificate issuance rules you may also find it impossible to request an SSL certificate for a domain name that is not internet-routable or that you do not legitimately own (e.g., domain.local). If you’re unsure about how exactly this will work please read my article on avoiding server names in SSL certificates.
Which Type of Certificate to Purchase?
Certificate authorities such as Digicert can sell you a variety of certificate types, and some certificate authorities have different names for what is basically the same thing.
A standard SSL certificate contains a single name and is generally the cheapest to purchase, however these are not suitable for even the simplest of namespace designs.
A wildcard SSL certificate allows you to secure multiple names on a domain without having to specify the exact names on the certificate itself. For example, a Digicert wildcard certificate can be acquired for exchange2016demo.com and *.exchange2016demo.com. While these are often a lower cost option, wildcard certificates can have compatibility issues with some integration scenarios with other systems, as well as not being suitable for secure POP and IMAP configurations.
A SAN or UC (Unified Communications) certificate is the recommended type of SSL certificate to purchase. A SAN certificate can contain multiple names. For example, a Digicert UC certificate can include up to four names at the normal price, with additional names up to 25 total being available at an additional cost. While the cost of a SAN/UC certificate will be more than a wildcard certificate you are less likely to run into any compatibility issues with the SAN/UC certificate, as long as the certificate contains the correct names. If you make an error with your namespace planning or need to add a name later Digicert and some other providers will allow you to re-issue the certificate at no cost, while other providers will charge a re-issuing fee.
How Many SSL Certificates Should You Purchase?
After planning your namespaces and choosing a certificate authority you may be considering how many SSL certificates to purchase, especially if you have more than one Exchange 2016 server.
The recommend practice is to provision as few SSL certificates as possible, because it is simpler to administer as well as less costly to purchase. So while it is possible to have separate certificates for each of the HTTPS, SMTP, POP and IMAP services, it is recommended to use one certificate for all of them unless you have a specific scenario that requires different certificates.
Note that while only one SSL certificate can be enabled for HTTPS on a server, multiple SSL certificates can be enabled for SMTP. However in most simple deployments only a single certificate will be required for SMTP.
Similarly it is recommended to use the same SSL certificate for all of the Exchange servers that will be configured with the same namespaces. For example, if you have two Exchange 2016 servers in a site that will be load-balanced, and both have the “mail.exchange2016demo.com” namespace configured for HTTPS services, they should have the same certificate installed. You achieve this by provisioning the certificate on the first server, and then exporting it and importing it to as many additional servers as needed.
Next Steps
After planning your Exchange Server 2016 SSL certificates the next steps are:
- Generate a certificate signing request (CSR) for Exchange Server 2016
- Submit the CSR to your chosen certificate authority
- Complete the pending certificate request on the Exchange server
- Export/import the SSL certificate to any additional servers (for multi-server scenarios)
- Enable the SSL certificate for services in Exchange Server 2016
We’ll explore each of those steps in more detail in upcoming articles on this site.
This article Exchange Server 2016 SSL Certificates is © 2015 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
