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”.

http://o365info.com/public-san-certificate-deprecated-support-in-the-internal-server-name-part-19-of-36


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/


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.





http://o365info.com/exchange-infrastructure-implementing-single-domain-namespace-part-2-of-2-part-18-of-36

http://o365info.com/exchange-infrastructure-implementing-single-domain-namespace-part-2-of-2-part-18-of-36


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 changes\updates 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 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.






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]





http://en.wikipedia.org/wiki/CA/Browser_Forum

https://cabforum.org/

http://www.networking4all.com/en/ssl+certificates/faq/change+san+issue/



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 host\s names, which are “entitled” to use the specific

certificate.





http://www.digicert.com/internal-names.htm


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”





http://en.wikipedia.org/wiki/SubjectAltName

https://www.google.co.il/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB4QFjAA&url=https%3A%2F%2Fcabforum.org%2Fwp-content%2Fuploads%2FGuidance-Deprecated-Internal-Names.pdf&ei=6eCdVbuTCon7ywOmopWwCg&usg=AFQjCNG0wOhZ9FIRgbJTV9CU84FEXKWtRg&sig2=sv3TKPT74xJxOnB3Fs6Beg&bvm=bv.96952980,d.bGQ

https://www.google.co.il/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB4QFjAA&url=https%3A%2F%2Fcabforum.org%2Fwp-content%2Fuploads%2FGuidance-Deprecated-Internal-Names.pdf&ei=6eCdVbuTCon7ywOmopWwCg&usg=AFQjCNG0wOhZ9FIRgbJTV9CU84FEXKWtRg&sig2=sv3TKPT74xJxOnB3Fs6Beg&bvm=bv.96952980,d.bGQ


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 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, 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





http://www.cabforum.org/Baseline_Requirements_V1.pdf

http://www.cabforum.org/Baseline_Requirements_V1.pdf

https://cabforum.org/wp.../Guidance-Deprecated-Internal-Names.pdf

https://wiki.mozilla.org/CA:Problematic_Practices

http://exchangekb.com/tag/invalid-fully-qualified-domain-name-such-as-local/

http://exchangekb.com/tag/invalid-fully-qualified-domain-name-such-as-local/

https://www.networking4all.com/en/support/ssl+certificates/manuals/microsoft/exchange+2010/modify+.local/



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





http://social.technet.microsoft.com/Forums/exchange/en-US/0f8f66fe-e4a3-42ef-b85b-10f841b795cd/no-internal-server-names-on-san-certificates-after-2015-where-are-the-procedures?forum=exchange2010

http://social.technet.microsoft.com/Forums/exchange/en-US/0f8f66fe-e4a3-42ef-b85b-10f841b795cd/no-internal-server-names-on-san-certificates-after-2015-where-are-the-procedures?forum=exchange2010

http://www.digicert.com/internal-names.htm

https://www.eff.org/deeplinks/2011/04/unqualified-names-ssl-observatory

https://www.eff.org/deeplinks/2011/04/fully-qualified-nonsense-ssl-observatory

https://www.eff.org/deeplinks/2011/04/fully-qualified-nonsense-ssl-observatory

http://www.iana.org/domains/root/db

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

Documents