As a safety precaution to prevent SSL server certificates being exploited for network man-in-the-middle attacks on organizations, vendors that issue SSL server certificates will begin adhering to new issuance guidelines as of Nov. 1. These new rules, as described by members of the industry group Certificate Authority/Browser Forum, mean certificate authorities (CAs) will not issue certificates that contain "internal names" and expire after Nov. 1, 2015.
Now, a second industry group, the CA Security Council, whose members include Go Daddy, DigiCert, Trend Micro, Entrust, Symantec, GlobalSign and Comodo, shares its perspective on these important changes in the commentary below from Wayne Thayer, a member of the Steering Committee of the CA Security Council who is also Go Daddy's general manager for security products:
With hundreds of new top-level domain names (TLDs) such as ".exchange" and ".xyz" becoming available, there's currently a lot of excitement and change in the world of domains. The onset of all these new TLDs is also driving some big changes in so-called "Internal Names" -- domain names that are only meaningful to a particular organization. Common examples are "mail" and "intranet", but IT departments have historically used Internal Names to identify all sorts of systems that don't require public access.
The CA/Browser Forum has adopted rules that will soon end the issuance of SSL certificates containing Internal Names. Specifically, Certificate Authorities (CAs) may not issue certificates that contain Internal Names and expire after 1 November 2015. Since most CAs sell certificates in 1-year increments, this effectively means that customers must stop requesting certificates containing Internal Names before 1 November 2014. In addition, CAs must revoke existing certificates containing Internal Names by 1 October 2016.
+ Also on NetworkWorld: New SSL server rules go into effect Nov. 1+
In addition, existing certificates containing Internal Names that match newly delegated TLDs (e.g. "exchange") must be revoked no later than 120 days after the contract for the new TLD is executed. In most cases, this timing is such that existing certificates must be revoked before names in the new TLD are available to be registered.
These new rules are forcing many IT departments to scramble to make decisions and implement changes before their existing SSL certificates expire or are revoked. The recommended solution to these challenges is to reconfigure systems to utilize publicly registered names. In some cases that work can be too costly and organizations will consider the other options outlined in this CA Security Council blog.
The security issues driving these new rules existed long before ICANN's massive expansion of TLDs. The fundamental problem with Internal Names is simply that they're not unique. This means that many parties can and do obtain certificates containing the exact same name. Combine this fact with the relative ease of executing man-in-the-middle attacks over wireless networks, and you have a significant security hole.
As an example of this threat, consider a company with a guest Wi-Fi network that is running their internal email system at https://exchange. An attacker with access to the network and an SSL certificate for "exchange" -- easily obtained under existing CA policies - has everything needed to intercept email credentials and contents using a tool like sslsniff without being detected.
Moving systems away from Internal Names, like most security related efforts, isn't necessarily easy or much appreciated, but this work is setting the stage for a time in late 2016 when all publicly trusted SSL certificates are associated with unique registered domain names, and networks are safer as a result.
Ellen Messmer is senior editor at Network World, an IDG website, where she covers news and technology trends related to information security. Twitter: MessmerE. E-mail: emessmer@nww.com
