Link to home
Start Free TrialLog in
Avatar of Wolf Consulting, LLC
Wolf Consulting, LLC

asked on

SSL certificates for Exchange Server 2007/2010 when domain is .local

Hello. I am looking for a little help with Exchange Server and SSL certificates.

I run a networking and IT consulting firm. Many of our clients run Microsoft Small Business Server (SBS) and run the included on-premise Exchange Server.  Other clients run NON-SBS servers and also have on-premise Exchange Servers.  It has been our standard company practice to always name the local activate directory domain name for each customer to be "theircompanyname.local", so that it is separate from any public facing DNS (for websites, OWA, etc) for ""

Since Exchange Server 2007, we have been getting UCC SSL certificates from GoDaddy.  We typically include the following names in our UCC (Unified Communications) SSL request.  I sometimes also hear/see this called a SAN (subject alternate name) certificate.
- servername (local NETBIOS server name)
- servername. theircompanyname.local (local server FQDN)
- (public domain name)
- (public URL for Outlook web access)

I honestly can’t recall the details of how or why we started using all of those names in the certificate/request,  but it has been our standard practice for many years.

Now it is my understanding that Certificate Authorities (CAs) have accepted worldwide guideline changes, and will no longer issue SAN SSL Certificates that include any invalid Fully Qualified Domain Name (such as .local), effective November 2015. We have already run into issues with this, as we are no longer able to request multi-year certificates that go beyond the November 2015 date. (ie a one-year cert request works, but a 3, 4 or 5 year cert request fails).

We are having internal discussions about our practice of using .local for internal domain names (and are considering other common scenarios such as subdomains (such as or corp. So for those future networks, I may have a different workaround.

But we have 80+ networks for 80+ existing customers, that are mostly setup using "theircompanyname.local" for the local domain name.  We have to somehow get SSL certificates for these Exchange Servers, and we will NOT be able to include any reference to “servername“ or “servername. theircompanyname.local” in the SSL certificate request.

SO my questions is.... What is the best/correct method for requesting an UCC/SAN SSL certificate for Exchange Server 2007 and Exchange Server 2010, when the local Windows domain name is “theircompanyname.local”?  

Do we just exclude any reference to the “servername” and “servername. theircompanyname.local” in the SSL cert request?  I guess we could try that, but I have to assume that we were including those for a reason in the first place?

Do we make a change somewhere on the server so that it does not depend on any references to “servername” or “servername. theircompanyname.local” being in the SSL certificate in order to function properly?

Any advice and suggestions would be greatly appreciated.  Thank you in advance.

Warm Regards,

Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

Often those extra names are included because someone got advice they "read on the internet." In common deployments, you only need one or two names, the first is the public name you want the CAS to use for OWA and EWS. Optionally, the second is the autodiscover name, but if you use a SRV record to redirect autodiscover, you don't even need that, so you don't even need a UCC/SAN certificate. The other three names, unless you are doing something very strange, are not needed and no special changes need to be made to exchange.
Considering the price of a single name cert is around $10, you can even buy one as a test and chalk up the cost as a business learning expense to verify this works as expected. If your margins are so thin that you cant spend $10 to learn whether a technique will work for 50+ clients a .50 cent per client experiment) then it is time to look at your pricing model.
Avatar of Wolf Consulting, LLC
Wolf Consulting, LLC



Thanks for the responses. I am happy to try anything, and spending some money to determine a workable solution (especially one that can be applied to all of our clients) is certainly no issue.

As I mentioned, I am not really sure how we developed the practice of including all of the names for the SAN/UCC certtificate. Perhaps it was an SBS thing?

Just so that I fully understand your solution, I beleive you are saying that.... when we request the certificate, we can enter "" for the Outlook Web App service for both intranet and internet, and enter the same ""  for Web Services, Outlook Anywhere and Autodiscover names, and I suppose create a DNS record on the local LAN DNS server so that the host name "" when on the local network resolves to the local IP address of the Exchange Server, am I understanding correctly?

And also, since they are all the same name "" for all of the services, that we dont even need the UCC/SAN certificate and can just by the cheaper cert for a single name?

Thanks again, in advance.

The previous advice given was to include:

common name, FQDN of the server, netbios of the server, autodiscover and sites.

This covered all eventualities including where the internal name was used for things like autodiscover.

With the change in SSL certificates forthcoming, using internal names isn't possible. It is possible to get down to two names on the certificate and IF and only IF the external DNS provider supports SRV records then you can get it down to a single name certificate.
That is because you need to cover autodiscover in some way.
Autodiscover can work with either (host name on the SSL certificate) or SRV records.

SRV records information:

Single name certificate use:

There is still a case for UC certificates though. A number of clients will use seperate name spaces for each service, so that troubleshooting becomes easier.,,,

Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
@cgaliher and @Sembee2,

Thanks very much for the replies and the explainations!