SSL Certificates without Non-FQDNs

Bruce Morton

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.

Bruce Morton
Bruce Morton
Director, Certificate Technology & Standards

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.


  1. Sanjeev Addagarla June 22, 2016 Reply

    Hi Bruce,
    can we create the certificate with FQDN and then use a hostname alias as Subject alternate name? does it still carry the security risk?


    • Bruce Morton Author
      Bruce Morton June 22, 2016 Reply

      No. All domain names are included in the subject alternative name (SAN) field. The requirement for public trust SSL/TLS certificates is that no domain names can be unregistered, so we cannot include a host name as a SAN.

  2. David.ha@gmail.com June 25, 2016 Reply

    Hi Bruce
    does this rule (SSL must be with FQDNs) apply for self signed certificates that are used in cloud platforms as well?

    • Bruce Morton Author
      Bruce Morton June 27, 2016 Reply

      Hi David,

      This rule should not apply to self-signed certificates. It should only apply to public trust certificates which validate back to a root certificate which is distributed by the operating system or browser.


  3. Prashant November 2, 2016 Reply

    is it okay to use non-FQDN certificates for internal (within the organization) B2B communication? or does it carry any security risks? pls can you guide.

    • Bruce Morton Author
      Bruce Morton November 4, 2016 Reply

      The answer will depend on the CA or the root which will trust the certificate. The policy to stop issuing certificates with unregistered domain names is for public trust only. The reason is that many CAs could issue certificates with the same domain names to many different customers. The result could make the customer or their users open to attack.

      Today, public trust CAs cannot issue certificates with unregistered domain names. The current sources would be self-signed, internal enterprise CA, or a private trust CA service. Issuing the certificate from a CA is the best option as the CA will meet a defined policy, the certificate status can be provided and the certificate can be revoked. If the certificate comes from a private trust CA service, then you should ensure that the CA does not allow other customers to receive certificates with non-FQDNs which are the same as yours. If two customers can use the same non-FQDNs, then they are vulnerable to each other.

      Entrust Private SSL Certificates https://www.entrust.com/private-ssl-certificates/ could be a solution which could work for you.


Add to the Conversation