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.

Background

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
Required/Optional: Required

9.2.2  Subject Common Name Field
Certificate Field: subject:commonName (OID 2.5.4.3)
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.

Namespace Support

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
Required/Optional:Required

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.

1. 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.
2. 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.
3. 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.