Enterprises have long needed certificates for their internal servers where they use naming conventions that do not lend themselves to using registered top level domains and are only valid in the context of a local network. However, as of November 1, 2015, the CA/Browser Form, which manages the Baseline Requirements (BRs) and sets the industry standard for the use of SSL Certificates, no longer allows publicly trusted SSL Certificates to include these local names, such as internal server names and reserved IP addresses.
Note: The BR went into effect July 1, 2012, specifying that “the CA shall not issue a certificate with an Expiry Date later than 1 November 2015 with a SAN or Subject Common Name field containing a Reserved IP Address or Internal Server Name. As from 1 October 2016, CAs shall revoke all unexpired Certificates”. We stopped issuing publicly trusted certificates in accordance with this timeline and will revoke any unexpired certificates upon the October 1 deadline.
What Is an Internal Server Name?
An internal server name (which may or may not include an Unregistered Domain Name) is one that is not resolvable using the public DNS, for example:
- Any server name with a non-public domain name suffix (e.g. mydomain.local, mydomain.internal)
- NetBIOS names or short hostnames, anything without a public domain
What Is a Reserved IP Address?
A reserved IP is an IPv4 or IPv6 address that the IANA has marked as reserved, for example:
- Any IPv4 address in the RFC 1918 range (e.g. 10.0.0.0, 172.16.0.0, 192.168.0.0)
- Any IPv6 address in the RFC 4193 range
Why Aren't Internal Server Names and Reserved IPs Allowed in Publicly Trusted SSL?
For one, this is because these names are not unique and are used internally, so there is no way for a CA to verify that the company owns them (e.g. many companies may have an internal mail system at the address “https://mail/”).
There is also potential for misuse if publicly trusted certificates were to include these non-unique names. For example, consider a scenario where an organization uses “https://mail/” for their mail system. Since that name is not unique, anyone could potentially obtain a certificate for “https://mail/”, bring it into the corporate network and combined with local name spoofing, impersonate the enterprise’s real mail server to gain access to all email contents.
For more explanation on the dangers of internal names and reserved IPs in public SSL Certificates and background on their deprecation, check out this white paper from the CA/Browser Forum.
Options for Internal or Local SSL Certificates
So what can you do if you have servers with internal names and/or reserved IPs that you want to secure with SSL? There are a couple options:
- Migrating to registered domain names - a good long term option and allows you to continue getting certificates from your preferred trusted CA provider.
- Setting up and running your own enterprise CA – however, this comes with the costs of procuring, configuring and running your own CA and OCSP services.
- Using self-signed SSL Certificates – however, this is only good in very limited environments (e.g. test servers). It teaches users to ignore important browser warnings which can lead to security issues if they accept self-signed certificates outside of their company.
- Obtaining SSL Certificates under non-public roots from your trusted CA provider – this is a good option if you want to continue using unqualified names, but don’t want to run your own CA or rely on self-signed certificates.
The last approach is arguably the best if you don’t want to, or can’t migrate to FQDNs because you can continue using your current CA portal to manage all of your SSL Certificates in one place - Extended Validation (EV), Organization Validated (OV), plus those issued under non-public roots for internal use. This way you get all the benefits of a hosted CA solution (e.g. renewal reminders/reports, centralized reporting and inventory management, APIs to fully automate certificate issuance and delegated user administration) with the flexibility of continuing to support internal servers and applications.
GlobalSign IntranetSSL
We wanted to give organizations a way to continue issuing SSL to internal server names and reserved IPs without the need to run an internal CA, rely on self-signed certificates, or obtain a company-specific private CA, so we created IntranetSSL. IntranetSSL is an addition to our cloud-based certificate management portal, offering immediate issuance of organization vetted certificates based on pre-vetted company profiles and domains, as well as internal server names. Because the certificates are issued from non-publicly trusted root certificates (roots which are not distributed by the browsers and operating system vendors), the certificates are not constrained by the baseline requirements.
Enterprises can easily push out the necessary IntranetSSL non-public roots to their users via Group Policy Object (GPO), or other centralized management system which will make the IntranetSSL certificates trusted by their user community.
Three Key IntranetSSL Features
| 1 |
Internal Server names and reserved IP addresses: |
| 2 |
Flexible key types/hashing algorithms: |
| 3 |
Longer validity periods: |
Have questions about using SSL with internal server names? Please don't hesitate to contact us. If you'd like more information on the Baseline Requirement and the deprecation of internal server names and reserved IP addresses in publicly trusted SSL Certificates, we recommend this white paper.
