In the wake of the revelation that a major SSL certificate provider suffered a serious breach, Chris Palmer from the Electronic Frontier Foundation has analysis of the common practice of issuing certificates for unqualified domain names, such as “mail” and “www” and “localhost” (an unqualified domain is one that consists of a single word, without a top- and second-level domain, e.g., “www” instead of “www.boingboing.net”). These unqualified names should never be issued certificates, as doing so leaves anyone who makes a practice of using them within a company network vulnerable to man-in-the-middle attacks. Palmer found tens of thousands of these certificates, and sounds the alarm that if you’re not using fully qualified domains for secure connections, you’re very vulnerable.
Although signing “localhost” is humorous, CAs create real risk when they sign other unqualified names. What if an attacker were able to receive a CA-signed certificate for names like “mail” or “webmail”? Such an attacker would be able to perfectly forge the identity of your organization’s webmail server in a “man-in-the-middle” attack! Everything would look normal: your browser would use HTTPS, it would show a the lock icon that indicates HTTPS is working properly, it would show that a real CA validated the HTTPS certificate, and it would raise no security warnings. And yet, you would be giving your password and your email contents to the attacker.
To test the prevalence of the validated, unqualified names problem, I queried the Observatory database for unqualified names similar to “exchange”. (Microsoft Exchange is an extremely popular email server, and servers that run it commonly have “exchange” or “exch” in their names. Likely examples include “exchange.example.net” and “exch-01.example.com”.) My results show that unqualified “exchange”-like names are the most popular type of name, overall, that CAs are happy to sign.
Unqualified Names in the SSL Observatory