A restriction to public certificates was introduced several months ago that could affect your planning of a Microsoft Lync, Exchange, or other application service deployment. While this change restricts only public certificates that contain an internal name with an expiry date after November 2015, you should be aware of this change for planning and certificate renewal purposes.
The Change: No Public Certificates with Internal Names Allowed
In a nutshell, the change will mean that Public Certificate Authorities (e.g. GoDaddy, DigiCert, VeriSign, Entrust, etc..) will no longer issue public certificates that contain an internal only name – i.e. a name that cannot be publicly verified. For Microsoft Lync and Exchange this equates to not allowing public certificates used on servers that have an internal (private) AD suffix – e.g. domain.local.
Note: before this restriction, many public CA’s frowned upon this type of certificate, and wouldn’t issue them anyway.
The specific requirement for this change can be found in the CAB Baseline Requirements document here: https://www.cabforum.org/Baseline_Requirements_V1.pdf. Section 9.2.1 details the requirement: “
“….the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name”
The CAB is a voluntary organization of certification authorities (CAs) and web browser vendors.
This restriction is targeted at certificates with expiry dates after November 1, 2015, but apparently some Certificate Authorities that previously did this are already rejecting these types of certificate requests. Any of these types of certificates already issued will be good until their expiry date however. The CAB specification states that “the practice will be eliminated by October 2016”.
What Does it Mean for Microsoft Lync and Exchange?
While not common-place in Lync and Exchange deployments, it was sometimes used in deployments with two namespaces – one public (domain.com) and the other private (domain.local) with an associated split-brain DNS deployment – as a useful solution to a couple of challenging Lync and Exchange authentication issues.
For example, in Microsoft Lync, using a certificate that is signed by an internal Certificate Authority will present problems for any client that does not trust the private CA certificate chain. This includes any non-domain joined Lync clients or Lync Phone devices that could not download the internal certificate. The issue was amplified with the introduction of the Lync Mobile clients which would sometimes connect internally via the Lync autodiscover service but did not natively trust an the internal CA.
Lync MVP Jeff Schertz nicely details how this issue is magnified in Lync Server 2013 with the introduction of more Lync clients that depend on the Lync autodiscover service, and concludes:
“The first solution would be to simply start issuing public certificates to the internal Lync servers but this approach may not work for all environments as many third party certificate authorities will not allow certificate requests which contain internal-only domain names”.
Several Public CA’s, such as DigiCert, did allow public certificates with internal names, and it made for a simple solution to these types of issues. Jeff offers some updated guidance (in his blog entry) which does not require a public certificate with an internal name for this situation.
I have had other Microsoft Lync and Exchange authentication issues that were nicely solved with a public certificate that contained an internal name. So why was it frowned upon?
What was the Issue with these Types of Certificates?
While public certificates that contained internal names simplified some deployments, it was somewhat frowned upon because it was seen as a potential security risk:
- It is generally not a good security practice to put internal names on things that are meant for public purposes; even if they are used for internal only services.
- A potential security risk – in theory at least – that went along the lines of:
- A hacker (aka bad guy) finds out the internal name (e.g. domain.local) used inside a company (e.g. through some sort of network access) by looking at the certificate.
- The hacker goes to a CA and acquires a public certificate issued with this internal name on it (e.g. domain.local).
- The hacker then set’s up a rogue version of a popular application service using this certificate that accepts user authentication attempts (user name and passwords) – for example, a network service that mimics Lync Server on port 5061.
- The hacker then get’s corporate users to logon to the rogue network service (via DNS poisoning, DHCP impersonations, etc…).
- This allows the hacker to collect user names and passwords.
As someone pointed out to me, a hacker could achieve the same thing with an internal certificate that they issued themselves with their own internal CA – with the exception that users will have a chance to opt-out from connecting because they will get the “…this certificate is not trusted” warning – but 90% of users would accept that warning if it meant getting at their Outlook email.
Nevertheless, restricting certificates of this nature is more secure.