2

We have recently had to decommission our .local certificate from Godaddy, as it will not be valid anymore. The new certificate contains the following names:

  • mail.mydomain.com
  • autodiscover.mydomain.com

This certificate has been applied to the Exchange server and activated for all services.

I was expecting clients to get errors on the certificate as they are connected to the mail.mylocaldomain.local name. I have read a lot of documentation and they all pretty much say the same thing:

  1. add new zone on local DNS server with the public domain (I added a zone mydomain.com)
  2. add a record A pointing to the local ip of the email server (I added mail.mydomain.com pointing to local IP of the server)

I have issued these commands:

Set-ClientAccessServer -Identity EXCHANGE-MAIL -AutodiscoverServiceInternalUrihttps://mail.publicdomain.co.uk/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “EXCHANGE-MAIL\EWS (Default Web Site)” –InternalUrlhttps://mail.publicdomain.co.uk/EWS/Exchange.asmx
Set-OABVirtualDirectory -Identity “EXCHANGE-MAIL\OAB (Default Web Site)” -InternalURL https://mail.publicdomain.co.uk/OAB
Set-ActiveSyncVirtualDirectory -Identity “EXCHANGE-MAIL\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURLhttps://mail.publicdomain.co.uk/Microsoft-Server-Activesync
Set-WebServicesVirtualDirectory –Identity ‘EXCHANGE-MAIL\EWS (Default Web Site)’ –ExternalUrlhttps://mail.publicdomain.co.uk/ews/exchange.asmx

with the proper names in them, but my clients are still getting the certificate error.

Why?

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Nickd
  • 31
  • 1
  • 1
  • 3
  • The best answer to this question is here: https://serverfault.com/questions/618309/exchange-2010-certificate-error-on-internal-outlook-2013-connections – Lijo George Jan 28 '19 at 08:19

3 Answers3

4

Your Exchange server's FQDN (Fully Qualified Domain Name) is still hostname.domainname.local, hence the clients connect to it, see that the name of the server they are connecting to does not match either the name, nor the SANs (Subject Alternative Names) on the certificate you have, and throw that error, as they are designed to do.

The easiest solution (by a wide margin) is to perform an Exchange migration to get your Exchange server onto a properly named domain for which you can get a certificate issued from a trusted public certificate authority.

See this thread on Active Directory best practices, it is one of several we have on the subject. Your Active Directory DNS name should be an unused subdomain of your publicly registered domain name. Once you have that in place, migrate your Exchange server to it, and get a certificate issued which includes your new Exchange server's FQDN, for which you will be able to obtain a certificate.

Community
  • 1
HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
  • sorry but i dont think this is going to work. It is an internal non public domain, so i am using the .local and that cannot change. Also please note that if i go to a client, create a new profile in outlook and let it autoconfigure it works without errors (and it connects to the mail.mydomain.local), but for some reasons the current clients although they connect to the same mail.mydomain.local, they get the error (for some reason i would need to recreate the profile on each machine, that is something i am trying to avoid). thanks btw – Nickd Mar 03 '15 at 01:09
  • 2
    @Nickd The Common Name in the certificate must match the hostname, there is no way around as this is one of the key points of the PKI/CA-System. You have to adapt your hostnames at the client side to valid ones. – sebix Mar 03 '15 at 13:59
1

please bear in bind that the answer from HopelessN00b IS NOT correct. YOU DO NOT need to migrate the Exchange even if it has the local hostname. Adding an internal DNS zone pointing to the public name will do as well as changing the autodiscoverinternaluri switch.

Nickd
  • 31
  • 1
  • 1
  • 3
0

Please refer to the following Microsoft KB article (940726) for resolution: http://support.microsoft.com/en-us/kb/940726

Outlook polls AD periodically to update Autodiscover settings, so it can take up to 1 hour for Outlook to pick up the new settings (or you can restart Outlook to refresh the settings immediately).

Also, verify that mail.mydomain.com points to the internal IP address of the Exchange server on Outlook clients, and that you have recycled the MSExchangeAutodiscoverAppPool in IIS on the Exchange server after applying the new settings.

Twirlee
  • 1