154121 - Mozilla doesn't add certificate chain properly

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, defect, P1)

Description

[timtas]

When trying to insert a new certificate chain consisting of a self-sigend root
and a root signed intermediate ca, mozilla will only prompt for the intermediate
to trust (not the root) and then insert both ca's for use as "Status Responder
Certificate".

Netscape 4 does add them correctly and lets you trust the root directly.
The chain is in the nseq Format, pem or der, and is delivered with the mime-type
application/x-x509-ca-cert.

Any fix/workaround avaliable?

Comment 1

[timtas]

Attachment: Certificate Chain in nseq Format, PEM encoded

This is the file containing the ca certificates to add

Comment 2

[timtas]

Attachment: C Source for cgi-bin to present the certificates to a browser

Comment 3

[Matthias Versen [:Matti]]

*** Bug 158823 has been marked as a duplicate of this bug. ***

Comment 4

[John Unruh]

Confirming

Comment 5

[Stephane Saux]

workaround is not to trust the intermediate (it's still imported).
Then you go to the certificate manager and edit the trust on the root.

Comment 6

[Kai Engert (:KaiE:)]

This seems to be a problem with NSS' handling of nseq type certificate chains.

For completeness, I copied your nseq certificate chain to my test server:
  http://www.kuix.de/misc/test34/nseq.php
It shows the problem you describe.

Next, I used
  openssl nseq -in your-nseq-chain.pem -out a-x509-file.pem

I created an additional test case, using the certificate chain in x509 format.
It is available at:
  http://www.kuix.de/misc/test34/x509.php

Surprisingly, we handle your chain correctly in this second case.

So I suspect there is a problem within NSS's handling of the nseq chain type,
which causes the wrong certificate to be seen as the root cert.

Comment 7

[Kai Engert (:KaiE:)]

Actually, in the second case only the root certificate gets imported, but not
the intermediate. When downloading PEM files with multiple certs, it seems, only
the first certificate is handled.

Comment 8

[Stephane Saux]

We have an issue in PSM (not NSS) with certificate chains: We assume a certain
order by looking at the first two certs in the DER, and then extrapolating what
we find to all the certs. These assumption is false. The certs could come in not
particular order and we must build the chain completely. There's a bug filed on
this. This issue may be related. How many certs were in your chain?

The application makes the decision of which cert in the chain to trust.

Comment 9

[timtas]

To Stephane: You say you assume a particular order: that's fine by me. I just
have not been able to figure out the order that is working. We can prepare the
chain in any way Mozilla can handle it, it just seems to be the case that there
is no way at all to insert a root and an internediate at the same time.

To Kai: I tested your URL: http://www.kuix.de/misc/test34/x509.php
I use Mozilla 1.0 and it is _not_ working, only the root is imported.

Comment 10

[Kai Engert (:KaiE:)]

Actually I think I was wrong. I see PSM does indeed do some of the handling when
importing the cert. Assigning back to me until I know more.

Comment 11

[Kai Engert (:KaiE:)]

-> PSM

Comment 12

[Kai Engert (:KaiE:)]

-> me

Comment 13

[Kai Engert (:KaiE:)]

Nelson B today said on IRC:

"I view the document
http://wp.netscape.com/eng/security/comm4-cert-download.html#communicator as the
specification for how cert importing should work in Netscape/mozilla browsers.
Each of the 3 content types listed there is able to import a cert chain.
It should be able to import the chain in any of 4 formats, {PKCS7 or nscert},
and {binary, ASCII}
In all cases, the first cert in the chain that is downloaded is the one about
which the GUI will interact with the user (if any interaction is needed).
The remaining certs after the first will be treated as untrusted CAs and will be
added to the cert DB if not already present.
That is (I believe) the intent of how things are supposed to work.
That means that for the content type x-x509-ca-cert, the first cert inthe chain
should be the root CA.
For the other content types, the first cert in the chain should be the leaf cert."

Comment 14

[Kai Engert (:KaiE:)]

Since we don't behave as the specifications say, I propose this should be a P1 bug.

Comment 15

[John Douglass]

Didn't find this bug earlier when I attempted to submit a new one.

I have additional information posted at:

http://testca.gatech.edu/pkcs7-test.html

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

I didn't find out about this bug until today.  Bug 194245 reports a similar
problem but for chains in the form of a PKCS7 signedData.  

In comments 8 and 10 above, the writers mention that certs are processed by
both PSM and NSS.  This creates an ambiguity about whether or not there is 
a problem in NSS that needs to be fixed here.  If this bug in in NSS, then
it affects other NSS-based PKI clients also.

If there is an NSS problem here, I would like to see that fixed in NSS 3.8.
So, I think Kai and I need to work together now to determine whether this bug
is in NSS or PSM or both.  I'd like us to at least diagnose the problems in
this bug and in bug 194245.  

Comment 17

[John Douglass]

Has there been any additional cycles on this particular bug? Not being able to
import a cert chain has a couple of "end user" issues when you want to start
talking about deploying a multi-level PKI heirarchy.

This bug is still unresolved so I assume it's also an issue with the Firebird
branch as well?

Comment 18

[John G. Myers]

*** Bug 194245 has been marked as a duplicate of this bug. ***

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

In answer to the question in comment 17, I believe that the solution to 
this involves a change to PSM.  But PSM has been unstaffed for a while.

Comment 20

[John G. Myers]

nsCRT::strcmp() doesn't work too well on UTF-16.  Patch forthcoming.

Comment 21

[John G. Myers]

Attachment: Patch to fix the string comparison

Fixing the string comparison bug still results in the same behavior for the
test cases.  Mozilla deliberately asks about the most subordinate CA, as
intended by the fix to bug 91407.

I am curious why a web site would include a subordinate CA in the chain if it
wants the client to trust the root CA.	Why not send only the root CA in that
case?

So we can apply this patch to fix the string comparisons and declare the
reporters' desired behavior as INVALID, or we can remove the code that attempts
to detect a certificate chain and always ask about the first cert in the chain.

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

John, What is the relevance of nsCRT::strcmp()'s utf16 comparisons to this bug?
Perhaps I can answer your questions in comment 21 if I knew that.

Comment 23

[John G. Myers]

The code first tries to compare the first cert's subject name with the second
cert's issuer name.  If the names matched, it (heuristically) derived that the
first cert is the root, so it decided to ask the user about the last cert.

The bug was that the comparison used strcmp to compare two UTF-16 strings. 
Since almost all subject names start with a character in the ISO-8859-1
character set, the first byte of the UTF-16 representation would be 0x00. 
strcmp would thus see two zero-length strings, so would always compare them
equal.  It would thus always behave as if the first cert was the root, asking
the user about the last cert.

Comment 24

[Nelson Bolyard (seldom reads bugmail)]

Thanks for that explanation.

I think we agree that the correct behavior is to 
a) import all the certs, and 
b) prompt the user to trust the most subordinate CA there.
So, I think we agree to fix the string comparison and then mark it invalid.

Comment 25

[John Douglass]

> I am curious why a web site would include a subordinate CA in the chain if it
> wants the client to trust the root CA.	Why not send only the root CA in 
> that case?

I think this comes back to a related issue that might be similarly bugged. My
research into this problem came when I was experimenting in a multi-tiered CA
heirarchy and playing with digital signatures.

In the user interface to certs, a user can look at his certs but if all the
certs in the heirarchy are not present then when they look at details they see
"Issuer Unknown". Also if all the certs aren't there, there may be problems
later exporting/importing a PKCS12 into a different browser as well as
certificates that are attached as part of a signing/encrypting process.

I think this had to do with a similar PKCS7 bug in which I theoretically should
be able to put the intermediaries along with the end user cert into a package
and deliver to the browser for processing and incorporation.

I'll see if I can't rig up some tests on THIS similar to what I posted earlier.

- JohnD

Comment 26

[Kai Engert (:KaiE:)]

Comment on attachment 139154 [details] [diff] [review]
Patch to fix the string comparison

r=kaie

Comment 27

[(not reading, please use [e-mail] instead)]

Comment on attachment 139154 [details] [diff] [review]
Patch to fix the string comparison

sr=sspitzer

Comment 28

[John G. Myers]

Although the intended behavior is the opposite of what the reporter wanted,
there was a discrepancy between the actual and intended behavior which has been
corrected.  When a server presents Mozilla with a cert chain in reverse order
(with the most subordinate cert listed first), it will now ask the user about
the most subordinate cert, as intended.  I am thus closing this bug as FIXED.