Let’s start here: It’s not your fault. No, really. You were unfortunately misdirected for a number of years and now you’re “stuck” with a .local domain.
This has been “fine and dandy” for a number of years, but is no longer the case. Maybe a brief recap would be helpful:
When Active Directory first became “a thing” 15 years ago, there was not great direction for how to properly name your fully qualified domain name (FQDN), so many people just chose <domain>.local for their Active Directory. Even today many active Microsoft KB Articles have directions to use a non-public TLD (like a .local name) today. The primary reason that the .local even became a thing was to easily administrate and separate public and private namespaces. In separating your private namespace to a .local, there was a clean break between private and public DNS zones. DNS “split brain” is possible, but in early days (even today I guess) you have to be exceptionally careful with DNS entries and change control.
The Problem
The actual problem with this began years ago but has recently gained traction and attention. One early problem with .local as a private name space was with Apple/Mac computers and their use of the Rendezvous (now called Bonjour) protocol. It uses the .local domain for its own purposes for service discovery and usage.
The .local conflict between Apple and Microsoft is well documented and often the cause of IT Holy Wars so we won’t recap it here. The current major issue with the .local domain is related to SSL certificates and “subject alternative names.” For the last seven or eight years, a common practice among many people has been to purchase UCC (or multi-SAN) certificates. These certificates may be utilized for securing multiple services with multiple FQDN. For example: in Microsoft Lync, you may be presenting a web service with a <domain>.com FQDN but that same certificate may have an Active Directory joined machine requirement with a <domain>.local need. You could buy that certificate from GoDaddy or Comodo or Digicert without issue. In 2011 that all changed.
You can read more about that here (focusing on Section 9.2.1). The basic summary is that getting certificates with non-public domain names (like .local) is a problem, and has been a problem for years.
Today’s Reality
You can no longer get a public SSL certificate with .local as a subject alternative name. The D-Day for this is October 31, 2014. If you happen to have a certificate in play, it won’t stop working. You won’t be able to renew it or purchase anything new and it will be forcefully revoked on November 1, 2016.
Will this affect all companies? No. But it definitely has implications with Exchange and Lync and as time moves on it will affect more and more applications. You need a plan. This plan will potentially be a painfully disruptive solution, or, could potentially just focus on administrative processes to get you by.
Moving Forward
You basically have three options.
- You can do nothing. Your world won’t stop turning. But, you will still need to plan on how to utilize your .local domain and any .local FQDN needs as it relates to SSL certificates. For regular Windows machines joined to an Active Directory – you can just utilize local CA/PKI solutions. Group policy can push certificate trusts. However, your non-domain joined machines, like mobile devices or perhaps that bring-your-own-device initiative may now become more complex. You’ll have to address certificate trusts in a different way.
- You can rename your domain. Microsoft has a process in play to allow you to rename your Active Directory to another namespace name. The problem is that almost no one can really do this. If you have Exchange, or Lync/OCS, or SCOM, or some SharePoint services in play – a domain rename isn’t possible.
- You can move to a full greenfield. Build up a new Forest/Domain and migrate away from .local to another namespace that IS a public FQDN and NOT subject to the same SSL challenges detailed in that CA/Browser forum document above.
Remember: you are not alone. It’s not your fault. It is; however, your new reality. Mirazon has the experience to help identify if you have a potential risk here and can help you plan and execute a going forward solution.