Deprecation of ssl certificates securing internal domains: why, when and what to do
DEPRECATION OF SSL CERTIFICATES SECURING INTERNAL DOMAINS: WHY, WHEN AND WHAT TO DO
The first step announced by the CA/Browser forum is now very close: they stated in 2012 that no SSL certificate securing a local domain, IP address or a server name should be issued with an expiry date later than October 31st, 2015.
SSL certificates are issued for a minimum of 1 year, therefore, no CA (Certification Authority) will be issuing any SSL certificate for internal needs after October 31st, 2014.
To put it another way, you have (from the date this was written) less than two months to order an SSL certificate securing a local domain / IP or server name. In any case, its expiry date cannot go beyond October 31st, 2015.
If you already have an SSL certificate for your local domain / IP or server name, bear in mind that this certificate will remain valid 2 years maximum from November 1st 2014 (according to the duration you chose when you purchased it). However:
- From November 1st, 2015 you won’t be able to reissue your certificate. We strongly recommend that you save your SSL certificate (CER and PFX/PVK files) in case you would have issues with your server.
- From October 1st, 2016, your SSL certificate will be revoked, whatever the expiry date is.
The transition to a FQDN SSL certificate shouldn’t be too much of an issue for a majority of people. However, we know that users of Microsoft applications (such as Exchange or Active Directory) won’t be delighted with this transition, as it requires some important network configuration changes.
Why can we no longer secure internal domains, internal IPs or server names with an SSL certificate?
The launch of hundreds of new gTLDs and the risk of name collision between internal and public domains using new gTLDs is one of the reasons which triggered this deprecation. Yet, the guide for internal domains deprecation released by the CA/Browser forum explains how the organisation’s decision was motivated above all by the potential security issues with certificates for internal needs:
“Because non‐unique names cannot be meaningfully validated in the context of the public Internet, and because of the potential for malicious misuse of such certificates, the CA/Browser Forum has decided to cease issuing them after a grace period to allow affected users to transition away from them.”
To make it short, the decision to deprecate the issuance of SSL certificates for internal needs was essentially made in order to fight against MITM (Man in the Middle) attacks inside private networks. Internal domain names / IPs and server names cannot be vetted during the issuance process. Therefore, they should no longer be used.
One major problem remains: what to do when your network infrastructure relies on local names / IPs / servers?
What are the solutions for companies using SSL certificates for internal needs?
You have 3 options to consider:
- Reissue your SSL certificate without any SAN including a local domain, private IP or server name before October 31st, 2015. This will make sure your certificate won’t be revoked on October 1st, 2016, but it is only possible if the common name used in your SSL certificate is a FQDN (Fully Qualified Domain Name, a public domain name).
- Buy a public domain name (SSL247® can help you buy and manage domain names) and force DNS domain suffix search on your network (see this tutorial). Please note that some Microsoft services such as Exchange or Outlook 2007 Autodiscovery use by default a server name and not a public domain name. You can change this configuration by following this tutorial.
- Generate yourself your SSL certificates (self-signed certificates) and install them on all the computers of your network: you will entirely manage your PKI (Private Key Infrastructure). This solution can be hard to set up for medium and large networks, this is why we offer mPKI (Managed Private Key Infrastructure) solutions to simplify the management of such infrastructure. Contact us to find out more and get a full audit of your SSL needs.
Send us your comments
Your comment will not be published. If you have a question, do not forget to write your email address so that we can get back to you!