skip to Main Content

Public SAN certificate | Deprecated support in the internal server name | Part 19#36

In the current article, we will review the subject of – “Invalid Fully Qualified Domain Names” in SAN certificate.

The interesting thing is that hostname (2014), there is not too much public information about this subject, but although this topic seems to be minor and not “cool”, the Implications of this new standard could be quite dramatic and severe.

Article Series Table of content | Click to expand

Exchange and Autodiscover infrastructure | Article Series

Exchange Autodiscover – Article series – INDEX

Exchange and Autodiscover infrastructure | The building blocks

Autodiscover infrastructure | FQDN and URL address

Exchange Autodiscover flow in different environments

Autodiscover infrastructure | Exchange infrastructure and namespace convention

Exchange, Autodiscover and security infrastructure

Autodiscover Troubleshooting tools

Autodiscover major flow scenarios

Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment

Autodiscover flow in an Office 365 based environment

Autodiscover flow in an Exchange Hybrid environment

Exchange Stage migration and Autodiscover infrastructure

Allowing myself to be a little dramatic, I relate to the new public certificate standard as the- “The revolution of 1 November 2015.”

The Revolution of 1 November 2015

As of the date of – 1 November 2015, there will be no option to enroll in a new public certificate or renew existing public certificate that includes Non-unique names.

In other words – you will not be able to publish internal or external host who provides a particular service by using a certificate that includes Non-unique names.

And as usual, at this stage, there are many relevant questions that could appear:

Q1. What is the meaning of Invalid Fully Qualified Domain Names?

Q2. What is the meaning of Non-Unique names?

Q3. What are the relations or the connection to SAN certificate?

Q4. To what organization services, and infrastructures does this issue relate?

Q5. How to prepare me for this change?

I will try to answer some of this question in details in the following section. Regarding question number 4 – “To what organization services and infrastructures does this issue relate”, is important to emphasize that this subject is enormous, and the answer can relate to dozens or even hundreds of different services. In the current article, I relate mainly to the Microsoft Exchange server infrastructure.

Regarding question number 5 – the “how part” answer appears in more details in the former article – Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36

Note – despite the “declaration” about the relevance of the Exchange infrastructure, most of the information is relevant for any other infrastructure and even for non-Microsoft operating systems.

Why should I care about the subject of – Public SAN certificate | deprecated support in – Internal Server name? (Non-unique names)?

As mentioned, the subject at the end of support for the Internal server name in the Public SAN certificate doesn’t make too much noise, but it is a imperative subject that relates to the most basic organizing services and infrastructure begging with the websites, Exchange infrastructure and much more.

Q: In the case that I would prefer to ignore this subject, what could be the consequence?

A: I’m not a prophet, but I can predict that the consequence could be begging from annoying, up to be catastrophic.

Ignore Public SAN certificate deprecated support in Internal Server name

As an IT administrator or, as an Exchange server \ infrastructure Advisor, you owe yourself and your users to be familiar with the “new public certificate standard”, understand the meaning of this standard, plan for the required changes and implemented the changes\updates before the last day.

No internal server names on SAN certificates after 2015 and Exchange administrator

So what is all about?

The rustling and rattling are about the fact that in case that organization infrastructure such as Exchange CAS server uses an SAN certificate that includes a single host name or an FQDN with a private domain name, you will not be able to renew this certificate as of the date 1 November 2015.

No entry for a non-unique names and Private domain suffix

Another way to show the reluctance of the CA/Browser Forum – Public SAN certificate that includes Internal Server name? (Non-unique names) appears in the following picture.

Public SAN certificate - Deprecated support in Internal Server name 01

Note – I must admit that I have I got carried away but, I could not resist the temptation of adding this wonderful cat picture!

Q1: Who is the persona that makes my life so hard?

A1: CA/Browser Forum

Q2: Who is\are\it the CA/Browser Forum?

A2: The definition that appears in Wikipedia is:

The Certification Authority Browser Forum, also known as the CA / Browser Forum, is a voluntary consortium of certification authorities, vendors of Internet browser software, operating systems, and other PKI-enabled applications that promulgates industry guidelines governing the issuance and management of X.509 v. 3 digital certificates that chain to a trust anchor embedded in such applications.

Its guidelines cover certificates used for the SSL/TLS protocol and code signing, as well as system and network security of certificate authorities.

As of July 2013, the CA/Browser Forum includes over 30 Certificate Authority members and the following five Internet Browser Software Vendors: Microsoft (Internet Explorer), Apple (Safari), Mozilla (Firefox), Google (Chrome), and Opera.

The point – we should need to this “Forum” very seriousness!

Q: What is the reason to stop using the internal name in my public certificate?


The reason that given for the change is that the internal server names are not unique and therefore easy to falsify. With common names like server01 or webmail, the end user is never sure if it is actually dealing with the right party or with a malicious.

The changing legislation for SSL Certificates shall start on 1 November 2015.

This means, from that date, the invalid Fully-Qualified Domain Names (hereafter called FQDN) will no longer be accepted at the standard of the CA/Browser Forum and after that date such certificates may no longer be issued. All certificates issued after 1 November 2015 and meet this qualification will be revoked upon discovery.

In November 2011, the CA/Browser Forum (CA/B) adopted Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates that took effect on July 1, 2012.
These requirements state:

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a Subject Alternative Name (SAN) extension or Subject Common Name field containing a Reserved IP Address or Internal Server Name, the CA shall notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016.

Also as of the Effective Date, the CA shall not issue a certificate with an Expiry Date later than 1 November 2015 with an 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.”

“Because of these new requirements, Certificate Authorities (CAs) must immediately begin to phase out the issuance of SSL Certificates for internal server names or reserved IP addresses and eliminate (revoke) any certificates containing internal names by October 2016.

In addition, the baseline requirements prevent CAs from issuing internal name certificates that expire after November 1, 2015. After 2015 it will be impossible to obtain a publicly-trusted certificate for any host name that cannot be externally verified.

[Source of information – SSL Certificates for Internal Server Names]

What is an SAN public certificate?

The simple explanation for the term “SAN certificate” is – a public certificate that includes a list of one or more host\s names, which are “entitled” to use the specific certificate.

For example, an SAN certificate that includes the host name –

When we need to implement secure communication channel using protocols such as HTTPS, the “server side” proves his identity to the client by presenting an “approved” certificate.

For example – when a client address host named, the server will reply by proving the client a certificate, which include the host name in the “Subject Alternative Name” filed.

Exchange server identify himself before the client

In case that the host name doesn’t appear on the certificate, the certificate considered as not valid.

Example for SAN certificate

The formal definition of an SAN certificate as it appears in Wikipedia is:

SubjectAltName (SAN) is an extension to X.509 that allows various values to associated with a security certificate. These values are called “Subject Alternative Names”, or SANs. Names include:

  • E-mail addresses
  • IP addresses
  • URIs
  • DNS names (Otherwise often given as a Common Name RDN within the Subject)
  • directory names (alternative Distinguished Names to that given in the Subject)
  • other names, given as a General Name – an registered object identifier followed by a value.
  • SubjectAltName
[Source of information: SubjectAltName]

Why does the use of the Internal Server name (Non-unique names) could be translated into a security risk

Using an Internal Server name? (Non-unique names) is a public SAN certificate can lead to a scenario of the security vulnerability or exploit.

Regarding the subject of security vulnerability, I choose to make my life easier and provide the answer to this question by using a very precise and informative PDF that published by the CA/Browser Forum named –Guidance on the Deprecation of Internal Server

Certification Authorities enable the establishment of trust on the Internet by issuing certificates that bind cryptographic public key material to verify identities”

“The key distinction between the two types of names and addresses is uniqueness.

A fully qualified domain name like “” represents a unique and

Distinct identity on the Internet (even if multiple servers respond to that name, the control of that name belongs to a single entity).

In contrast, at any given time, there may be thousands of systems on public and private networks that could respond to the unqualified name “www”.

Only one logical host on the Internet has the IP address “”, while there are tens of thousands of home Internet gateways that have the address “”

“The purpose of certificates issued by publicly trusted Certification Authorities is to provide trust in names across the scope of the entire Internet.

Non-unique names, by their very nature, cannot be attested to outside their local context, and such certificates can be dangerously misused, so, as of the effective date of the BR 1.0, issuance of certificates for non-unique names and addresses, such as “www”, “www.local”, or “” is deprecated.

What are Non-unique Names?

Well, this is the tricky part because we need to explain an Intangible concept and additionally, there are many parallel words, which described the similar or the same concept.

The main subject of this article, relate to the new standard of public SAN certificate that states that – in the very near future (1 November 2015) a there is not support for Non-unique Names or Invalid Fully Qualified Domain Names.

What is Non-unique Names

In the following diagram, we can see a list of – ”Non-unique Names”, that will be considered as “not allowed” or not supported in an SAN public certificate beginning with 1 November 2015

Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates

Let’s admits, the term – ”Non-unique Names” is a little vague.
The reason for this ambiguity is because the term – ”Non-unique Names”, can be translated or converted into a couple of parallel terms.

To clarify this term, let’s use a basic classification for two name space categories: Single name address space verse FQDN (Fully qualified Doman Name) address space.

1. Single name address space

The “Single names address space” and all of the above terms, describe a naming convention that is based on a single name.
This is that exact naming convention that we use for our personal name.
Each of us, have a personal name, but we cannot relate to this name as a “unique identifier” because, there is a very a reasonable chance, that other people use this name.

In the network environment, we can refer to a host by using a single name address space.

This method of relating to a specific host by using a Single name address space described also by using the following terms:

  • Internal Server Name
  • Single Host name
  • Local names
  • Short Name
  • NetBIOS Name
  • Link-Local Multicast Name

2. FQDN (Fully Qualified Doman Name) address space

The term FQDN (fully qualified domain name) defines, as the name implies, a “Full name” that is built from a host name + Domain name suffix.

Each of these “parts” in a FQDN name is not unique, but the combination of host name and the domain name create a “unique name” or a Fully Qualified Doman Name.

The term – ”FQDN” can also be dived to two main categories:

1. Public FQDN

A public FQDN is a host name who has a public domain name suffix.
There could be a couple of formal definitions for the term- “public domain name” but if we want to make it simple, the meaning is a domain that was purchased from a public ISP\Providers who sell public domain names.

The public domain name should be registered, so after we have purchased the public domain name, nobody else can buy this domain name.

2. Private FQDN

The term – “private FQDN”, describe a FQDN name who uses a domain suffix that considers as private or, non public domain names suffix.

The advantage of a private domain name suffix is that is free and everybody is “allowed” to use it.

The only issue is that the private domain name, can only be used in an internal network.
In other words, we cannot publish a host in the public network by using a FQDN that includes a private domain name.

When relating to Active Directory domain name, the common practice was to “segregate” the internal organization’s network from the public network, by using a private domain name for the Active Directory.

The “theory” was that – we should separate and segregate internal host from the public network by providing them a private name who cannot be published on the public network and by doing so, protecting this host from malicious elements.

FQDN address space and domain name suffix

Public SAN certificate | Deprecated support in – Internal Server name? (Non-unique names)

In this section, I would like to review the subject of the CA/Browser Forum announcement about- baseline requirements for the Issuance and management of publicly trusted Certificates and Deprecated support in: Internal Server name? (Non-unique names) that will start in 1 November 2015.

Let’s start with the explanation of the term- Internal Server name (Non-unique names).
The “translation” of this term could be:

  • Single name
  • FQDN name with a private domain name

Internal Server name -Non-unique names

1. Single name

One translation of the term- “Internal Server name”? (Non-unique names) is – host name who uses a “single name space” as the host name.

An example for such as host name is the server named- mail

In the diagram, we can see additional synonym for the term “Single host name” such as- Local names, Short Name etc.

This type of a host name, will be no longer supported when using an SAN public certificate as of the date 1 November 2015.

Non‐unique names and Single name address space-01-A

2. FQDN name with a private domain name.

The second “translation” of the term “Internal Server name”? (Non-unique names) is – FQDN name who uses a private domain name suffix.

The new standard of the public SAN certificate will not support host name who uses a domain name suffix that is not a public domain name suffix.

Additional synonyms for this type of host FQDN are:

  • Invalid Fully Qualified Domain Name
  • Unregistered Domain Name
  • Private Domain Name

Non-unique names and FQDN address space-02

The o365info Team

The o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *