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!
Brendon GaigeIT DirectorAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Hypercat (Deb)Commented:
It sounds like it's your internal DNS records that aren't correct.  You need to add an autodiscover entry to your internal DNS to ensure the internal workstations find the correct name for that server.  Look at this article - it has instructions for configuring both external and internal DNS for Exchange 2016:

https://technet.microsoft.com/en-us/library/mt473798(v=exchg.150).aspx
Brendon GaigeIT DirectorAuthor Commented:
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.
viktor grantExchange ServersCommented:
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
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Brendon GaigeIT DirectorAuthor Commented:
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?
Brendon GaigeIT DirectorAuthor Commented:
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?
Brendon GaigeIT DirectorAuthor Commented:
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?
Brendon GaigeIT DirectorAuthor Commented:
So, since no one else seemed to have any other suggestions. I seem to have resolved the issue on my own, by purchasing the SAN for my SSL cert for autodiscover.email.com and adding it in. That seems to have stopped the SSL pop-ups. I don't feel like that was the 'actual and proper' way to resolve the issue, but it is working for the time being.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Brendon GaigeIT DirectorAuthor Commented:
No other truly helpful options were presented.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.