strange SSL certificate behavior

This is a multi-part message in MIME format.

--nextPart11843649.FvnNQJo7RH
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

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* :)
--nextPart11843649.FvnNQJo7RH
Content-Disposition: attachment; filename="t-dbu-01.txt"
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"; name="t-dbu-01.txt"

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            75:e6:07:33:85:c2:14:27:ab:0d:c4:1d:6c:ec:71:02:62:42:ed:e4
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: OU=Organizational CA, O=DBUSCHKE-IDM46
        Validity
            Not Before: Mar 20 09:09:00 2017 GMT
            Not After : Mar 18 08:44:00 2027 GMT
        Subject: O=DBUSCHKE-IDM46, CN=t-dbu-01.araneaconsult.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d4:7c:5b:0c:77:a7:e5:fb:bd:8d:73:59:9c:8d:
                    9a:3a:74:89:a8:78:7d:01:27:78:5e:08:89:1d:48:
                    2c:2a:19:5c:16:57:1d:fe:de:76:91:e5:43:2b:0b:
                    5e:66:9b:9d:b6:23:57:90:57:7d:51:7c:8c:dc:9d:
                    9d:bf:cc:40:d1:da:2c:65:78:da:78:c3:dc:9e:44:
                    30:6e:9e:ad:6e:d7:9a:2a:d0:c2:61:78:9a:b3:2c:
                    53:10:f4:5a:09:83:7b:7d:e7:cb:9d:c2:bb:e3:82:
                    d6:c7:14:11:e0:4b:7a:f7:73:e1:99:08:34:64:a0:
                    40:64:47:03:21:1f:fc:a2:4f:3e:4b:62:fc:44:b2:
                    cb:60:6b:cb:78:68:a1:a7:9d:e0:f5:a0:7a:61:6a:
                    13:46:41:5c:ee:2c:47:5d:59:e8:38:65:38:b2:e1:
                    4b:e3:32:22:bb:98:5d:5c:9f:37:28:51:09:f9:2b:
                    d8:e4:42:dc:72:c1:2e:8d:a5:94:2e:e8:e2:dd:a6:
                    96:5c:7d:f1:35:56:e6:bb:f0:ec:c4:cc:32:9f:9b:
                    89:86:c9:2f:71:d4:47:35:e8:f5:82:b0:1a:81:76:
                    c5:af:06:c7:25:cd:38:f3:14:5c:be:e4:fd:fa:be:
                    ac:18:e2:d2:e1:60:bc:dc:e8:ec:53:c9:6c:fb:a1:
                    ed:bd
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                05:52:13:C0:13:7C:A4:27:C5:80:2B:E8:E8:16:F4:17:10:49:C0:1F
            X509v3 Authority Key Identifier: 
                keyid:C7:2A:EC:69:12:52:03:24:65:F6:B1:C2:A2:05:3C:05:49:E3:18:7C

            X509v3 Subject Alternative Name: 
                IP Address:10.32.1.170, DNS:10.32.1.170, DNS:t-dbu-01.araneaconsult.de, DNS:t-dbu-01
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            2.16.840.1.113719.1.9.4.1: 
                0............Novell Security Attribute(tm).Chttp://developer.novell.com/repository/attributes/certattrs_v10.htm0..H.....0.0......F0.0......
.........................0.0.................0.0............................Q.N0L...........
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 CRL Distribution Points: 

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

                Full Name:
                  URI:ldap://10.32.1.170:389/CN=One,CN=One%20-%20Configuration,CN=CRL%20Container,CN=Security

                Full Name:
                  URI:https://10.32.1.170:8030/crl/one.crl

                Full Name:
                  URI:ldaps://10.32.1.170:636/CN=One,CN=One%20-%20Configuration,CN=CRL%20Container,CN=Security

                Full Name:
                  DirName: CN = One, CN = One - Configuration, CN = CRL Container, CN = Security

    Signature Algorithm: sha256WithRSAEncryption
         b0:27:e2:e1:ad:c2:01:a4:7f:4d:99:8d:16:cb:c1:b2:10:ec:
         b1:53:50:cc:3b:ef:8d:a1:a4:fc:29:d5:7a:d7:05:9c:0a:bf:
         3b:82:c1:bd:9b:99:09:d4:11:1b:f5:a1:17:d3:30:ab:e5:38:
         57:f7:f4:53:b6:19:9c:05:03:8b:ee:e4:d8:12:05:45:0a:a2:
         c2:0f:29:ce:8b:ab:4f:44:fd:83:95:a8:82:a4:25:11:a2:98:
         e2:25:aa:e3:4b:67:b8:1c:25:3b:7d:23:f2:00:f6:4d:29:e4:
         5b:b3:82:c1:20:92:7e:49:ca:1a:b8:b6:8d:3d:e7:0d:86:d6:
         8d:be:06:05:b9:c4:30:59:b5:62:9b:6c:01:06:05:ff:b0:e3:
         23:20:15:bf:09:03:90:7c:53:93:f9:e3:0f:43:7e:d2:f1:36:
         87:5d:66:e0:28:ba:62:44:b2:24:14:73:df:51:ee:77:0c:d8:
         11:0c:4b:03:4d:63:11:42:91:49:7f:0f:23:a4:b3:b2:83:c5:
         76:a1:3d:6e:65:0e:31:86:96:ae:ad:c6:62:ed:44:86:a6:b9:
         c2:c9:3c:74:ca:1a:c0:bc:ea:27:5e:4c:9d:77:6d:82:a0:9f:
         80:66:d1:06:0f:0e:b8:cf:c2:79:7f:db:da:a3:87:cd:77:ef:
         09:74:40:29
-----BEGIN CERTIFICATE-----
MIIHAzCCBeugAwIBAgIUdeYHM4XCFCerDcQdbOxxAmJC7eQwDQYJKoZIhvcNAQEL
BQAwNTEaMBgGA1UECxMRT3JnYW5pemF0aW9uYWwgQ0ExFzAVBgNVBAoTDkRCVVND
SEtFLUlETTQ2MB4XDTE3MDMyMDA5MDkwMFoXDTI3MDMxODA4NDQwMFowPTEXMBUG
A1UEChMOREJVU0NIS0UtSURNNDYxIjAgBgNVBAMTGXQtZGJ1LTAxLmFyYW5lYWNv
bnN1bHQuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUfFsMd6fl
+72Nc1mcjZo6dImoeH0BJ3heCIkdSCwqGVwWVx3+3naR5UMrC15mm522I1eQV31R
fIzcnZ2/zEDR2ixleNp4w9yeRDBunq1u15oq0MJheJqzLFMQ9FoJg3t958udwrvj
gtbHFBHgS3r3c+GZCDRkoEBkRwMhH/yiTz5LYvxEsstga8t4aKGnneD1oHphahNG
QVzuLEddWeg4ZTiy4UvjMiK7mF1cnzcoUQn5K9jkQtxywS6NpZQu6OLdppZcffE1
Vua78OzEzDKfm4mGyS9x1Ec16PWCsBqBdsWvBsclzTjzFFy+5P36vqwY4tLhYLzc
6OxTyWz7oe29AgMBAAGjggQBMIID/TAdBgNVHQ4EFgQUBVITwBN8pCfFgCvo6Bb0
FxBJwB8wHwYDVR0jBBgwFoAUxyrsaRJSAyRl9rHCogU8BUnjGHwwQQYDVR0RBDow
OIcECiABqoILMTAuMzIuMS4xNzCCGXQtZGJ1LTAxLmFyYW5lYWNvbnN1bHQuZGWC
CHQtZGJ1LTAxMAsGA1UdDwQEAwIFoDCCAcwGC2CGSAGG+DcBCQQBBIIBuzCCAbcE
AgEAAQH/Ex1Ob3ZlbGwgU2VjdXJpdHkgQXR0cmlidXRlKHRtKRZDaHR0cDovL2Rl
dmVsb3Blci5ub3ZlbGwuY29tL3JlcG9zaXRvcnkvYXR0cmlidXRlcy9jZXJ0YXR0
cnNfdjEwLmh0bTCCAUigGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpoRoBAQAw
CDAGAgEBAgEAMAgwBgIBAQIBAAIBAKIGAgEXAQH/o4IBBKBYAgECAgIA/wIBAAMN
AIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBgwEAIBAAIIf/////////8BAQACBAbw
30gwGDAQAgEAAgh//////////wEBAAIEBvDfSKFYAgECAgIA/wIBAAMNAEAAAAAA
AAAAAAAAAAMJAEAAAAAAAAAAMBgwEAIBAAIIf/////////8BAQACBBH/qFEwGDAQ
AgEAAgh//////////wEBAAIEEf+oUaJOMEwCAQICAQACAgD/Aw0AgAAAAAAAAAAA
AAAAAwkAgAAAAAAAAAAwEjAQAgEAAgh//////////wEBADASMBACAQACCH//////
////AQEAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMIIBhAYDVR0fBIIBezCCAXcwKaAn
oCWGI2h0dHA6Ly8xMC4zMi4xLjE3MDo4MDI4L2NybC9vbmUuY3JsMF2gW6BZhlds
ZGFwOi8vMTAuMzIuMS4xNzA6Mzg5L0NOPU9uZSxDTj1PbmUlMjAtJTIwQ29uZmln
dXJhdGlvbixDTj1DUkwlMjBDb250YWluZXIsQ049U2VjdXJpdHkwKqAooCaGJGh0
dHBzOi8vMTAuMzIuMS4xNzA6ODAzMC9jcmwvb25lLmNybDBeoFygWoZYbGRhcHM6
Ly8xMC4zMi4xLjE3MDo2MzYvQ049T25lLENOPU9uZSUyMC0lMjBDb25maWd1cmF0
aW9uLENOPUNSTCUyMENvbnRhaW5lcixDTj1TZWN1cml0eTBfoF2gW6RZMFcxDDAK
BgNVBAMTA09uZTEcMBoGA1UEAxMTT25lIC0gQ29uZmlndXJhdGlvbjEWMBQGA1UE
AxMNQ1JMIENvbnRhaW5lcjERMA8GA1UEAxMIU2VjdXJpdHkwDQYJKoZIhvcNAQEL
BQADggEBALAn4uGtwgGkf02ZjRbLwbIQ7LFTUMw7742hpPwp1XrXBZwKvzuCwb2b
mQnUERv1oRfTMKvlOFf39FO2GZwFA4vu5NgSBUUKosIPKc6Lq09E/YOVqIKkJRGi
mOIlquNLZ7gcJTt9I/IA9k0p5FuzgsEgkn5Jyhq4to095w2G1o2+BgW5xDBZtWKb
bAEGBf+w4yMgFb8JA5B8U5P54w9DftLxNoddZuAoumJEsiQUc99R7ncM2BEMSwNN
YxFCkUl/DyOks7KDxXahPW5lDjGGlq6txmLtRIamucLJPHTKGsC86ideTJ13bYKg
n4Bm0QYPDrjPwnl/29qjh8137wl0QCk=
-----END CERTIFICATE-----

--nextPart11843649.FvnNQJo7RH--



0
Daniel
3/20/2017 10:02:20 AM
mozilla.support.firefox 23866 articles. 6 followers. Post Follow

4 Replies
96 Views

Similar Articles

[PageSpeed] 26

Daniel Buschke <daniel.buschke@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)?
0
VanguardLH
3/21/2017 12:46:53 AM
Hi,

On 2017 M03 20, Mon 19:46:53 CET VanguardLH wrote:
> Daniel Buschke <daniel.buschke@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

0
Daniel
3/21/2017 8:08:21 AM
Daniel Buschke <daniel.buschke@araneaconsult.de> wrote:

> VanguardLH wrote:
>
>> Daniel Buschke <daniel.buschke@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?

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.
0
VanguardLH
3/21/2017 12:42:39 PM
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>"?
> ...

0
Daniel
3/21/2017 3:21:38 PM
Reply: