Home / server / Questions / 618309
Accepted
Lorenz Meyer
Asked: 2014-08-06 22:56:58 +0800 CST

Exchange 2010 - Certificate error on internal Outlook 2013 connections

  • 772

I have an Exchange 2010 and Outlook 2003. The exchange server has a wildcard SSL certificate installed *.domain.com, (for use with autodiscover.domain.com and mail.domain.com). The local fqdn of the Exchange server is exch.domain.local. With this configuration there is no problem.

Now I started upgrading all Outlook 2003 to Outlook 2013, and I start to get consistently a certificate error in Outlook :

The Name on the security certificate is invalid or does not match the name of the site

I understand why I get that error: Outlook 2013 is connecting to exch.domain.local while the certificate is for *.domain.com.

I was ready to buy a SAN (Subject Alternate Names) Certificate, that contains the three domains exch.domain.local, mail.domain.com, autodiscover.domain.com. But there is a hindrance: the certificate provider (in my case Godaddy) requires that the domain is validated as being our property. Now it is not possible for an internal domain that is not accessible from the internet. So this turns out not to be an option.

Create self-signed SAN certificate with an Enterprise CA is an other option that is barely viable: There would be certificate error with every access to webmail, and I had to install the certificate on all Outlook clients.

What is a recommended viable solution ?

Is it possible to disable certificate checking in Outlook ?
Or how could I change the Exchange server configuration so that the public domain name is used for all connections ?
How to change the main FQDN of the Exchange server, as suggested in the answer, without the need of reinstalling the server ? Or is there another solution I'm not thinking of ?

Any advice is welcome.

exchange-2010

3 Answers

  1. Best Answer

    Here are the steps to change the FQDN used by Outlook to connect to the server (sources: Godaddy, puryear)

    Using the Exchange Management console change the internal URL of the different webservices:

    Set-ClientAccessServer -Identity Your_Server_Name -AutodiscoverServiceInternalUri https://mail.domain.com/autodiscover/autodiscover.xml

    Set-WebServicesVirtualDirectory -Identity "Your_Server_Name\EWS (Default Web Site)" -Set-OABVirtualDirectory -Identity "Your_Server_Name\oab (Default Web Site)" -InternalUrl https://mail.domain.com/oab

    Set-UMVirtualDirectory -Identity “Your_Server_Name\unifiedmessaging (Default Web Site)” -InternalUrl https://mail.domain.com/unifiedmessaging/service.asmx

    Set-ActiveSyncVirtualDirectory -Identity "Your_Server_Name\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl "https://mail.domain.com/Microsoft-Server-ActiveSync"

    The main thing to notice here is that your setting the internal URLs to be the same as the external URLs.

    • 5

  2. I am working through the same process, Exchange 2010 with Outlook 2013 clients and having just registered a mail.domain.com certificate. Our server isn't server.local though, it is server.domain.com, but I don't want to have to add that server name to the listed hostnames in the certificate, and also want to do it correctly.

    https://www.digicert.com/internal-domain-name-tool.htm

    You can use this tool to generate the Powershell scripts that will correct the Exchange URL addresses to be that of your externally facing hostname instead of your internal hostname, as well as a roll back script to revert the changes.

    You will need to have installed the certificates into Exchange, and you will also need to have created an internal DNS entry to resolve mail.domain.com to servername.local.

    You will most likely see that if you access mail.domain.com/OWA (from internal or external) you won't get a certificate error, but if you access server.local/OWA you will. This fix is definitely for you then!

    Note: The Microsoft KB940726 article shows that the OABVirtualDirectory URL should be HTTPS, however if you had HTTP configured, the DigiCert tool will keep that instead of changing it to HTTPS.

    • 1

  3. You can begin to solve your situation by not using ".local" in your FQDN. Starting in 2015, locally assigned addresses will no longer be accepted by certification authorities. So your better fixing this problem now then a year down the road.

    GoDaddy is doing the right thing. Your basically stuck between a rock and a hard place. Most certificate providers are enforcing the new rule now, so you might as well buy a new certificate with your actual global domain address (hopefully you have a domain set up) with the appropriate SANS.

    • 0