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.
I want to migrate exchange mailbox to o365, but in the server we are using self signed certificate. can i migrate users to o365 using hybrid or cutover method without having valid CA certificate?
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?
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?
You’ve installed a new root CA? Why?
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?