The common practice combining public and non-public domains could prove problematic as new extensions are made open for public registration.
It’s common practice for network administrators to use internal non-public top level domain extension as a way to extend resource naming within their corporate network and help users differentiate between resources within and outside of their corporate network.
Product documentation often encouraged administrators to use these extensions in order to differential internal vs. external network sources.
In 2011, ICANN approved the launch of a new gTLD program enabling the purchase of new top level domain extensions. The program’s goals emphasize enhancing competition online by allowing more domain names to be registered and gives consumers greater flexibility in their domain choices.
The gTLD program includes a strict set of requirements for operators wishing to register new extensions, but on the opening day of applications for the program, nearly 2000 organizations submitted their intention of registering new gTLDs.
Securing Networks with gTLD Extensions
Enterprises that for years have utilized internal names like .mail, .corp, .local, .services, among others in their corporate network and secured internal names with SSL Certificates, would need to register any domain name used in order to continue securing those services with SSL Certificates.
This common network practice combining public and non-public domains in SSL Certificates could prove problematic with the new registration requirement.
The Certificate Authority Security Council (CASC), CA/Browser Forum, and many major enterprises have requested that ICANN reconsider the release of some domain extensions, especially those proving most problematic to corporate networks.
Internal Name SSL Certificates
With the pending changes in previously internal domain name extensions, network administrators are scrambling to reconfigure their networks in order to stop the use of internal domain names. DigiCert has setup a thorough tutorial to redirect internal names within corporate network to help administrators through the transition process.
To simplify the migration for Microsoft Exchange environments, the DigiCert Internal Name Tool for Exchange makes it easy for administrators to comply with the new guidelines eliminating the need to include internal name in an SSL Certificate.
Most new domain extensions will have little impact on the corporate network. However, extensions like .corp and .services will create the most disruption for system administrators.
Phasing Out Internal Names
Certificate Authorities have been required to phase out the use of internal names in SSL Certificates by 2015. Converting internal names to external public names should be a top priority for network administrators.
DigiCert has provided simply resources to help make the reconfiguration process easy and DigiCert technical support engineers have been fully trained in the internal name migration and are available 24 hours a day to help with the process.
Administrators should frequently analyze their internal corporate network and ensure that all systems have been updated to use fully-qualified registered domain names. The DigiCert Certificate Inspector cloud-based platform scans of internal networks for free make internal name migration simple and easy.