Public san certificate deprecated support in the internal server name part 19#36

of 21 |Public SAN certificate | Deprecated support in the internal server name |
Part 19#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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 at the current time (2014), there is not too much public
information about this subject, but although this subject seems to be minor and
not “cool”, the Implications of this new standard could be quite dramatic and
serious.
Allowing myself to be a little dramatic, I relate to the new public certificate standard
as the- “The revolution of 1 November 2015”.

Part 19#36
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 specific service by using a certificate that includes Non-unique names.
And as usual, in 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 myself for this change?
I will try to answer some of this question in details in the following section, but,
regarding question number 4 – “To what organization services and infrastructures
does this issue relate”, is important to emphasize that this subject is huge, and the
answer can relate to Dozens or even hundreds of different services but in the
current article I relate mainly to the Microsoft Exchange server infrastructure.

Part 19#36
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 very important
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.

Part 19#36
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 changesupdates before the last day.

Part 19#36
So what is all about?
The rustling and rattling is about the fact that in case that organization
infrastructure such as Exchange CAS server use 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.

Part 19#36
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.

Part 19#36
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 isareit 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.

Part 19#36
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.
[Source of information CA/Browser Forum]
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?
A:
The reason that is 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 – Global changes in legislation regarding SAN SSL
Certificates]

Part 19#36
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 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.”
“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 hosts names, which are “entitled” to use the specific
certificate.

Part 19#36
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 upon the certificate, the certificate
considered as not valid.

Part 19#36
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 be
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)

Part 19#36
 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 for this question by using a very clear and informative PDF that
was 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 “97.74.42.11”, while there
are tens of thousands of home Internet gateways that have the address
“192.168.0.1”

Part 19#36
“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.

Part 19#36
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

Part 19#36
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:

Part 19#36
 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 ISPProviders 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, not 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.

Part 19#36
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

Part 19#36
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.

Part 19#36
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

Part 19#36
Additional reading
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

Part 19#36
 No internal server names on SAN certificates after 2015 – where are the
procedures?
Information from public CA companies
 SSL Certificates for Internal Server Names
 Unqualified Names in the SSL Observatory
 Fully-qualified Nonsense in the SSL Observatory
 Root Zone Database

Public san certificate deprecated support in the internal server name part 19#36

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (15)

Semelhante a Public san certificate deprecated support in the internal server name part 19#36

Semelhante a Public san certificate deprecated support in the internal server name part 19#36 (20)

Mais de Eyal Doron

Mais de Eyal Doron (20)

Último

Último (20)

Public san certificate deprecated support in the internal server name part 19#36