SSL Certificates without Non-FQDNs

February 21, 2013 by Bruce Morton     1 Comment

fqdnOver the years, publicly-trusted CAs have issued SSL certificates with domain names of different types. The most common is the Fully Qualified Domain Name (FQDN). This is a certificate that has been issued with a name registered with an entity that manages a top-level domain (TLD), for example server1.domain.com. The differentiating characteristic about an FQDN is that it is unique. There is one controller of domain.com and that controller determines who can have any name under that root, such as server1.domain.com.

Along the way, public CAs also issued certificates with non-FQDNs, such as:

  • Server host name only, for example: server1
  • Server name with non-managed TLD, for example: server1.domain.local
    (In this example, local is not a TLD per ICANN.)
  • Reserved IP addresses
    (In this case, the IP address cannot be registered, see IPv4 and IPv6.)

Many SSL certificates have been issued that contain non-unique domain identifiers. Correspondingly, there are many security risks where publicly-trusted certificates issued with a non-FQDN could be used to attack an enterprise using the same name for internal usages.

The CA/Browser Forum decided to mitigate the risk by deprecating the issuance of certificates with non-FQDNs. As defined in the Baseline Requirements, the publicly-trusted SSL CAs will stop issuing certificates with non-FQDNs by November 1, 2015, and all unexpired certificates with non-FQDNs will be revoked by October 1, 2016. The CAs must also provide a warning of the deprecated use of such certificate to the applicant before issuance.

This issue is particularly a problem with Microsoft Exchange users where non-FQDN names are used frequently. Paul Cunningham, a Microsoft Exchange Server MVP, wrote this article to help address the Exchange issue.

The problem also affects other deployments. To help, the CA/Browser Forum published Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses to explain the issue and provide recommended solutions.

Please take a look at the publications and see if you have a problem with non-FQDNs.

About

Bruce Morton has worked in the public key infrastructure and digital certificate industry for more than 15 years and has focused on SSL and other publicly trusted certificates since 2005. He has been an active member of the CA/Browser Forum that released guidelines for extended validation (EV) certificates and Baseline Requirements for SSL certificates. Bruce oversees the governance and compliance of Entrust’s publicly trusted PKI.

One thought on “SSL Certificates without Non-FQDNs

  1. Pingback: certificate for intranet server

Add to the Conversation