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.

  • Why are you using .local at all? – Joe Sniderman Aug 6 '14 at 8:47
  • @JoeSniderman Because our AD domain is sbgmb.local. Therefore the fqdn of the exchange server is exch.sbgmb.local. – Lorenz Meyer Aug 6 '14 at 12:10
  • @JoeSniderman Do you know how to force Outlook2013 to connect to the external host name only ? – Lorenz Meyer Aug 6 '14 at 14:13

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.


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.


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.


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.

  • 1
    I understand. My question is 'How not to use .local in my FQDN without creating a new domain, moving all computers and users, reinstalling a DC, Exchange server ... how do I change the main fqdn of my Exchange server without creating work for two months ? – Lorenz Meyer Aug 20 '14 at 7:39
  • My Exchange server has an external domain name, and Outlook Anywhere work from the internet. Only on-premise Outlook clients have the certificate warning. – Lorenz Meyer Aug 20 '14 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.