Exchange 2016 and Outlook showing wrong name on SSL Cert
I am deploying an Exchange 2016 install onto a 2012 R2 server, and I keep running into an issue where Outlook keeps trying to point to the local name of the server, which throws up an SSL cert error. The server's real name is exchange.local.com. I am aware that having a *.com name for a local domain is not good policy, but that was the hand I was dealt. The Exchange 2016 is up and running, and hosting an email domain for @email.com. The accounts propagate, send and receive email correctly. The public facing domain that points to the Exchange server is @public.net. So the flow should go as follows:
(email dns hosted on godaddy) user@email.com > (public) exchange.public.net (dns hosted on godaddy )> public facing IP of server which our firewall NATs to the internal IP.
I have a SSL cert from DigiCert that includes the exchange.public.net and autodiscover.public.net SANs, and it is properly loaded onto the Exchange server. I can load up the OWA, and it shows it as a secure connection from https://exchange.public.net. I ran the Microsoft online tool, and after giving it all of the proper account information, it resolves everything just fine, using the SRV for autodiscover for the email domain @email.com, finding it routing to exchange.public.net just fine, even giving a perfect SSL handshake along the way.
WHY then, does Outlook continue to point to the internal address of exchange.local.com? Which of course throws up the SSL cert error every time someone opens their outlook?
I have gone through and pointed every internal and external URL and URI to https://exchange.public.net. I have setup the split-DNS entries for the lxgx.net domain inside of my local.com forest. I also checked the SCP in the Sites and Services of the local.com domain, and that points to https://exchange.public.net/autodiscover as it should.
NSLookups all resolve, both internally and externally to exactly where they are supposed to. DNS entries resolve to exchange.public.net when pinging exchange.local.com.
Yet Outlook still pops up an SSL error saying it is trying to connect to Exchange.local.com. WHY?
Also, if I login to an off-prem computer, and setup the Exchange account in Outlook using the 'connect by proxy' settings, the first time it connects, it will authenticate perfectly, giving no SSL errors. However, upon closing Outlook and re-opening, when it is trying to reconnect, it never does, because it changes the server it is trying to connect to back to the internal address.
First time:
Server: GUID_long_name@email.com
User: first.last
Everytime after:
Server: https://exchange.local.com/mapi/GUID_long_name@email.com
User: first.last
Outlook injects the local address of the server into the server information, even though the computer is not on-prem, meaning that the user can no longer connect to their mailbox!
(email dns hosted on godaddy) user@email.com > (public) exchange.public.net (dns hosted on godaddy )> public facing IP of server which our firewall NATs to the internal IP.
I have a SSL cert from DigiCert that includes the exchange.public.net and autodiscover.public.net SANs, and it is properly loaded onto the Exchange server. I can load up the OWA, and it shows it as a secure connection from https://exchange.public.net. I ran the Microsoft online tool, and after giving it all of the proper account information, it resolves everything just fine, using the SRV for autodiscover for the email domain @email.com, finding it routing to exchange.public.net just fine, even giving a perfect SSL handshake along the way.
WHY then, does Outlook continue to point to the internal address of exchange.local.com? Which of course throws up the SSL cert error every time someone opens their outlook?
I have gone through and pointed every internal and external URL and URI to https://exchange.public.net. I have setup the split-DNS entries for the lxgx.net domain inside of my local.com forest. I also checked the SCP in the Sites and Services of the local.com domain, and that points to https://exchange.public.net/autodiscover as it should.
NSLookups all resolve, both internally and externally to exactly where they are supposed to. DNS entries resolve to exchange.public.net when pinging exchange.local.com.
Yet Outlook still pops up an SSL error saying it is trying to connect to Exchange.local.com. WHY?
Also, if I login to an off-prem computer, and setup the Exchange account in Outlook using the 'connect by proxy' settings, the first time it connects, it will authenticate perfectly, giving no SSL errors. However, upon closing Outlook and re-opening, when it is trying to reconnect, it never does, because it changes the server it is trying to connect to back to the internal address.
First time:
Server: GUID_long_name@email.com
User: first.last
Everytime after:
Server: https://exchange.local.com/mapi/GUID_long_name@email.com
User: first.last
Outlook injects the local address of the server into the server information, even though the computer is not on-prem, meaning that the user can no longer connect to their mailbox!
ASKER
So for my internal DNS I have it set as follows:
Forward Lookup Zones:
local.com
autodiscover cname autodiscover.public.net
exchange cname exchange.public.net
_tcp
_autodiscover SRV exchange.public.net
Public.net
autodiscover Host(A) 192.168.1.15
exchange HOST(A) 192.168.1.15
Reverse Lookup Zones:
192.168.1.15 PTR autodiscover.public.net
192.168.1.15 PTR exchange.public.net
What else am I supposed to put in? In every other case I test, it resolves the DNS to exchange.public.net, except for Outlook.
Forward Lookup Zones:
local.com
autodiscover cname autodiscover.public.net
exchange cname exchange.public.net
_tcp
_autodiscover SRV exchange.public.net
Public.net
autodiscover Host(A) 192.168.1.15
exchange HOST(A) 192.168.1.15
Reverse Lookup Zones:
192.168.1.15 PTR autodiscover.public.net
192.168.1.15 PTR exchange.public.net
What else am I supposed to put in? In every other case I test, it resolves the DNS to exchange.public.net, except for Outlook.
HI Brendon,
The issue happens internally and externally?
Firstly you can try to solve internally. If you have the correct name in the certificate, you can create A record in order that the connection be quickly.
Cheers
Viktor
The issue happens internally and externally?
Firstly you can try to solve internally. If you have the correct name in the certificate, you can create A record in order that the connection be quickly.
Cheers
Viktor
ASKER
Viktor, I don't understand what you mean.
The issue happens both internally and externally, but only with Outlook.
I am trying to solve it internally. You can no longer put local names in public facing SSL certs per regulations. So how am I supposed to do that, when I have the public facing name in the cert, along with the public facing name listed in all public and local DNS, and it resolves correctly through every means except Outlook?
The issue happens both internally and externally, but only with Outlook.
I am trying to solve it internally. You can no longer put local names in public facing SSL certs per regulations. So how am I supposed to do that, when I have the public facing name in the cert, along with the public facing name listed in all public and local DNS, and it resolves correctly through every means except Outlook?
ASKER
Something is missing somewhere... It seems that Outlook makes two checks when attempting to connect to Exchange. I have been able to get it to resolve at times on the first check with the approved FQDN of exchange.public.net but on the second check, it always returns the exchange.local.com. Why?
ASKER
Ok, so an update, I have been able to get Outlook to connect to Exchange, both internally and externally reliably. Once the connection is establish, Outlook updates the server information to show as:
https://exchange.public.net/mapi/xxxx@email.com
Which is what it should show, and now atleast on the seeming first check, it will not ask for the SSL cert warning. It is however, now giving a pop-up after about 2-3 minutes of being connected saying the SSL cert does not recognize autodiscover.email.com. Why is it trying to connect to the autodiscover.email.com address, when it has already established a correct connection with the exchange.public.com address and created a secure connection?
https://exchange.public.net/mapi/xxxx@email.com
Which is what it should show, and now atleast on the seeming first check, it will not ask for the SSL cert warning. It is however, now giving a pop-up after about 2-3 minutes of being connected saying the SSL cert does not recognize autodiscover.email.com. Why is it trying to connect to the autodiscover.email.com address, when it has already established a correct connection with the exchange.public.com address and created a secure connection?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
No other truly helpful options were presented.
https://technet.microsoft.com/en-us/library/mt473798(v=exchg.150).aspx