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.
[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 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.