November 1st, 2015: New Rules Coming into Effect
Your friends at SSL.com would like to let you know that beginning November 1st, 2015, some very important changes regarding what can be covered in SSL certificates are taking effect:
- New certificates containing internal names will no longer be issued by any certificate authority following the CA/Browser Forum guidelines (i.e., all reputable ones)Note that for some time now SSL.com has not been issuing intranet certificates to internal names with expiration dates past November 1st, 2015 and thus SSL.com customers should not encounter any immediate issues- however, we strongly encourage you to double check your certificates for potential ways these rulings may impact you.
- Existing certificates containing internal names will not be RE-issued after November 1st, 2015.Again, SSL.com has worked to make sure you won’t have problems due to this – however, we’ve presented a worst-case scenario for your edification below.
- Existing certificates containing internal names will be AUTOMATICALLY REVOKED on November 1st, 2016.This is a catch-all policy, as some security architectures may have long-existing legacy certificates that do not observe these rules.
These changes mean that email – the internet’s first and still most useful tool – may be negatively impacted by changes, particularly if you are using Microsoft’s Exchange Server (which market research suggests is 63 percent of y’all). Thus your security architecture could start being impacted starting this coming All Saint’s Day.
Are you ready?
What Do You Mean When You Say “Internal Names”?
The simplest definition of an internal name is any network identifier that’s part of a private network and not reachable using a name using a top level domain (TLD) or unique IP address. By implication, any network ID that is publicly registered with a central authority such as ICAAN will be usable in certificates
In the earlier, simpler days of the internet an internal DNS architecture only had to worry about avoiding a limited set of TLDs – thus, AwfulBigCo.com’s intranet could support not only ABC.nyc and ABC.london but 1600.pennsylvania.ave, mail and Gandalf . Furthermore, some ranges of IPv4 and IPv6 addresses are set aside for purely local use – these reserved ranges include “192.168.*.*” for routing and 10.*.*.* for local networks. Securing intranets with SSL certificates is of course a Good Idea, and until the new ruling, any network admin could request and receive a certificate that included any of these.
Starting November 1st 2015, this will no longer be the case – certificates will no longer be issued – or, crucially, RE-issued – which contain internal names. These new rules are designed to both improve security and allow for proper use of new top level domain names (for instance, both .london and .nyc are public TLDs now). However, they do require any Exchange user to take a hard look at their network and security setup and make changes to acknowledge these new rules. Since many Exchange security designs have historically utilized internal names, this may cause serious issues with your mail service when and as your certificates expire, since new certificates with internal names cannot be issued to replace your existing ones – worse yet, any multi-domain certificate containing even one internal name will fail at renewal, potentially exposing your mail traffic to malicious exploits.
Failing to do this may negatively impact your mail traffic, your business and/or your reputation.
Sounds Dire.
It could very well be – it truly depends on how prepared you are. This could be a very easy problem to miss, and the consequences could be absolutely fatal to your business – if you fail to act ahead of time.
Example: Robert Dobbs is a senior sysadmin for AwfuBigCo. Among other jobs, he (theoretically) manages the corporation’s security certificates. However, those have been set to autorenew every November 2nd – which has been happening like clockwork since long before Bob got here, and he never even sees the invoice. Somewhere back before Dre’s comeback album, AwfulBigCo’s network architecture was configured to include four Exchange servers named “abc.exchange”, “Mail”, “Mail2” and “Gandalf”, plus an internal IP address (10.10.10.10) set up for secure FTP backups and two servers used for the London and New York development teams. They’ve been protecting their Exchange servers AND their other domains with one UCC certificate containing the following entries:
*.awfulbigco.com
*.awfulbigco.co.uk
awfulbigco.london
awfulbigco.nyc
abc.exchange
Gandalf
Mail
Mail2
10.10.10.10
November 2nd, 2015. Bob gets a phone call from Elaine in International Fulfillment – she’s having problems with Outlook. While he’s talking her through checking her settings, he gets a text from Nathan in the UK branch – some of the images on the website are broken and the order form’s timing out. Then another text from a VP of Marketing wanting to know why his demo in Singapore just cratered in front of a boardroom of potential investors…And believe it or not, Bob’s day is going to get much, much worse before it gets better.
See, AwfulBigCo’s certificate provider ran their request past their robots, detected those internal names and (per the CA/B Forum rules) declined the renewal.
This is a problem. The UCC will NOT be renewed and not only will services using the diallowed internal names (i.e., all corporate mail and the FTP backups) no longer be protected – neither will any OTHER domains included in the UCC, such as the primary and .co.uk domains for AwfulBigCo.
Sure, this is an extreme worst-case scenario – but we truly believe that full security depends on preparing for exactly that.
Okay, I am Legit Scared – What Do I Do Now?
If you are using internal names in your SSL certificates, you WILL need to take measures to address this, and the sooner the better.
Basically, there are a few options you can choose:
- Reconfigure the system to use only publicly-registered domain names.
This is probably the best solution – it makes the internal name issue moot and will be simpler overall to maintain and extend going forward. Unfortunately, this option will likely require considerable work up front, but Microsoft Exchange servers can be set up to use fully qualified public domain names (and this CA/Browser Forum white paper tells more about implementing FQDNs in Active Directory networks). Administration after the changeover will almost certainly be as simple or simpler than before (a big plus for Bob) and going forward AwfulBigCo will be able to use publicly trusted certificates to secure all traffic both internally and externally. A possible drawback to this method is that it may allow information about a company’s internal infrastructure to be discovered via DNS, but savvy configuration of DNS zones can help address this – for instance, using subdomains like “internal” or separate domain names and limiting resolution of these outside of company networks. - Register internal names as FQDNs.
Unfortunately, not an option for that reserved IP address, and “Mail” and “Gandalf” of course are right out. (We’ll assume for the sake of Bob’s sanity that the .com and .co.uk domains are already safely registered – his day is tough enough as it is.)
Also, even if abc.exchange is available – and remember that .exchange is one of the new TLDs whose introduction is helping to drive this rule change – it could well be squatted upon and only available for an exorbitant price- easier and cheaper alternatives are likely available. - Set up an Enterprise CA
This is a method already employed by truly large entities who need to secure primarily internal communications. An enterprise CA serves as a corporate certificate authority – essentially, instead of the chain of trust running up to an external CA, all certificates are ultimately secured by an internally-generated root certificate.While this does give greater customization (and would allow Bob to maintain the legacy naming structure AwfulBigCo has in place) there are serious security issues to consider – a Sony-style hack could expose the enterprise root certificate and/or private key, allowing almost unlimited exploitation of the network. Also, certificates issued in-house will NOT be trusted elsewhere – this is a method that secures internal communications but cannot extend trust beyond the walls of your business network. Finally, setting up an enterprise CA is by no means an overnight solution, and might be much more difficult that the other options listed here, and thus only viable for very large (or growing) networks.SSL.com is happy to offer consulting and management services to help you negotiate the path to setting up your own Enterprise CA – just send a message to enterpriseca@ssl.com and one of our senior administrators will contact you soon. - Use self-signed certificates
This option has similar drawbacks to that of the Enterprise CA, but doesn’t scale well – since each self-signed certificate has no chain of trust beyond itself, each individual certificate would have to be installed on each and every client to avoid error messages. Management across a wide network would also create a whole new slew of headaches for poor Bob – something as simple as automatic browser updates could cause havoc unless ongoing vigilance is maintained on every device.
As always, contact us at SSL.com if you have any questions. Remember – a safer internet is a better internet.
