Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1847
  • Last Modified:

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 "theircompanyname.com."

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)
- theircompanyname.com (public domain name)
- mail.theircompanyname.com (public URL for Outlook web access)
- autodiscover.theircompanyname.com

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 local.theircompanyname.com or corp. theircompanyname.com). 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,

Lloyd
0
wolfconsultinginc
Asked:
wolfconsultinginc
  • 3
  • 2
1 Solution
 
Cliff GaliherCommented:
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.
0
 
Cliff GaliherCommented:
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.
0
 
wolfconsultingincAuthor Commented:
@cgaliher,

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 "mail.theirpublicdomain.com" for the Outlook Web App service for both intranet and internet, and enter the same "mail.theirpublicdomain.com"  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 "mail.theirpublicdomain.com" 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 "mail.theirpublicdomain.com" 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.

Lloyd
0
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.

 
Simon Butler (Sembee)ConsultantCommented:
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 autodiscover.example.com (host name on the SSL certificate) or SRV records.

SRV records information: http://support.microsoft.com/kb/940881

Single name certificate use: http://exchange.sembee.info/2010/install/singlenamessl.asp

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.
autodiscover.example.com, owa.example.com, activesync.example.com, pop.example.com ews.example.com

Simon.
0
 
Cliff GaliherCommented:
Definitely not an SBS thing. In fact, SBS has a certificate wizard that, by default, is designed for a simple single-name certificate.

Yes, you can enter *just* mail.publicdomain.com into the certificate process. And yes, it can be a simple single-name certificate.

If you are setting up SBS and use the wizards, the DNS setup for the public name pointing to the private address is done automatically as part of the wizard. For your non-SBS networks, yes, you will want to add that step as part of your setup.

There is still the issue of autodiscover though. Outlook uses several methods to "autodiscover" the exchange settings. If you aren't using a UCC/SAN certificate and aren't setting up records for autodiscover.publicname.com, you will want to set up a SRV record on the *public* DNS host, wherever that may be. This is unnecessary for the internal private DNS network, as an Active Directory SCP will be used to locate the information.

The public SRV record, when configured properly, will allow users outside the network to easily configure "Outlook Anywhere" using AutoDiscover with no certificate errors or additional work. If you don't use Outlook Anywhere, then even this step is unnecessary.


Hopefully that better answers your questions.
0
 
wolfconsultingincAuthor Commented:
@cgaliher and @Sembee2,

Thanks very much for the replies and the explainations!

Lloyd
0

Featured Post

Configuration Guide and Best Practices

Read the guide to learn how to orchestrate Data ONTAP, create application-consistent backups and enable fast recovery from NetApp storage snapshots. Version 9.5 also contains performance and scalability enhancements to meet the needs of the largest enterprise environments.

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