Some years ago, I cannot recall, Go Daddy along with many other SSL certificate providers stopped supporting Subject Alt Names (SANs) that had the local FQDN of your mail server. Example: mailserver.interanl_domain.local. Email servers today need to have a UCC certificate. There are many places where you can obtain free certificates , such as STARTSLL.com. As of late, Go Daddy was instumental in getting some StartSSL IP address black listed. This issue has been resolved and they are back in business. Obviously, free vs 400/ 3years is a good deal.
The above error is experienced by internal users after the new SSL certificate is imported. You may also find that your OWA and email accounts on your cell phones have stopped working.
Here is our most recent scenario. Our customer wanted to be able to securely access their email from home using Outlook 2016. Exchange/Outlook 2010 use RPC over TCP while Excchange 2013/2016 use RPC over HTTP. We did what anyone would do. We purchased a UCC SSL certificate from Go Daddy and added the following SANs.
-rdp.domainname.com (for future use)
NOTE: there is not an entry for mailserver.internal_domain.com. Herein lies the crux of the issue.
The moment the new SSL was imported, the internal users began experiencing the above error message, OWA went down and cell phone email accounts stopped. The isses are all related.
Issue 1: you will see the mail_server.internal_domain.local at the top of the error. When you view the SANs in the certificate, you will note that it is using the newly imported certificate purchased. mail_server.internal_domain.local is not and cannot be one of thse SANs. So how do you resolve this issue? Simple. It's a binding issue. I will say that we had fun perfoming these same steps on an older Exchange 2007 server as well.
Note that the https .443 * is bound to the new Go Daddy certificate. This is correct. What we need to resolve the above error is verify the where the server is being pointed internally to resolve mailserver.internal_domain.local. This can be done using two different methods.
Step 1: Open Outlook on your workstation exhibiting the error message
Step 2: Click the up arrow at the bottom-right near the clock
Step 3: Hold the CTRL key and right click the Outlook icon
Step 4: Click Test email autoconfiguration…
Step 5: Uncheck Use Guessmart and Secure Guessmart Authentication
Step 6: Click Test
Step 7: Click the Log tab.
NOTE: Below is an example of a correct configuration