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
- Exchange Autodiscover infrastructure – Introduction | Part 01#36
- The old Exchange environment versus “modern” Exchange environment | Part 02#36
- Who are the Exchange Autodiscover clients? | Part 03#36
- The Autodiscover information | Part 04#36
- The Autodiscover algorithm for locating the “source of information” | Part 05#36
- Exchange CAS server | Providing Exchange clients access to their mailbox | Part 06#36
- Exchange CAS server as information + Web service provider | Part 07#36
- The dual identity of the Exchange server | Part 08#36
Autodiscover infrastructure | FQDN and URL address
- The basics of Domain name, FQDN and URL address | Exchange infrastructure |Part 09#36
- Exchange Web services | Manage the Internal and external URL address | Part 10#36
Exchange Autodiscover flow in different environments
- The content of the Autodiscover server response | Part 11#36
- Outlook client protocol connectivity flow in an internal network environment | Part 12#36
- Exchange clients and their Public facing Exchange server | Part 13#36
- Outlook Autodiscover decision process | Choosing the right Autodiscover method | Part 14#36
- Autodiscover flow in Active Directory based environment | Part 15#36
- Autodiscover scenarios in enterprise environment | Part 16#36
Autodiscover infrastructure | Exchange infrastructure and namespace convention
- Should I use a single namespace for Exchange Infrastructure? | Part 1#2 | Part 17#36
- Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36
- Public SAN certificate | Deprecated support in the internal server name | Part 19#36
Exchange, Autodiscover and security infrastructure
Autodiscover Troubleshooting tools
- Outlook Test E-mail AutoConfiguration | Autodiscover troubleshooting tools | Part 1#4 | Part 21#36
- Microsoft Remote Connectivity Analyzer (ExRCA) | Autodiscover troubleshooting tools | Part 2#4 | Part 22#36
- Microsoft Connectivity Analyzer (MCA) | Autodiscover troubleshooting tools | Part 3#4 | Part 23#36
- Using Fiddler for Autodiscover troubleshooting scenarios | Part 4#4 | Part 24#36
Autodiscover major flow scenarios
Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 1#3 | Part 26#36
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 2#3 | Part 27#36
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 3#3 | Part 28#36
Autodiscover flow in an Office 365 based environment
- Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36
- Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36
- Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36
Autodiscover flow in an Exchange Hybrid environment
- Autodiscover flow in an Exchange Hybrid environment | Part 1#3 | Part 32#36
- Autodiscover flow in an Exchange Hybrid environment | Part 2#3 | Part 33#36
- Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36
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.”
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
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.
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.
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.
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.
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:
[Source of information CA/Browser Forum]
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!
For more information, you can visit the CA/Browser Forum website (cabforum)
Q: What is the reason to stop using the internal name in my public certificate?
[Source of information – Global changes in legislation regarding SAN SSL Certificates]
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.
[Source of information – SSL Certificates for Internal Server Names]
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.
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 – mail.o365info.com
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 mail.o365info.com, the server will reply by proving the client a certificate, which include the host name in the “Subject Alternative Name” filed.
In case that the host name doesn’t appear on the certificate, the certificate considered as not valid.
The formal definition of an SAN certificate as it appears in Wikipedia is:
[Source of information: SubjectAltName]
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
- 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.
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 “www.cabforum.org” 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 “220.127.116.11”, while there are tens of thousands of home Internet gateways that have the address “192.168.0.1”
“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 “192.168.0.1” 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.
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
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.
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
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.
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
Information about the new standard – cabforum
- Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.0
- Guidance on the Deprecation of Internal Server
General Information about the new standard
- CA:Problematic Practices
- Invalid Fully Qualified Domain Names no longer accepted in Subject Alternative Names (SANS) in SSL certficates
- Modify .local in Exchange 2010
- Global changes in legislation regarding SAN SSL Certificates
- No internal server names on SAN certificates after 2015 – where are the procedures?
Information from public CA companies
It is important for us to know your opinion on this article