Exchange Server 2013 provides a high level of security for client-server and server-server communications by using 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 certificates that are enabled for those protocols.
Here is an example of the self-signed certificates installed on a new Exchange 2013 server.
[PS] C:\>Get-ExchangeCertificate | Select Subject,IsSelfSigned,Services | ft -auto Subject IsSelfSigned Services ------- ------------ -------- CN=Microsoft Exchange Server Auth Certificate True SMTP CN=E15MB1 True IMAP, POP, IIS, SMTP CN=WMSvc-E15MB1 True None
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 certificates is only intended to be temporary while the administrator acquired 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://webmail.exchangeserverpro.net/owa to connect to Outlook Web App, then the SSL certificate on the Exchange server must include the name “webmail.exchangeserverpro.net”.
At minimum the SSL certificate should include the fully qualified domain name (FQDN) of the Exchange server itself. Then, depending on the role and configuration of the server, it may also need several other names for external access methods.
For example, an internet-facing Client Access server named “excas1″ in the “exchangeserverpro.net” domain may need:
- the server FQDN of “excas1.exchangeserverpro.net”
- the OWA, OA, 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. Consider that the Exchange servers in a given site will likely have the same configurations such as external URLs, so the only variation in their certificate requirements is the server FQDN itself.
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 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 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.
After planning your certificate requirements the next steps are:
- Generate a Certificate Request for Exchange 2013
- Submit the certificate request to your chosen CA to acquire the SSL certificate. I recommend Digicert for their competitive pricing, good support, flexible licensing, and free re-issues if you happen to make an error. Or if you’re using a private CA refer to these steps.
- Complete the pending certificate request
- Export/import an SSL certificate to multiple Exchange 2013 servers (optional)
- Assign the SSL certificate to services in Exchange 2013