Certificates for Internal Servers

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

• 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: IntranetSSL supports the issuance of SSL Certificates with internal server names and reserved IP addresses in the CN and SAN values.  Further, IntranetSSL supports full flexibility in the use of these values with the pre-vetted domains to allow customer to mix and match internal, FQDNs, Sub-domains, Wildcard and Global IP addresses in one certificate, all bound to your Organization Name.
2	Flexible key types/hashing algorithms: IntranetSSL supports legacy, current and future applications with a variety of key types and hashing algorithms.  IntranetSSL is offered under three distinct hierarchies.  The RSA 2048/SHA-1 hierarchy supports legacy SHA-1 only applications which cannot be easily updated to support SHA-256 in line with the BR SHA-1 deprecation schedule, the RSA 2048/SHA-256 hierarchy is used for today's most common servers and browsers and the SHA256ECDSA hierarchy with ECC P-256 keys can be used for tomorrow's highest security enterprise applications.  All options are available to all IntranetSSL customers.
3	Longer validity periods: IntranetSSL supports longer validity period certificates than are permitted under the BRs enabling customers to receive certificates that are valid for up to 5 years.

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.