AD, DNS & Exchange 2010

Posted on 2013-01-07
Last Modified: 2013-01-07
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?

Question by:87scully
LVL 42

Expert Comment

ID: 38751558
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.
LVL 17

Expert Comment

ID: 38751588
LVL 58

Accepted Solution

tigermatt earned 250 total points
ID: 38751710
>> 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.

Netscaler Common Configuration How To guides

If you use NetScaler you will want to see these guides. The NetScaler How To Guides show administrators how to get NetScaler up and configured by providing instructions for common scenarios and some not so common ones.

LVL 26

Expert Comment

ID: 38751729
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.

Author Comment

ID: 38751748
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!

Author Comment

ID: 38751757
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!
LVL 58

Expert Comment

ID: 38752052
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!


Author Comment

ID: 38753345
 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!


Featured Post

Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

This article aims to explain the working of CircularLogArchiver. This tool was designed to solve the buildup of log file in cases where systems do not support circular logging or where circular logging is not enabled
A list of top three free exchange EDB viewers that helps the user to extract a mailbox from an unmounted .edb file and get a clear preview of all emails & other items with just a single click on mailboxes.
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …

821 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question