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.