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.
For more information see Avoiding Server Names in SSL Certificates.
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.
Renaming your entire Active Directory isn’t necessary when you can run your Exchange namespaces on a different domain anyway. Just because your Active Directory is domain.local doesn’t mean you need to use that namespace for Exchange services. For more information see Avoiding Server Names in SSL Certificates.
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.
Note that the examples below were created in the Exchange 2007/2010 era, before Exchange 2013 was released. Also note that adding multiple websites and virtual directories is going to increase the complexity of your environment, making it more difficult to maintain and troubleshoot.
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.
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.
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.