Closed Bug 154121 Opened 22 years ago Closed 20 years ago

Mozilla doesn't add certificate chain properly


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

1.0 Branch


(Not tracked)



(Reporter: timtas, Assigned: jgmyers)





(3 files)

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

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

Any fix/workaround avaliable?
This is the file containing the ca certificates to add
Priority: -- → P3
Version: unspecified → 2.3
*** Bug 158823 has been marked as a duplicate of this bug. ***
Ever confirmed: true
Keywords: nsbeta1
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.

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

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.
Assignee: ssaux → wtc
Component: Client Library → Libraries
Product: PSM → NSS
QA Contact: junruh → bishakhabanerjee
Version: 2.3 → unspecified
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.
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.
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:
I use Mozilla 1.0 and it is _not_ working, only the root is imported.

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.
-> PSM
Assignee: wtc → ssaux
Component: Libraries → Client Library
Product: NSS → PSM
QA Contact: bishakhabanerjee → junruh
Target Milestone: --- → Future
-> me
Assignee: ssaux → kaie
Keywords: nsbeta1nsbeta1+
Summary: Mozilla doesnt add certificate chain properly → Mozilla doesn't add certificate chain properly
Nelson B today said on IRC:

"I view the document 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."
Since we don't behave as the specifications say, I propose this should be a P1 bug.
Priority: P3 → P1
Version: unspecified → 2.4
Didn't find this bug earlier when I attempted to submit a new one.

I have additional information posted at:
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.  
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?
*** Bug 194245 has been marked as a duplicate of this bug. ***
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.
nsCRT::strcmp() doesn't work too well on UTF-16.  Patch forthcoming.
Assignee: kaie → jgmyers
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

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.
Attachment #139154 - Flags: review?(kaie)
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.
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.
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.
> 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 on attachment 139154 [details] [diff] [review]
Patch to fix the string comparison

Attachment #139154 - Flags: review?(kaie) → review+
Attachment #139154 - Flags: superreview?(sspitzer)
Comment on attachment 139154 [details] [diff] [review]
Patch to fix the string comparison

Attachment #139154 - Flags: superreview?(sspitzer) → superreview+
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.

Closed: 20 years ago
Resolution: --- → FIXED
Product: PSM → Core
Version: psm2.4 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.