Certificates

As you plan the migration to Exchange Server 2016, you should first perform a review of your client access namespaces before you move on to planning for SSL certificates.

Exchange 2016 will install with a self-signed SSL certificate, but that certificate is not suitable for client connectivity as it will fail validation. Not only is the self-signed certificate untrusted by your clients, but it will not contain the namespaces that you’re using in your Exchange environment.

Fortunately for most organizations the existing SSL certificate being used for Exchange 2010 or 2013 can be re-used, provided that:

• It contains the namespaces that you’re planning to use for Exchange 2016
• It has been issued by a trusted certificate authority such as Digicert
• It hasn’t expired

You can review the current SSL certificates in the environment by running my Exchange certificate report script and reviewing the HTML report that it produces.

There is an additional consideration that you should look at. The existing certificates in some environments will be SHA-1 certificates, which are being phased out. If you have SHA-1 certificates installed on your Exchange servers, you should consider replacing them. You can either replace them on your existing servers in readiness for migration to Exchange 2016, or install a new certificate on your Exchange 2016 server. It’s best to contact your certificate provider first, as they will often allow SHA-1 certificates to be re-issued for free with SHA-2 certificates.

If you’re interested in how Exchange handles selection of a certificate when multiple certificates are bound to the SMTP protocol, here are some articles that explain it:

• Selection of Inbound Anonymous TLS certificates
• Selection of Inbound STARTLS certificates
• Selection of Outbound Anonymous TLS certificates

In the next part of this series we’ll look at additional information to collect from your Exchange environment when planning a migration to Exchange 2016.

In the last part of this Exchange 2016 migration series we looked at installing the first Exchange 2016 Mailbox server into the Not Real University organization. Now it’s time to configure the client access services for the new server.

Not Real University is using the same client access namespaces for Exchange 2016 as the existing Exchange 2010 and 2013 servers, so there are already DNS records in place. If you are deploying Exchange 2016 into a different site with new namespaces, you should add the DNS records for the namespaces first.

The Exchange 2016 client access namespace configuration can be performed using the Exchange Admin Center, but that’s the slow way of doing it. Instead, let’s use a PowerShell script that is built for this purpose, called ConfigureExchangeURLs.ps1. You can download it from the TechNet Gallery.

To configure the Not Real University Exchange 2016 server, the command is:

Next, the SSL certificate needs to be configured. If you’re new to the topic of SSL for Exchange, you can learn more about it here. Not Real University is using the same certificate that is already in use on the Exchange 2013 and 2010 servers, so the steps are:

1. Export/import the SSL certificate to the new server
2. Enable the SSL certificate for services in Exchange Server 2016

For environments where a new certificate is required, the steps are:

1. Generate a certificate signing request (CSR) for Exchange Server 2016
2. Submit the CSR to your chosen certificate authority
3. Complete the pending certificate request on the Exchange server
4. Export/import the SSL certificate to any additional servers (for multi-server scenarios)
5. Enable the SSL certificate for services in Exchange Server 2016

After the SSL certificate has been installed and enabled, restart IIS on the server for all of the recent changes to take effect.

In the next part of this series, we’ll look at configuring mailbox databases.

provides secure client-server and server-server network communications by using SSL certificates to secure protocols such as HTTP, SMTP, POP and IMAP.

Because of the “secure by default” requirements, when an Exchange 2013 server is installed it is configured with self-signed SSL certificates that are enabled for those protocols.

Here is an example of the self-signed certificates installed on a new Exchange 2013 server.

Although this means that services such as Outlook Web App, Outlook Anywhere, and Activesync are secure right from the moment the Exchange server is installed, the use of self-signed SSL certificates in Exchange Server 2013 is only intended to be temporary while the administrator acquires and installs the correct SSL certificates for the server.

SAN/UC Certificates for Exchange Server 2013

Exchange 2013 uses a type of SSL certificate that is known as a “Subject Alternate Name” (SAN) certificate. In some cases this will be called a “Unified Communications” (UC) certificate by providers such as Digicert.

A SAN certificate is an SSL certificate that has multiple server or domain names on the one certificate. This means that you can use a single certificate to secure one or more Exchange 2013 servers, and it can include all of the server names and other external URLs you plan to use for your Exchange environment, instead of having to provision a single-named SSL certificate for each of the different names.

Planning for Exchange 2013 SSL Certificates

There are three requirements for an SSL certificate to work correctly in your Exchange 2013 environment.

Certificate Validity Period

The certificate validity period is the period of time between when the certificate was issued and when it expires. Every SSL certificate will have an expiry date, and this will vary depending on how the certificate has been provisioned.

The default, self-signed certificate that Exchange 2013 creates during setup is valid for 5 years. A certificate issued from a private certificate authority may be valid for several years as well.

A certificate that has been acquired from a commercial certificate authority such as Digicert will usually be valid for one year.

Trusted Certificate Authority

For a client to trust the SSL certificate that a server is using the certificate must be issued by a certificate authority that the client already trusts.

If you’re using a private certificate authority to issue SSL certificates to your Exchange 2013 servers, and that CA is an enterprise CA in your AD forest, then that CA will already be trusted by clients that are members of domains in that AD forest. Non-domain members will not trust the CA unless the root certificate is imported into their trusted CA list.

The major commercial certificate authorities are already trusted by the operating systems running on most computers or mobile devices, so when you acquire your certificate from one of those CAs it will be trusted by connecting clients as well.

These trust issues mean that although you can use a private CA to issue your SSL certificates, it tends to be easier and less administrative effort to use a commercial CA.

Note: this trust issue only applies to the certificates installed on a dedicated Client Access server. The Mailbox server can use self-signed certificates because it does not accept direct client connections. In a multi-role server the trust issue still applies.

Correct Server/Domain Names

The final requirement is that the server or domain name that the client is connecting to must match one of the names on the SSL certificate.

For example, if the clients use the URL https://mail.exchangeserverpro.net/owa to connect to Outlook Web App, then the SSL certificate on the Exchange server must include the name “mail.exchangeserverpro.net”.

Depending on the role and configuration of the server it may need several names to be included on the SSL certificate. The minimum recommended names are the Client Access namespace (when a single, unified namespace is used) and the Autodiscover namespace.

For example, an Exchange 2013 server in the “exchangeserverpro.net” domain may need:

• the OWA, Outlook Anywhere, Activesync external URL names, eg “mail.exchangeserverpro.net”
• the Autodiscover name for the primary SMTP namespace, eg “autodiscover.exchangeserverpro.net”

Microsoft’s published best practices on SSL certificates for Exchange recommend not including the server FQDN in the certificate. For more information on how to configure Exchange servers so that the server FQDN is not required on the certificate please refer to this article.

In an Exchange 2007 to 2013 upgrade/co-existence scenario the certificate may also need to include a legacy name, such as “legacy.exchangeserverpro.net”.

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

How Many SSL Certificates to Configure?

For ease of administration, as well as for lower costs, it is recommended to provision as few certificates as possible.

Because the SSL certificate can include as many names as you need (up to about 50 before it may begin to cause performance issues), and with the way SAN/UC certificates are priced, it is often less costly to use a single SAN certificate for multiple Exchange Server 2013 servers than to acquire a unique certificate for each server.

Also consider that the trust issues when using a private CA to issue the SSL certificates for Exchange 2013 generally only apply to the internet-facing servers that will be accepting connections from non-domain members such as mobile devices. It may be possible in your environment to use a private CA to issue the SSL certificates for the non-internet-facing servers, as they may only be seeing direct connections from domain members.

The best number of certificates to configure is something for you to determine in the planning for your unique environment, but generally speaking fewer certificates is less costly and more manageable.

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:

• Exchange Server 2016 Client Access namespace configuration

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)

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.

In versions of Microsoft Exchange Server prior to Exchange Server 2007 a server could be deployed into an organization and, by default, would not require HTTPS (SSL) for any of its client-server or server-server communications.

Of course for organizations that recognized the value of securing their network communications the wise move was to install an SSL certificate for the IIS instance on the Exchange Server and use SSL for user access to services such as Outlook Web Access and ActiveSync, at least for external access if not for internal access as well.

However this was not mandatory and it certainly isn’t unusual to encounter legacy Exchange environments that allow external access over insecure HTTP connections. This lack of SSL encryption exposes end authentication credentials in clear text and risks them being compromised by attackers and used to gain access to your network.

Since the release of Exchange Server 2007 Microsoft has 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 server that hosted the Client Access server role has SSL required by default for services such as:<

• Outlook Web App (OWA)
• ActiveSync (mobile device access)
• Exchange Web Services
• Outlook Anywhere (aka RPC-over HTTPS)

Because of this “secure by default” behaviour the Exchange Server installation process generates self-signed SSL certificates to bind to IIS and use for those services.

Although this means that services such as Outlook Web App, Outlook Anywhere, and ActiveSync are secure right from the moment the Exchange server is installed, the use of self-signed SSL certificates in Exchange Server 2013 is only intended to be temporary while the administrator acquires and installs the correct SSL certificates for the server.

Exchange Server administrators should acquire and install SSL certificates on new Exchange Server deployments to replace those self-signed certificates. You can read more about this process at the following resources: