strange SSL certificate behavior

[Daniel Buschke]

Hi all,
I noticed (at least 3 times for now) a strange SSL certificate validation
behavior in FF. After setting a trusted & valid certificate on a web server, FF
is still thinking that the domain name is not matching (see screen shot).

1. I go to https://t-dbu-01:8443/nps
2. except the certificate ONLY for that session
3. creating at new certificate (I have to create that certificate from the URL
from step 1, if anyone is wondering...)
4. install new certificate, install the CA of the new certificate in FF and
restart FF
5. visiting https://t-dbu-01:8443/nps again

What I would expect is that FF is opening the SSL page without any warning
because the DNS names are fully OK (SAN) and the CA is trusted. But what I get
is a warning that the certificate of the server is not valid due to a naming
mismatch.

I attached the certificate used by the web server. While doing that I noticed
that the 2 of the 4 specified CRLs will fail due to SSL errors ;) Is that a
problem? When why FF is giving the bad name error?

regards
Daniel

PS: Chrome is opening the page without any warning *scnr* :)

[VanguardLH]

Daniel Buschke <daniel....@araneaconsult.de> wrote:

> I noticed (at least 3 times for now) a strange SSL certificate validation
> behavior in FF. After setting a trusted & valid certificate on a web server, FF
> is still thinking that the domain name is not matching (see screen shot).
>
> 1. I go to https://t-dbu-01:8443/nps

^^^^^^^^___ Where's the TLD (top-level domain)?

You show what might be just a hostname. t-dbu-01 is not a domain name.
There is to TLD (e.g., .com, .net, .org, etc) in the domain (or whatever
t-dbu-01 was supposed to represent). So is this an internal host on
your own intranet that is running a web server?

I didn't even bother trying to connect to that host because it does not
have a valid domain name. Looks to be just a hostname which is only
something to which you can connect within your own intranet.

Try this:

nslookup t-dbu-01

It'll error. No such domain. You specified a hostname or you omitted
the TLD from the domain name. Is this a hostname you specified in your
'hosts' file (if using Windows - you didn't mention your OS)?

[Daniel Buschke]

Hi,

On 2017 M03 20, Mon 19:46:53 CET VanguardLH wrote:

> Daniel Buschke <daniel....@araneaconsult.de> wrote:
> > 1. I go to https://t-dbu-01:8443/nps
>

> ^^^^^^^^___ Where's the TLD (top-level domain)?

The FQDN is t-dbu-01.araneaconsult.de (not reachable from outside).
araneaconsult.de is the default DNS suffix in our network:

-----------------------------------------------
~> nslookup t-dbu-01
Server: 10.32.1.1
Address: 10.32.1.1#53

Name: t-dbu-01.araneaconsult.de
Address: 10.32.1.170
-----------------------------------------------

Please also note that both, the FQDN and the hostname, are part of the SAN
extension of the certificate. So it should not matter how you reach the web
server. Anyway, if the browser looks at the certificate and the URL host part
it should find a match, shouldn't it?

regards
Daniel

[VanguardLH]

Look at the details of the site certificate. What it registered against
araneaconsult.de or against t-dbu-01.araneaconsult.de? When visiting
the web site, click on the padlock icon at the left end of the address
bar. Click the rightward chevron for the domain info. Does it say
there "Verified by: <yourCA>"?

Click on More Information. Under Technical Details, what encryption
scheme is defined for your site cert?

Click on View Certificate. Click on the Details tab. Under the
Certificate Fields section, look at the value of the Subject attribute
of the cert. Look at the value of CN (Common Name).

Are you using a self-signed cert for your internal web server host?
Firefox won't accept those unless you add an exception.

https://www.poweradmin.com/help/sslhints/firefox.aspx

As I recall, you cannot add an exception for a server using IPv6.
However, according to the following article, that was in pre-43 versions
of Firefox. Don't know what version of Firefox you are using.

https://support.mozilla.org/t5/Documents-Archive/quot-This-Connection-is-Untrusted-quot-error-message-appears/ta-p/589

There is also the issue of what encryption the cert uses. SSL 1 & 2 got
dropped (considered insecure after proven they could be hacked). SSL 3,
I believe is supported but most sites are expected to move to TLS.
However, I wouldn't think an unsupported encryption scheme in Firefox
(which should also not be supported in Google Chrome) would result in an
error about the cert's domain name not matching on the domain where the
cert is deployed for a server.

https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
https://blog.mozilla.org/security/

I noticed:

URI:http://10.32.1.170:8028/crl/one.crl

Is that the CA that you are using internally? Presumably it is up and
can it be reached to provide the revocation list to check about your
cert. Looks to be on the same host as where you run your web server.

The Subject Alternative Name attribute does list both t-dbu-01 and
t-dbu-01.araneaconsult.de. While I've seen site certs with the SAN
attribute, the values have been hostname.domain.tld. I'm not familiar
with using IP addresses or common names (hostname only). The following
article and https://en.wikipedia.org/wiki/Subject_Alternative_Name say
IP addresses and DNS names are allowed. Will a hostname-only SAN
attribute work with a site cert since hosts can have the same name
across a subnet? DNS should help with that yet could differ on returned
IP adderss depending on which DNS server the client connected to.

https://www.digicert.com/subject-alternative-name.htm

Do you still run into a problem with the name mismatch error if you use
https://t-dbu-01.araneaconsult.de:8443/nps (instead of
https://t-dbu-01:8443/nps with just the hostname)?

Just to be sure, does your CA allow hostname-only targets in the SAN
attribute? So CAs can impose restrictions on the number of SAN targets
and also on their formats. For example, the CA may not permit
wildcarded hosts so each host must be enumerated. Some restrict the SAN
targets to allow only those within the same domain. A hostname only
doesn't specify a domain.

Maybe my eyes are too tired but I did not see a Common Name (CN)
attribute in the export of your cert that you presented as a .txt
attachment. So I hunted around for what happens to CN when SAN is
specified.

https://bugzilla.mozilla.org/show_bug.cgi?id=1157214

Comment 6 says to discard whatever is specified in the CN attribute.
Okay, but Comment 8 says "take care that you use the appropriate entry
type: dNSName for the domain name and iPAddress for the IP address". To
me, "domain name" is not the same as "hostnameOnly". When I've tried
hunting for examples of SAN certs, each non-IP address entry had a
domain name, not just a hostname.

https://tools.ietf.org/html/rfc5280#page-36
"When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName"

Gets tough when delving into the RFCs to know if "label" must have a
domain or it can be just a hostname (and rely on DNS resolution to the
domain).

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

It has a link to a whitepaper discussing use of hostname-only objects
resolved by DNS and spoofing. Yet you showed your DNS is resolving the
hostname to its FQDN. Maybe Firefox is not so lax.

https://www.digicert.com/subject-alternative-name-compatibility.htm

They duplicate the CN value as the first SAN value. I'm not sure that
is really necessary but what if you create your cert so DNS:t-dbu-01 was
listed first?

It also mentions mobile clients may not recognize or honor the SAN
attribute. I don't on what platform you are running Firefox.

https://www.ssllabs.com/ssltest/index.html

While can do some exhaustive testing of a site's certification, it only
works with publicly accessible server, and yours isn't one. I don't
know of a similar SSL test/diagnostic tool that could work inside your
network to do similar testing.

[Daniel Buschke]

Hi,
looks like I found a fix/workaround. The CN is present in the certificate BUT
was not the first entry in the SANs. If I issue a certificate which has the same
value from CN in the first entry of the SANs than FF is accepting the
certificate.

I wonder where this behavior comes from? Can anyone explain why FF behaves
like this?

BTW: I still think about opening a bug for that. Because:

1. FF is - at least - giving a misleading error message (bad domain name,
which is obviously not the reason of the error)

2. checking the certificate details, as VanguardLH mentioned, said that the
certificate is not issued by anyone and that I use a plain/unencrypted
connection (which is obviously also wrong)

Or should I go onto the developer mailing list? I will think about that.

regards
Daniel

On 2017 M03 21, Tue 07:42:39 CET VanguardLH wrote:
> Look at the details of the site certificate. What it registered against
> araneaconsult.de or against t-dbu-01.araneaconsult.de? When visiting
> the web site, click on the padlock icon at the left end of the address
> bar. Click the rightward chevron for the domain info. Does it say
> there "Verified by: <yourCA>"?

> ...