Can an unqualified domain name cause man-in-the-middle attacks?

ICANN issued a security advisory regarding SSL certificates for internal domain names with unqualified extensions. What is an unqualified extension, and what is the risk they pose? How can organizations secure their SSL certificates to prevent this problem?

DNS (Domain Name System) is the naming system used for computers, services and any other resource connected to the Internet. For example, the hostname "www.mycompany.com" is composed of three DNS labels: "www" is the local hostname, "mycompany" is the second-level domain name and ".com" is the top-level domain. A hostname is considered a fully qualified domain name (FQDN) when all the labels are specified and there is at least one public routable IP address associated with it. The hostname 'www.mycompany.com' would be translated into an IP address via the local host's file or a DNS resolver.

Organizations often identify machines on their local network with unqualified names such as "mail," "wiki" and "exchange" so that users can just type the short name of an internal resource to reach it. These human-readable local hostnames are also easier to remember and recognize than IP addresses. If these devices do not have a public IP address, they are regarded as having an unqualified domain name.

The Electronic Frontier Foundation discovered that there are thousands of legitimate certificates issued by Certificate Authorities (CA) for common unqualified domain names that are used to identify machines on local corporate networks. This creates a security issue because a digital certificate issued by a publicly trusted CA is meant to uniquely identify a resource across the scope of the entire Internet; these unqualified names are not unique, though, and anyone could potentially obtain a certificate that validates for https://mail or https://wiki.

If an attacker obtains a certificate for the unqualified name "mail" and it is chained to a CA in the browser or operating system trust store, they can use it in a man-in-the-middle attack for any mail server on an internal network called "mail," as they have a perfectly forged proof of identity. Connections to the server would look normal; a certificate check would show it was issued from either a publicly trusted CA or a private, enterprise-scope CA.

This problem is about to get worse as certificates have also been issued by CAs for internal domain names with unqualified extensions. For example, the ".corp" domain extension is used internally on many private corporate networks, but it's currently being considered for future public use as a new gTLD (generic top-level domain). As the new gTLDs become operational, previously issued certificates for ".corp" and other new gTLDs could be used to redirect a user from real domain names.

In response to the problem, the CA/Browser (CA/B) Forum, an organization of certificate authorities and Web browser vendors, has asked its CA members not to issue new certificates for internal server names that have an expiration date beyond Nov. 1, 2015. On Oct. 1, 2016, all CAs are expected to revoke the remaining certificates for internal server names that are still valid on that date, putting a permanent end to this type of certificate. This still leaves a potential vulnerability for new gTLDs until October 2016.

Enterprise administrators can combat the risk posed by man-in-the-middle attacks by not using unqualified domain names to access internal resources. For example, a mail server should only be accessible at the FQDN "https://mail. mycompany.com/" and not by going to "https://mail/." Enterprises issuing certificates using their own private CA, such as Microsoft's Certificate Server, should not sign certificates for unqualified names or private, nonroutable IP addresses and should revoke any existing certificates.