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.

certificate-report

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:

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.

[adrotate banner=”51″]

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. James

    We have our autodiscover entry in DNS pointing to one of our 2013 CAS servers (2 sites, each site with a CAS and 2 mailbox servers in a DAG) and a generic entry also ie. mail.company.com pointing to the same CAS server.

    However, all our internal/external URL’s are the individual server names.

    Our 3rd party cert has the autodiscover, mail.company.com and server name entries.

    If I add an Exch 2016 server into the mix, obviously I’d need to add it’s name onto the cert as well – OR – just change all the internal/external URLs to be mail.company.com. Is that correct?

  2. Lakshmi Anand K

    Hi,

    Thanks for the great series! I am migrating from a SBS 2011 environment to W2016 & Exchange 2016. It has MyCompanyName.local FQDN. There was an internal AD CS CA running on the SBS 2011 machine. As a part of the migration, I have installed a new root CA on a dedicated machine.

    Now, using your script, I can see that only one Kerbos authentication certificate is from the new root CA, with blank subject name. I see a lot of other servers having different subject names. There are certificates that are not shown as used for SMTP, IIS, POP, IMAP or UM. Being a part time admin, I am unable to make sense which is which.

    As with the other post of yours, which are very great, can you please include in this post too, a little more information on what is expected configuration, and how to fix it?

  3. Tamang

    I am in a disconnected environment and use internal CA issued certificate for exchange using SHA-1. Do I have to use SHA-2 too?

    Thanks,

    Tamang

Leave a Reply