Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 961
  • Last Modified:

AD, DNS & Exchange 2010

I'm trying to understand better the effects of the new SSL restrictions where internal, and .local are no longer allowed in an SSL certificate. I have a couple of clients who are currently using SSL for outlook anywhere and owa access. The current certificates use:

Everything works great for internal and external access to exchange services via outlook and mobile devices, iPhones, etc.

I have one of the clients who had to renew their SSL certificate and since we can no longer get the internal server name on the certificate outlook internally generates a certificate error every time they try to open something in outlook. (almost every time) with the internal name of the server saying it does not match the certificate.

I did a little research and digicert is saying that from now one the internal dns structure has to match the external dns naming conventions. So my AD domain needs to be a .com or .net. To accomplish this the AD domain name would need to be changed, which does not sound thrilling to me.

Does anyone have a solution or effective work around for this issue?

1 Solution
AmitIT ArchitectCommented:
Did your client purchased the same cert with same old domain names or anything changed?
Did you enabled the new Cert? for IIS,SMTP,POP,IMAP etc. If not enable it for these services.
James HIT DirectorCommented:
>> digicert is saying that from now one the internal dns structure has to match the external dns naming conventions

Yes, that would certainly work, but the advice is really masking what is happening behind the scenes.

Exchange publishes a number of HTTP services for Outlook and other client devices to connect to. Most of these URLs are configured at the server and can be modified. One example is the setting known as the Autodiscover Service Connection Point (SCP), which Outlook clients joined to the domain on the internal network will use to communicate with Autodiscover.

By default, Exchange will set the value in the SCP to:


If your internal Active Directory domain is, then the FQDN in the above URL becomes Assuming you own the namespace, you can now obtain a certificate which lists and prove ownership of the domain.

With a .local or some other non-public TLD, the FQDN part of the above URL is set - by default - to, again, where company.local is the internal Active Directory domain.

Much online advice stated that an SSL certificate must include the name for Exchange to work properly. This advice is not inaccurate; it would work, but on the basis that the default configuration for the various URLs is the internal name of the server, so listing it on the certificate gives everyone an easy life without additional DNS and Exchange changes required.

Now that .local names are not permitted on SSL certificates beyond 2015/16, this will no longer work. You certainly don't need to go through an AD namespace upheaval to fix this though. Just change the default URLs in Exchange and list the public names on the certificate.

As public names are going to be used internally, you will need to ensure they can be resolved and routed correctly. This will depend on your network architecture. In a typical network, the Exchange environment is on the same LAN behind the same firewall as the internal clients. In addition, when is resolved, it will (by default) return the public IP. Most firewalls won't allow access to a public IP from the private LAN. Some can be configured to do so, but it is better to maintain two DNS namespaces and resolve the appropriate names internally to the internal Exchange IPs, a configuration known as split DNS.

You will need to create a forward lookup zone on your internal DNS infrastructure (probably on the DCs, but not necessarily). Add to this the ability for and to resolve to the internal Exchange IP. A CNAME record is normally appropriate here, aliasing the names to The benefit of this configuration vs relying on the public DNS & firewall change is continuity of service in the event of an Internet connection failure. If you were to rely on the public DNS, that is most likely hosted by a third-party on all but the largest of enterprise networks. If you lose Internet, you take a full or partial service hit to email, even internally.

When split DNS is properly configured, update the various URLs in Exchange:

Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri
Set-OWAVirtualDirectory -Identity "OWA (Default Web Site)" -InternalUrl -ExternalUrl
Set-ECPVirtualDirectory -Identity "ECP (Default Web Site)" -InternalUrl -ExternalUrl
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -InternalUrl -ExternalUrl
Set-ActiveSyncVirtualDirectory -Identity "Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl -ExternalUrl

Open in new window

You are now in a position to eliminate the use of .local names on your public SSL certificate, as Exchange will use public names for all accesses regardless of location of the Outlook client.

Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

Check the links at the bottom of the Digicert page that describes the new cert requirements.  They've made a tool available to reconfiguring Exchange servers and have also provided the manual process in case you'd rather not use the tool.  Be sure to read the prerequisites if you choose to run the tool.
87scullyAuthor Commented:
I was thinking this was the case I just did not have the Exchange url pieces. That makes total sense. Going to give it a shot and thank you very much for your help!
87scullyAuthor Commented:
I'll check that out as well Dave. It looks like Matt listed the manual process of doing the same thing listed on the digicert page?

Thanks guys!
I wasn't aware of the tool Dave has posted on the Digicert page. I certainly wouldn't recommend using that on anything more than the simplest of Exchange environments, but then, my instructions don't really cater for those environments either.  It would require more understanding of the specifics of the set up to give the proper advice as to the URLs to specify where and the underlying DNS changes to make to ensure uninterrupted service in all but the simplest of environments.

Still, the good news is there are ways around this, and you aren't required to do a complete AD domain rename or overhaul in the process!

87scullyAuthor Commented:
 I could not get the first exchange command to work:

Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri

I did the split DNS and I ran the remaining exchange commands however and it seems to have resolved the problem.

Thanks for your help!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now