Replacing a single Godaddy domain certificate  with a multi domain one on an Exchange 2016 Server

bill2013
bill2013 used Ask the Experts™
on
My goal is to have an Exchange 2016 Server act as a mail server to Outlook 2016 clients on a small network.

All attempts have failed over the last 2 weeks and this seems to come down to me using a Standard SSL certificate while to get Exchange 2016 and Outlook 2016 working together requires a SANS certificate. I found this thanks to help from EE.

Anyway, I want to look at the easiest and least disruptive way to transfer the Certificate.

I will be getting the certificate later in the week and my work plan is as follows:

1. Leave the existing certificate (myoldcertificate.mydomain.com) in place until everything is finished.
2, Create a CSR from the Exchange Server for a Godaddy SHA-2 certificate with all URLs pointing to mynewcertificate.mydomain.com except for the autodiscover URL which will point to autodiscover.mydomain.com. Is this correct?
3. Add the new certificate as an MX and an A record in my Internet DNS. (Any SRV entries?)
4.  Install the new certificate on the exchange server.
5, Run the exchange wizard with the new certificate. Is there a way to properly edit the exchange settings rather than rerun the wizard?
6. Give the new certificate priority over the old one in the MX records.
7. Join Outlook 2016 clients to Exchange.

Is there anything I have forgotten?

Is it easier/possible to replace the certificate with a certificate of the same name - does exchange just look for the name, I guess it is secured to the full certificate serial number etc. and cannot be replaced for security issues, the whole point of the thing?

Thanks for any help.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Exec Consultant
Distinguished Expert 2018
Commented:
Do see this http://exchangeserverpro.com/exchange-server-2016-ssl-certificates/

2. Yes you can I see the common hostname as the external (internet) URI. Hence, the single "mynewcertificate"  (normally to make it simple it is "mail" as the hostname) host names client should covers the TLS/SSL connections to Exchange services. Those services include: Outlook Anywhere, MAPI, Outlook Web App, Exchange Control Panel, Exchange ActiveSync, Exchange Web Services, and Offline Address Book. The internal URI of hostname will differs generally. The other "autodiscover" is for the AutoDiscover.  Note that POP, IMAP and UM also have certificate requirements but can be enabled to use separate SSL certificates.

3. Actually you do not really need the SRV entries but it depends. See this sharing
http://www.experts-exchange.com/questions/28080144/Exchange-2013-SRV-Record-for-Internal-and-External-conneciton.html#a39030608
But more "typically" the SRV entries in your External (internet) DNS server is still setup for split DNS architecture. It is really to help the troubleshooting. Eventually the overall effect is to make sure the Outlook autodiscover will use DNS SRV lookup for _autodiscover._tcp.mydomain.com, and then "mynewcertificate.mydomain.com" is returned.

5. For testing, I suggest running external tests using the Remote Connectivity Analyzer website.
https://www.testexchangeconnectivity.com/
Actually you can also run through using powershell to see the setting prior to the final test to make sure the steps are done as expected.
http://exchangeserverpro.com/avoiding-exchange-2013-server-names-ssl-certificates/

Probably for the "remaining" stuffs is to check the  summarized outcome
- certificate must contain the names (i.e. the URLs or namespaces) that clients
- SSL cert validity period (start and end dates)
- any errors due to clients (Outlook, web browsers, mobile devices, etc) trust

You can reuse the same certificate as long as it fulfill the above mentioned too. See excerpt from the article (note that they use a different domain name)
•Correct server/domain names – the SSL certificate must contain the namespaces (aka, URLs, aliases, domain names) to match the names that clients will be connecting to (for example, users typing “mail.exchange2016demo.com” in their web browser to access Outlook on the web)
•Certificate validity period – each SSL certificate has a fixed period of time during which it can be considered valid. When the SSL certificate reaches its expiry date it will need to be renewed to continue working.
•Trusted certificate authority – clients will only trust SSL certificates that have been issued by a certificate authority that they already trust. This is one reason that the self-signed certificate is not suitable for general production use, because your clients will not trust certificates issued by the Exchange server itself. There are a wide range of certificate authorities available to purchase certificates from that your client operating systems and devices will trust.
https://exchangeserverpro.com/exchange-server-2016-ssl-certificates/

But do note for load balanced implementation, like doing SSL offloading on your reverse proxy, you actually do not follow the CSR approach that you shared. You can make a certificate request from your reverse proxy, generate a certificate for them through public CA (GoDaddy in your case) and then import onto that reverse proxy. Preferably, all servers in a load-balanced pool should use the same SSL certificate.

Author

Commented:
Many thanks. I will go through your reply in detail later today.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial