The average human interpretation of the Mayan calendar may have proven grossly inaccurate regarding the significance of the date of December 21, 2012 but there is now a new date to be genuinely concerned about which will actually have a real impact on at least some of our lives: November 1, 2015.
As pointed out on a few other blogs, like this article from fellow Lync MVP Curtis Johnstone, there will be some changes to how public certificates will be issued by most public certificate authorities. Be aware that although that date is still a few years away any public certificates requested today may already incorporate these modifications.
Before getting into what the changes are and how they will affect Lync Server deployments (and Active Directory design in general) it would be prudent to understand where they coming from and who will be enforcing them.
Basically there exists a voluntary organization called the Certificate Authority Browser Forum (or CA/Browser Forum for short) which is comprised of many leading public certificate authorities (e.g. Comodo, Digicert, Symantec) and Internet browser vendors (e.g. Apple, Google, Microsoft). Representatives from these companies work together to publish an agreed upon set of standards that each member adheres to in the spirit of providing secure communications throughout the Internet.
The latest agreed upon set of standards was recently published and adopted by these members as the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificate, v1.0. Within this document are two very important changes to how certificate requests will be handled which can or will impact Lync Server deployments for some organizations based on their current Active Directory namespace configuration. The first change limits the scope of accepted namespaces in the subject fields and the second change actually inverts the importance of the Subject Name (SN) and Subject Alternative Name (SAN) fields.
Subject Name Fields
The change which will have a lessor impact is that certificates issued which are compliant to this specification must always contain a Subject Alternative Name field, while the Subject Name field becomes optional. This is a complete reversal from previous practices where the certificate’s Common Name (CN) (e.g. server.domain.com) was included as part of the Distinguished Name (DN) defined in the Subject Name field, yet the SAN field was optional, and often for an additional cost. (Note that although CN and SN are often used interchangeably the CN is actually part of the SN.)
Looking at the CA/B Forums’ requirements document the following statements are highlighted in sections 9.2.1 and 9.2.2 which outline this shift in subject name usage.
9.2.1 Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
9.2.2 Subject Common Name Field
Certificate Field: subject:commonName (OID 18.104.22.168)
Required/Optional: Deprecated (Discouraged, but not prohibited)
Note that the SAN field is now listed as a requirement and the Subject Name field is defined as optional. Although the SN field is deprecated it is still being included in certificate requests today from the participating CAs. By definition of the word this indicates that sometime in the future the SN field will become obsolete and be dropped entirely, but probably only after all software vendors have been able to update their products to work with that type of certificate configuration.
So this in itself should not pose any risk to past or future Lync Server deployments as all clients and servers already support both field types and for the foreseeable future both fields will still be included in public certificates. Microsoft will need to do some testing to find out if any services or communications will break in the event that the certificate contains only a SAN field and no SN field though, and adjust their product accordingly. But there is no known defined timeline on when the Common Names will be dropped from public certificates across the board.
The second and more important change is also defined in the SAN field definition but it requires a little closer reading to understand and fully appreciate the gravity of the statements.
9.2.1 Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an IP Address containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IPaddress or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate.
Wildcard FQDNs are permitted.
As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, 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. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name.
There is a lot going on in this section, so it is easier to understand by breaking down each highlighted portion.
- The CA must validate any and all domain names included in the certificate request. Some public CAs have already been doing this for some time, but others have not. Starting from the adoption date reflected in the requirements document (July 2012) participating public CAs will no longer issue a certificate to a requestor if any of the domain names defined in the certificate request cannot be validated. This validation process typically involves the CA performing a WHOIS lookup on the domain name to leverage the contact information for a validation email or phone call.
- The CA shall notify the current owners of any valid certificates which do not meet these new requirements will no longer be allowed after October 2016. Basically this means that CAs need to inform their customers that practices are changing and they will need to update their usage and design to be compatible with future certificate requests.
- The CA shall not issue a certificate which does not meet these requirements which would expire after November 1, 2015. In short this means that if a certificate is requested today for one or two years then the previous configurations may still be allowed by that CA. But if a 3 year certificate was to be purchased today, placing the expiration date after November 1st 2015 then the CA will not allow the use of any domain names which cannot be validated.
So what does this all mean? On the surface it all looks like a good idea, providing for additional security and preventing the use of domain names which cannot be proven to be owned or managed by the requestor.
The key concept to understand is though the impact this has on organizations still using internal namespaces which cannot be validated. There are still many Active Directory forests in operation which utilize invalid DNS Top-Level Domains (TLD) like .local, .domain, .corp and so on. These namespaces cannot be registered with a Domain Name Registrar and thus certificate authorities have no method to prove the validity of these internal-only namespaces.
For some time now it has been a general Active Directory best practice in the field to no longer use these pseudo TLDs in internal deployments and instead use one of a couple different solutions. Even the examples used through this blog site do not reflect these newer best practices (e.g. schertz.local and mslync.net) but all internal server certificates have always been issued by a Windows Enterprise CA which clearly does not need to conform to the changes that public CAs are adopting.
One option is to still go with a disparate namespace configuration retaining the public name as external only (e.g. contoso.com) but to select a valid internal domain name (e.g. contoso.net) and then register that name with a public registrar. The domain name does not need to be used externally and may contains no actual DNS records (expect maybe a www redirection to the real public namespace if desired) but it does exist and includes a valid contact in the registrar records so a public CA can validate the ownership of that domain name.
Another option is to utilize a Split-Brain DNS approach where the same namespace (e.g. contoso.com) is used as both the internal AD domain namespace and the public namespace. This approach is becoming more common although there is some additional overhead in managing separate DNS zone database for internal and external records.
The benefits or drawbacks to either approach go far beyond the scope of this article and it is a topic which can be highly debated among IT professionals. In reality one solution may be ideal over the other for a given organization so there is not always a simple answer as to which is better. Future articles on this blog will reflect new example namespaces as a new AD forest and Lync Server 2013 deployment will bring the opportunity to select a new approach. For the sake of simplicity it would be ideal to just use mslync.net for both internal and external namespaces, but this often obfuscates the domain name and does not make it immediately apparent to the reader which namespaces (internal or external) is being referred to without specifically calling it out.
Impact to Lync Server
Everything discussed up until now covers design theory in detail, which is great for planning new deployments or environments, but what about existing environments which cannot be modified? Performing a complete Active Directory migration (or worse yet the dreaded domain rename) for the sole purposes of ditching an internal-only namespace is typically not feasible.
As covered in this previous blog article Lync Server 2010 and 2013 introduced new client architectures for Mobility and 2013 clients which adds some complexity when dealing with the balancing act of namespaces, certificate trusts, and device management. If locked into internal namespaces then using public certificates on an internal Lync server will no longer be possible, meaning that all devices will need to trust the internal certificate authority. This is easy for domain-joined workstations but not as simple when dealing with the wave of impending bring-your-own-device workforces. If public namespaces are used internally then the internal servers can utilize public certificates on all roles, allowing pretty much any device the ability to trust the registrar and web services roles on any internal Lync server.
But most importantly any environments out there still running internal-only namespaces which do not have their own internal certificate authority are going to find themselves left out in the cold very soon. As Microsoft works through defining new best practices with the product group, field engineers, partners, and customers one might expect to see some form of official documentation in the future outlining new recommendations along this topic.
26 thoughts on “Lync Server ‘Certificate Cliff’”
Jeff, there is another option for naming the AD, this is to use and internal subdomain e.g. ad.contoso.com, which is what Microsoft recommend since at least Windows 2003 http://technet.microsoft.com/en-us/library/cc7559… and http://support.microsoft.com/kb/909264
Yes, that is another configuration that would be valid as it would share the validated, public namespace but not be a true split-brain DNS configuration. Most often these deployments would use an empty root domain (which is also no longer recommended) which would itself be a split-brain zone of the public root name. In practice I've seen this approach used the least of all options though.
> By definition of the word this indicates that sometime in the future the SN field will become obsolete and be dropped entirely
I would disagree that SN field will be dropped entirely. New requirements affects only SSL certificates, while other certificate types still may rely on SN field. Moreover, CAB Forum is not an IETF.
> Microsoft will need to do some testing to find out if any services or communications will break in the event that the certificate contains only a SAN field and no SN field though, and adjust their product accordingly.
they do not need. Currently almost all network services behaves as they should when we are talking about certificate-based authentication. Also, RFC5280 defines the behavior of SN and SAN, so I would not expect any changes in near (within X.509 V3) future.
That statement is my own speculation, but if you look at the definition of the terms used in the specification then you can see the writing is on the wall. Besides, once the SAN field becomes primary there is no need for a secondary name field as that parameter can store one or more values. And yes the CAB forum is not creating industry ratified standards, but if all of the major players in this space are agreeing on these specifications then the rest of the industry will need to follow suit and adapt. And all software and hardware vendors will most certainly need to do their own testing to make sure that their implementations are not impacted by certificates formatted differently in the past (e.g. no SN field). Just look at ISA 2006 prior to SP1 for an example of that (or Lync 2010 + Exchange 2010 UM integration with a SAN cert as another example). I agree, the dropping of the SN field is less of a potential impact in the near time, it is the changes to allowed namespaces which is the most important point in this article.
> But there is no known defined timeline on when the Common Names will be dropped from public certificates across the board.
because it won't happen in X.509 profile V3.
> There are still many Active Directory forests in operation which utilize invalid DNS Top-Level Domains (TLD) like .local, .domain, .corp and so on
invalid??? It is one of the supported way to differentiate internal and external domains and name resolution method. Of course, it is not very useful, but still valid practice. Disagree with your statement.
By definition any undefined Top Level Domain is invalid in the sense that it is not Internet-resolvable. Yes there are many environments out there still using this approach and will continue to, but it's not been a suggested approach for quite sometime. I've used it as a simple way to differentiate between internal and external namespaces for instructional purposes, but if you look at Microsoft's own examples now they tend to use .net for internal names and .com for external. Although not as obvious, this does provide for some continuity across their product documentation.
Lync MVP Article Roundup: January 2013…
Lync MVPs are a fountain of deep knowledge on Lync Server. But keeping up with the dozens of great articles…
Thanks Jeff. This has us worried as all our domains were set up years and years ago when .local was the recommended method. Oy. Looking forward to more on this topic. And thank you for keeping internal and external namespaces separate in your blog posts… It's extremely frustrating to try and follow other blogs (including much on TechNet!) that does not make that distinction clear…
Thanks Wes, I haven't yet decided what namespaces I'll use for my new 2013 lab but I'll definitely not use split-brain, so there will be a clear delineation between internal and external namespaces.
When I deployed Lync 2013 I had to deal with this – we have a .local domain because we had previously dealt with the split-brain DNS scenario which was a pain. My public CA warned me about the .local requirements. I was able to get our system up and running after some tinkering, and thankfully, the "internal" and "external" certificates are easily separated in Lync 2013.
Preston, are you saying you issued a trusted Internal certificate from your OWN CA and then the public one for the public space? Or did you find a way to actually work aroung the issue by requesting a public cert without the .local domain? This is crazy, UC certs are expensive and as far as I can tell it's a minimum of 6 names. However with one of them being the .local domain, it won't be valid in a few years? How did Microsoft miss this design issue?
This isn't a problem with Lync, it has to do with internal networks still using invalid top level domain namespaces which is a practice that has not been recommended in a long time.
> And yes the CAB forum is not creating industry ratified standards, but if all of the major players in this space are agreeing on these specifications then the rest of the industry will need to follow suit and adapt.
arguable. Digital certificates are not only SSL certificates (while CAB forum deals only with them), so there are no expectations to change PKIX profile. As I already said, PKI standards are defined by IETF (and other organizations like ISO and so on) and they define X.509 certificate structure and processing rules. And they will never change anything in the standards tracks due to changes in particular application (or certificate type).
> but if you look at Microsoft's own examples now
while Microsoft may change their own vision, there still will be a lot of networks that follow previous recommendations and everyone has to deal with this, so this point makes no sense for me.
> Just look at ISA 2006 prior to SP1
I meant modern applications. Older may have issues here. But is ISA 2006 RTM still supported by Microsoft?
Appreciate your input here, but I can't answer for what CAs and Microsoft may/may not do in the future. I'm simply extrapolating the data provided in the documentation published and providing guidance specific to Lync. There is always more than one way to skin a cat.
What guidance are you seeing with certificate guidance moving forward, I'm about to embark on a deployment that is very tablet (ios, surface) heavy so I want to make sure that everything works inside and outside the network. Would you still recommend the hairpin solution through the reverse proxy or should I put a public SAN on my internal interface?
Hairpinning internal clients out and back through a reverse proxy is not recommended as it will mess up all internal Lync 2013 client connections. So either go with a public cert on the internal servers (if possible based on your namespace configuration) or plan to deal with pushing private root certs to all internally-connected devices.
[…] http://blog.schertz.name/2013/01/lync-server-certificate-cliff/ […]
[…] prevent the ability to issue public certificates for those internal services, as described in this previous article. The primary SIP domain namespace will continue to be mslync.net throughout all […]
Could you please take a look at my problem?
My aim is to correctly set Lync 2013 Environment.
OWAS (Web App Server)
I want to have mobility with autodiscover. I prefer to use certificates with following settings, is it correct and will work as expected?:
On the FrontEnd I would like to request (to internal CA) one certificate for ‘Server default’ and ‘Web services internal’:
Additionally, for external user access my approach assumes that I will request for ‘Web services external’ such SANs:
I would like to use second (external certificate) on FrontEnd and on the Reverse Proxy for two purposes: FrontEnd external services and OWAS.
Do you think this is possible and supportable?
Do I need to have separate IP address for OWAS external acces?
Thank you in advance!
It sounds like it might work but I haven't tested that configuration, and I can't comment on if Microsoft would support that (possibly not as they've not tested it either).
I'm finishing up a Lync 2013 install that I started months ago, luckily I found your article before buying certs, so it should save me time/money.
The question is, what's the best way to request the certs? If I use the Lync 2013 Certificate Request Wizard it is wanting to put SAN names with our .local domain in them, which will cause problems with the 3rd party CA.
Previously I've used Exchange Powershell or MMC to create a CSR, is that recommended, or is there a better way?
PS. What happened to part 3 of your Lync 2013 Install? The first 2 are very useful!
Using the Certificate wizard is the preferred route, and it it adding those .local entries because they are part of your topology. You can't simply omit these names from the certificate request as the server will not function correctly. You need to change the entire configuration of the server (and potentially the domain) to move away from the .local namespace, which is not very realistic. In these cases you are better off deploying an internal Enterprise Windows CA to provide internal certificates.
We are also facing the problem with non-domain-joined byod (Android, iOS etc) connecting to our Corporate WiFi. We will try to mitigate the issue by setting up a new DNS which is only used by our BYOD-SSID and that DNS will not contain the lyncdisconverinternal-record. The DNS will only be used by BYOD-SSID so this will not affect our other internal-clients.
If that does not work to our satisfaction we will try to solve it by fronting the everything with our Netscaler ADC's and have some clever rulessets there.
What are your thoughts about this?
[…] single namespaces to allow for the use of public certificates where desired, as described in this previous article. A joint Active Directory and primary SIP/SMTP namespace of jdskype.net is used throughout […]
Jeff, thanks for this article. It is the only one I could find that addresses the cert issue with Lync. Can you clarify the process for me a little? I got a bit confused at the the Editor’s Note saying that the section is no longer valid. We are using Microsoft Lync 2013 at our office. We have 2 frond end servers, 2 persistent chat servers, two edge servers, 2 mysql servers, and IIS-ARR server and 2 Kemp Load Balancers for our Lync environment. All of this was set up prior to my coming on board and our certificates will be expired soon.
We are using a .local naming scheme for the FQDNs and will need to make the change on our certificates. However, I don’t quite understand what the process will look like. I can’t change the domain and wanted to use the method of using both private and public certificates but now it looks like this isn’t recommended. Can you break it down for me as to what needs to be done? If you need more information I can provide this as well. Thank you.
Raymond, the only available option in your scenario is to use an internal CA to issue a certificate to the Front End server. You cannot split the certs among roles as even the Web Internal/External services will need to include the server FQDN in their assigned cert, which cannot be performed with a public cert.