Open Bug 1239313 Opened 8 years ago Updated 2 years ago

Support name comparison across string types in certificates

Categories

(NSS :: Libraries, defect, P3)

Product:
NSS
Component:
Libraries
Version:
3.22
Type:
defect

Tracking

(Not tracked)

People

(Reporter: gerv, Unassigned)

Details

Firefox has a problem accessing https://cl.siemens.com/ . 

The SSLLabs test gives it a clean bill of health:
https://www.ssllabs.com/ssltest/analyze.html?d=cl.siemens.com

Specifically, it says that the server _is_ sending the "Siemens Internet CA V1.0" certificate. However, if you go to the site in Firefox and look at the certificate viewer, Firefox appears not to be noticing that certificate (and therefore can't make a complete chain).

I'm filing this in NSS :: Libraries because cert handling and parsing is, AIUI, an NSS function. Please move this bug if I'm wrong.

Gerv
The certificate chain of https://cl.siemens.com/ can't be verified by any browser or openssl. So this doesn't seem to be an NSS issue.
The original reporter (by email) said:

"Hello guys,

we have problems connecting to https://cl.siemens.com with a fresh installation of Firefox (no import of any CA-Certificates). The error message is:

cl.siemens.com uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported. (Error code: sec_error_unknown_issuer)

With other browsers there is no problem. Could you please advice."

Should I ask him which other browsers he tested with?

Gerv
"can't be verified by any browser" - it works just fine in Chrome/Windows
"or OpenSSL" - well, that's not true, SSLLabs can pick it up :)

"fresh installation of Firefox" - the root it changes to (Baltimore CyberTrust) has been in for ages ( http://mxr.mozilla.org/nss/source/lib/ckfw/builtins/certdata.txt#1821 ) and is trusted for Web.

Some more debugging is still needed - I'm not sure what franziskus tested, but works on other platforms is definitely true.
hm, ok. I tested Linux and Mac FF and Chrome and openssl on Linux. But sounds like something is fishy here.

While the chain looks good to me, importing the intermediate certificate (Siemens Issuing CA Class Internet Server 2013) that signs the cert solves the problem. Importing only the CA (Siemens Internet CA V1.0) doesn't help.
This fails on every browser I have on my MacBook -- Nightly, Chrome, Safari, Yandex.  So at least it's not just a Firefox problem.

Keeler: Can you take a look at why this chain doesn't complete?
Flags: needinfo?(dkeeler)
Here's what I'm seeing. The server sends a chain like so:

 0 s:/OU=Trustcenter/O=Siemens/C=DE/ST=Bavaria/L=Munich/CN=cl.siemens.com
   i:/C=DE/O=Siemens/serialNumber=ZZZZZZY9/OU=Copyright (C) Siemens AG 2013 All Rights Reserved/CN=Siemens Issuing CA Class Internet Server 2013

 1 s:/C=DE/O=Siemens/serialNumber=ZZZZZZY9/OU=Copyright (C) Siemens AG 2013 All Rights Reserved/CN=Siemens Issuing CA Class Internet Server 2013
   i:/C=DE/O=Siemens/serialNumber=ZZZZZZV0/OU=Copyright (C) Siemens AG 2011 All Rights Reserved/CN=Siemens Internet CA V1.0

 2 s:/C=DE/O=Siemens/serialNumber=ZZZZZZV0/OU=Copyright (C) Siemens AG 2011 All Rights Reserved/CN=Siemens Internet CA V1.0
   i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root

Looking more closely, the issuer field of the 2013 certificate is encoded as follows:

SEQUENCE(5 elem)
  SET(1 elem)
    SEQUENCE(2 elem)
      OBJECT IDENTIFIER 2.5.4.6
      PrintableString DE
  SET(1 elem)
    SEQUENCE(2 elem)
      OBJECT IDENTIFIER 2.5.4.10
      UTF8String Siemens
  SET(1 elem)
    SEQUENCE(2 elem)
      OBJECT IDENTIFIER 2.5.4.5
      PrintableString ZZZZZZV0
  SET(1 elem)
    SEQUENCE(2 elem)
      OBJECT IDENTIFIER 2.5.4.11
      UTF8String Copyright (C) Siemens AG 2011 All Rights Reserved
  SET(1 elem)
    SEQUENCE(2 elem)
      OBJECT IDENTIFIER 2.5.4.3
      UTF8String Siemens Internet CA V1.0

Note the use of UTF8String. The subject field of the 2011 certificate (i.e. the one that purportedly issued the 2013 certificate) is encoded as follows:

SEQUENCE(5 elem)
  SET(1 elem)
    SEQUENCE(2 elem)
      OBJECT IDENTIFIER 2.5.4.6
      PrintableString DE
  SET(1 elem)
    SEQUENCE(2 elem)
      OBJECT IDENTIFIER 2.5.4.10
      PrintableString Siemens
  SET(1 elem)
    SEQUENCE(2 elem)
      OBJECT IDENTIFIER 2.5.4.5
      PrintableString ZZZZZZV0
  SET(1 elem)
    SEQUENCE(2 elem)
      OBJECT IDENTIFIER 2.5.4.11
      PrintableString Copyright (C) Siemens AG 2011 All Rights Reserved
  SET(1 elem)
    SEQUENCE(2 elem)
      OBJECT IDENTIFIER 2.5.4.3
      PrintableString Siemens Internet CA V1.0

Note that everything is encoded as a PrintableString, not UTF8String. It looks like NSS considers these to not match, and as a result mozilla::pkix has no candidate issuers with which to build a path to a trusted root. This results in the unknown issuer error.
Flags: needinfo?(dkeeler)
W.r.t. SSLLabs: Ivan tells me that the engine there does the following:

- Build chains by chaining AKI/SKI and Subject/Issuer (and following AIA)
- Check those chains using the Java X.509 library

So they're not using OpenSSL (as Ryan suggested above).  That said, it does look like at least my local instance of OpenSSL is OK with what they're sending:

> rbarnes$ openssl version
> OpenSSL 1.0.2d 9 Jul 2015
> rbarnes$ openssl s_client -showcerts -connect cl.siemens.com:443 </dev/null 2>/dev/null | grep Verify
>     Verify return code: 0 (ok)

Libcurl is intolerant:

> rbarnes$ curl --version
> curl 7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
> rbarnes$ curl https://cl.siemens.com/ 
> curl: (60) SSL certificate problem: Invalid certificate chain
I think keeler has correctly identified the problem, namely that NSS doesn't implement the type-insensitive name comparison specified in RFC 5280.  In fact, it seems to just use the octets of the subject as a hash key, so it's a strict octet string match.

https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/pki/tdcache.c#920

This is a divergence from the spec, so I'm re-titling the bug to reflect.  However, given that it's a pretty extensive change (since it affects how NSS stores certificates), it will be a while before it's fixed, so affected people should probably just re-issue the relevant certs.
Summary: Firefox not noticing a cert sent by https://cl.siemens.com/ → Support name comparison across string types in certificates
(In reply to Richard Barnes [:rbarnes] from comment #7)

> Libcurl is intolerant:

> > rbarnes$ curl --version
> > curl 7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
> > rbarnes$ curl https://cl.siemens.com/ 
> > curl: (60) SSL certificate problem: Invalid certificate chain

Depends on the TLS backend it was built to use! With the openssl backend it works...
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.