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 "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.theircompanyn
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
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
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.theircompanyn
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
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
Cliff Galiher
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.
ASKER
@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.co
And also, since they are all the same name "mail.theirpublicdomain.co
Thanks again, in advance.
Lloyd
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.co
And also, since they are all the same name "mail.theirpublicdomain.co
Thanks again, in advance.
Lloyd
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@cgaliher and @Sembee2,
Thanks very much for the replies and the explainations!
Lloyd
Thanks very much for the replies and the explainations!
Lloyd