Exchange 2010 SSL Cert Only Works In Either LAN or WAN

We have Exchange 2010 running on a single Server 2012 DataCenter machine.

I have an Exchange self-signed cert - exchange01.domain.local
I have a public cert -

When I assign SMTP and IIS services to the exchange01 cert, WAN access on the OWA site shows an invalid cert error.
When I assign SMTP and IIS services to the owa cert, internal Outlook clients show an error stating that the server name and certificate don't match.

How can I get both of them to work properly?
Paul WagnerFriend To Robots and RocksAsked:
Who is Participating?

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

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.

Jian An LimSolutions ArchitectCommented:
fix up your by adding the right subject alternative name (san)
like and etc

check on
Simon Butler (Sembee)ConsultantCommented:
Reconfigure Exchange to use the external host name internally as well as externally - via a split DNS system.

You cannot have internal host names on SSL certificates any longer, so you need to move to that model - then tell users to stop using the server's real name.

Paul WagnerFriend To Robots and RocksAuthor Commented:
The problem is that even when I had the external cert being used, the internal Outlook clients still got a name mismatch issue. When they first set up outlook, it automatically finds their name and sets up the account. When they first open Outlook, it shows the server name mismatch error for the cert. I suppose that means I have to change something in the way the Outlook is auto-configured for clients but am not sure where.

My owa cert already is a 5-domain cert with owa, autodiscover, etc. I didn't want to confuse the issue.
Discover the Answer to Productive IT

Discover app within WatchGuard's Wi-Fi Cloud helps you optimize W-Fi user experience with the most complete set of visibility, troubleshooting, and network health features. Quickly pinpointing network problems will lead to more happy users and most importantly, productive IT.

Simon Butler (Sembee)ConsultantCommented:
You haven't changed the host names to match the certificate.
The prompt is almost certainly coming from Autodiscover, and internal Autodiscover needs to be changed with EMS.

It has nothing to do with the name of the server within Outlook - that will always be the real name of the server - which is fine because it doesn't make an SSL connection.

Berkson WeinTech FreelancerCommented:
We tend to use single name SSL certificates, but if you already have a SAN SSL cert, that's fine too.  You can't use a a self signed cert and a properly issued one concurrently though unless you're setting up multiple front end servers or additional virtual iis servers.

Here's what I would do:

You can use a single certificate, for example

Then you need to set the names that are used:

-- change owa
Set-OwaVirtualDirectory -Identity "servername\owa (default web site)" -ExternalUrl -InternalUrl

confirm: Get-OwaVirtualDirectory | Select Server,ExternalURL,InternalURL | fl

-- change ecp
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -ExternalUrl -InternalUrl

confirm : Get-EcpVirtualDirectory | select server,externalurl,internalurl | fl

-- change activesync
Set-ActiveSyncVirtualDirectory -Identity "ServerName\Microsoft-Server-Activesync (Default Web Site)" -ExternalUrl -InternalUrl

confirm: Get-ActiveSyncVirtualDirectory | select server,externalurl,internalurl | fl

-- change exchange web services
Set-WebServicesVirtualDirectory -Identity "ServerName\EWS (Default Web Site)" -ExternalUrl -InternalUrl

OR FOR ALL Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalUrl -InternalUrl
confirm: Get-WebServicesVirtualDirectory | Select Server,ExternalURL,InternalURL | fl

--      change oab
Set-OabVirtualDirectory -Identity "ServerName\oab (default web site)" -ExternalUrl -InternalUrl
confirm: Get-OabVirtualDirectory | Select Server,ExternalURL,InternalURL | fl

-- change autodiscover
Set-ClientAccessServer -Identity "ServerName" -AutoDiscoverServiceInternalUri

confirm: Get-ClientAccessServer | Select Name,AutoDiscoverServiceInternalURI

Keep in mind that the autodiscover rename requires a workaround.  THe alternative is to have a multiple name (SAN) certificate that has autodiscover in it.  We use a _SRV record in DNS to tell the client to look to

The internal clients will look at the autodiscover record in your public domain's dns servers and will auto configure from there.

Hope this helps.

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
Paul WagnerFriend To Robots and RocksAuthor Commented:
@weinberk and @Simon
I'll be taking a look at it this morning. Will let you know.
Paul WagnerFriend To Robots and RocksAuthor Commented:

Our cert has in it as well as and a few others. Should I then adjust your command to look like this?

-- change autodiscover
Set-ClientAccessServer -Identity "ServerName" -AutoDiscoverServiceInternalUri
Berkson WeinTech FreelancerCommented:
exactly.  And the OWA one. The key is that none should have your .local.

Of course you need to make sure that the DNS entries exist for all of the records too.

Being that you have a SAN certificate (multiple names), you do not need (or want to) do the SRV record that I referenced unless you have other domain names that need auto configuration.  If you do have other domain names, you'd need to modify the SAN certificate with another autodiscover record or uses the SRV dns record method.
Paul WagnerFriend To Robots and RocksAuthor Commented:

One caveat - we currently have our "old" Exchange 2010 server responding to requests. :-(

Without getting into it, we are migrating from one domain/exchange server to another domain/exchange server.
The old one is
The new one is
They both use the same multi-cert that has

My thoughts are that the internal users on the new domain will resolve to the proper "new" server via local DNS so there shouldn't be a problem there. Until we get everyone moved over and take down the old server, we won't be able have people authenticate externally on the new server using since the public DNS points to the old server. This shouldn't impact users in the new domain from setting up Exchange via Active-Sync on their phones since that URL has (??)

That sound about right?
Berkson WeinTech FreelancerCommented:
That does sound about right.  Migrations are always "fun."

I hate split DNS, but that could work for you if your public domain name doesn't have too many records.  Essentially, create a zone in your AD DNS for and add duplicate ALL of the records in your public DNS space.  Then change those that should point to something internal instead.  So for example: is the same public IP in the public DNS and AD DNS, autodiscover, owa would be the public IP in public DNS (the ex 2010 server for autodiscover) and the correct internal IP for the AD DNS
It ain't elegant and can be a maintenance nightmare if you change/add/delete dns records frequently, but it works.
Paul WagnerFriend To Robots and RocksAuthor Commented:
Sweet. We already point addresses to local IP's on the AD DNS anyway, so now I get to do that in two domains. Sounds like "fun". Setting everything up now. Will keep you posted.
Paul WagnerFriend To Robots and RocksAuthor Commented:

Ok, everything is working!

I do have another dilemma with autodiscover but that is kind of a separate issue than the original question. You're welcome to help me out with it! ;-)

Some points to Simon since he was helpful as well.
Paul WagnerFriend To Robots and RocksAuthor Commented:
Excellent guidance and  instructions! Thanks so much to @weinberk
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

From novice to tech pro — start learning today.