I’ve been receiving more and more questions about SSL certificates from people who find themselves in a situation where they can’t get the certificates they need from a public certificate authority.
The scenarios tend to be either:
- they are using a DNS namespace that they do not actually own the domain name for
- they are using names that are no longer accepted by commercial certificate authorities due to changes in the rules for issuing certificates
Let’s take a quick look at an example of each of those scenarios.
Using a DNS Namespace You Do Not Own
I’ve seen this scenario occur a few different ways. In some cases the company uses something they thought was harmless and generic for their internal namespace, such as office.net, and then a public namespace of company.com. However, someone else already owns the office.net domain, so they are not able to register it.
In other cases the company used company.net internally, and company.com externally, but simply forgets to register company.net and someone else came along and registered it afterwards.
In either case because you are not the owner of the domain a public certificate authority will not issue you an SSL certificate for that domain.
Using a Name No Longer Valid Under New Rules
In this scenario a company uses an invalid namespace for their internal domain name, eg company.local, or uses short names such as webmail or even IP addresses for internal access to certain services, and wants to include those invalid names, short names, or IP addresses in their SSL certificate.
In 2012 the rules for SSL certificate issuance have changed. From Digicert:
The CA/Browser Forum, a collaborative effort between Certificate Authorities (companies like DigiCert that issue certificates) and Web Browsers (companies like Mozilla or Microsoft that manage trust on a CA level), has introduced new Baseline Requirements for certificate issuance.
As part of these new requirements, Certificate Authorities must phase out the issuance of certificates issued to either Internal Server Names or a Reserved IP Address by October 2016. Specifically, CAs cannot issue certificates to these internal names with expiration dates after November 1, 2015…
Essentially, this change in SSL standards will make it impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified as owned by the organization that is requesting the certificate.
Avoiding the Problem at Design Phase
For those who get the opportunity to design new Active Directory and Exchange environments from scratch the best advice is to avoid using an internal namespace that the company doesn’t own.
I recently saw a new AD/Exchange design that proposed a .local namespace and gave them that same advice. Even though it may have been possible for them to be issued an SSL certificate with .local names in it today, when that certificate expires it may not be possible to renew it.
Better to avoid the problem before the first domain controller is even promoted.
Resolving the Problem for Existing Organizations
For those who are already in the situation where they will not meet the new requirements for certificate issuance there are a few approaches that can be taken.
Renaming/Migrating Active Directory Domains
Digicert published some brief guidance on renaming Active Directory to resolve the issue. They also suggest considering a migration to a new domain that has a compliant namespace.
Personally I would not be keen to undertake either of those unless absolutely necessary. This is really a decision for businesses to make based on the number of things in their environment that would be impacted by such a change.
A migration may be less painful that a rename but I would probably lean towards doing that on the next upgrade project rather than rush it through immediately.
Using a Mix of Private and Public Certificate Authorities
More and more organizations are running their own internal PKI these days due to the increasing number of products that use SSL in their communication channels (not just Exchange, but also Lync and the System Centre family).
This makes it possible to meet your SSL requirements for non-compliant names using your private CA. The challenge though is to combine this with public CA certificates so that non-domain members (such as mobile devices) will continue to work correctly for external access.
Example 1
In this example you could use a private CA to issue the SSL certificate for the .local names, and a public CA for the public names (eg webmail.company.com). The public cert is bound to the ISA/TMG for external access, while the private cert is bound to the Exchange server itself. The ISA/TMG bridges the traffic between the two, with external clients unaware of the internal namespace.
Note: this is also a solution for those who don’t want the public-facing cert to have internal server names on it.
Example #2
Another approach is to create a second IIS website on the Exchange server (Client Access server) and create additional virtual directories for the external services such as OWA. You can then bind the public CA issued certificate to that IIS website, and the private CA issued certificate to the Default Website.
When combined with split DNS this allows internal and external clients to connect to services such as OWA by using the same name.
If an ISA/TMG server is also involved it would also have the public CA cert bound to it, and would publish external access to the second IIS website.
Summary
It is difficult to cover every scenario in an article such as this because there will be a lot of variables depending on the specific environment. Before you deploy any solution I do recommend that you thoroughly test it first in a test environment, or at the very least have a clear rollback plan if something unexpected occurs.
Hopefully though you can see that there are options that exist to allow us to work through these changes to the rules for SSL certificate issuance, without necessarily having to make a major architectural change to our AD/Exchange.
Further reading:
About Paul Cunningham
Actually i have learnt that i can use any internal name for my company, and if i want to have public name i have to choose one matches the world rules.
I mean would it be a problem to have my active directory domain (ABC.local)? , and if i wanted to have a public name i have to choose a name that hasn’t taken before by any company !
Is that what you meant or you mean to make the internal name like the external name (ABC.com) ?
If you think about E-mails, i can use hub transport Accepted domains for the external name and make an email address policy to change the E-mail addresses to the new extension (test@abc.com).
Do you think i am thinking right?
The internal/external namespaces can be different.
The point is that if you choose an internal namespace that doesn’t meet the new rules, or that you don’t own, then you won’t be able to get SSL certificates for those internal names (such as your Exchange server FQDN) from commercial CAs.
Aha, Got your point. But what should i do if can’t buy an certificate for my internal name space. i think i can use a local certificate authority or what is you opinion ?
Yes, thats when you can consider using your own private CA to issue the certs you need.
Hello Paul, I have an Italian student and I read with interest your post but I would like to ask you a question that might interest many users.
I would like to use a registered domain for testing laboratory for a school. You carry the sample data for the domain name, server, etc..
Can you tell me what names should I take to a CA for a certificate SAN (The CA may issue certificates .local and .it)
Internal Domain Name: scuola.local
Public Domain Name: scuola.it
Name Server Exchange 2010: cas-01
FQDN Server: cas-01.server.local
I would like to use the name OWA mail.scuola.it, is it possible? Or should it be cas-01.scuola.it?
Could you tell me all the names to be included in the certificate request.
Thanks
Antonino
I thought it was a best practice to have your internal and external namespaces different. Now its suggested that if you are creating a new AD forest/domain to go away from that and make them the same. Or rename your domain to a resolvable one. This makes no sense.
I assume Lync will be severely impacted by these changes as well.
Fewer namespaces are easier to manage, but that doesn’t mean that it is the right solution for all situations.
The main point is that you should not use namespaces that (a) you don’t own, or (b) are no longer valid under the new rules for SSL certificates.
Yes this will impact Lync and really any other product or technology where you need to acquire an SSL certificate from a public CA.
Hi Paul – Currently we have a default self signed server certificate which contains the name of the Exchange Server. However when we use OWA and OutlookAnywhere, unless we use the internal LAN Exchange server name in the OWA URL / Outlook Anywhere Proxy server settings, we get certificate errors eg for OWA the error is that the certificate is not trusted and for Outlook Anywhere the error is that the server name is incorrect…
And this will of course only work when on the local Domain…
NOW..I want to create a new Exchange Server Certificate, which contains my resolvable server name (eg the server name which is used in the EXTERNAL Public DNS namespace..)
In your posts you have said that only one certificate can be used by IIS, and I am wary of creating a certificate that affects my local Outlook clients…
Can I create a second Exchange certificate solely for OWA and Outlook Anywhere services and leave the IIS,SMTP services on the default server certificate
We have problems getting a CA issued certificate as there are too many requirements asked for by the Certificate Issuer we have tried so far…Also we would like to use the private CA route if possible…
Thank you for your feedback/comments on the above
Yes, only one SSL certificate can be used by an IIS website. OWA, ActiveSync, OA etc run off IIS.
SMTP can use the same, or a different certificate, that is up to you.
The solution is to use a SAN certificate. I suggest you start reading here:
http://exchangeserverpro.com/exchange-2010-ssl-certificates
That will tell you everything you need to know, including how to use a private CA if you choose to go that way.
Paul,
regarding “Using a Mix of Private and Public Certificate Authorities”, you mentioned Microsoft Firewalls ISA/TMG to bind the external certificate to (Example1 and also Example2).
What if you don’t run an ISA/TMG but an alternative firewall such as pfSense, Astaro or IP-Cop?
Should it also be configurable, or does the bridge-functionality resp. access chain EXTERNAL CLIENT -> FIREWALL -> CAS require some special Microsoft-only features?
Thanks in advance!
If you want to use a mix of private and public certs then your public facing reverse proxy needs to be able to do the SSL proxying like ISA/TMG. Some do, some don’t. It isn’t a Microsoft-only capability.
I ran into a similar situation during an Exchange 2003 to 2010 migration.
Someone thought it would be clever to use domain.AD as the internal namespace.
The workaround I used was to update the InternalURL properties of all of my CAS services to match the ExternalURL value.
The only real issue with this setup as it was necessary to maintain a split DNS zone internally for the external namespace to service clients connecting locally.
But that still seems like less work than maintining an additional CA, or renaming you production AD domain (Yikes!)
Just thought I’d throw that out as another possible workaround.
Thanks!
This also worked for me. We had a ‘.local’ internal namespace. We also had an internal DNS entry for our mail server’s external (.com) name which pointed to the server’s internal IP address. I used a non-SAN (i.e. basic web server) certificate from a public cert. authority for IIS/HTTPS, and my local certificate authority for everything else. By updating the Web Services Virtual Directory Internal URL and the Autodiscover Service Internal URI from the shell (as well as setting all of the CAS URLs in the GUI) I was able to allow OWA and EAS to function properly both internally and externally, and Outlook clients to connect without getting those pesky certificate popups. Thanks!
Another alternative is to use a Layer 7 load balancer with SSL offloading. It is similar to the TMG example. In this case the virtual directories are configured not to require SSL and the ‘internal’ leg of the connection is transmitted insecurely – however we DO trust our internal network, so that’s not a problem is it?
It is a complicated topic. An IIS website can only have one certificate bound to it. IF SSL is required, the namespace configured on each virtual directory must be included on that certificate and that certificate must be trusted by the client. Outlook clients will access several virtual directories including Autodiscover, EWS and OAB (and possibly UnifiedMessaging too). If you get just one wrong, you can get a certificate warning message.
Some companies trust their internal network enough to not use SSL internally. Some do not. That is up to you. Personally I prefer to use SSL internally.
Can i verify something (as we want to use SSL for activesync):
We use domain.local – locally.
External email and website domain used is do-main.co.uk
How best to proceed with activesync and godaddy cert?
Thanks
Two options:
a) Use a reverse proxy like TMG or other, so that you can have a public-facing SSL cert with just the public names, and then use your own CA for the internal SSL cert that is installed on the Exchange server itself.
b) Reconfigure your Exchange virtual directories to use the external namespace for both InternalURL and ExternalURL, and use split DNS (refer to Joseph’s comment above – http://exchangeserverpro.com/ssl-requirements-for-exchange-when-certificate-authorities-wont-issue-certificate/#comment-14968)