If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

missing VeriSign code-signing root CA?

RESOLVED INVALID

Status

NSS
Libraries
P1
normal
RESOLVED INVALID
15 years ago
15 years ago

People

(Reporter: bill, Assigned: Nelson Bolyard (seldom reads bugmail))

Tracking

unspecified

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
Mozilla.org just got a code-signing cert from VeriSign but certutil and signtool
can't validate its chain.

When looking at the cert, here's the issuer" info:
CN = VeriSign Class 3 Code Signing 2001-4 CA
OU = Terms of use at https://www.verisign.com/rpa (c)01
OU = VeriSign Trust Network
O = VeriSign, Inc.

In PSM it shows up in the "certificate hierarchy" pane as not having an issuer.

shouldn't this rootCA cert be in our trusted root list?

Comment 1

15 years ago
shadow, you told me in private email that the issuer CA in question
is an intermediate CA.  So this isn't a root CA cert, correct?
Assignee: wtc → nelsonb
Priority: -- → P1
Target Milestone: --- → 3.8
(Assignee)

Comment 2

15 years ago
Sounds like you had a object signing cert issued by an intermediate CA.
It generated a signature that did not include the intermediate CA, 
so the client that attempted to verify the signature could not chain to 
the root.  If that's right, this situation is very similar to SSL servers
that don't install the intermediate CA certs for their server certs, so
the cert chains they send out lack the necessary intermediate CA certs.

The client may have the root, but without the intermediate CA, it cannot
verify the signature on the leaf cert.

Is that what's happening?
(Reporter)

Comment 3

15 years ago
pilot error.  This is an intermediate CA cert issue.

While it's not clear how to add an intermediate CA certificate to a signed file
with signtool, this isn't a "missing root" problem.  I'm marking this bug
INVALID myself.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
(Assignee)

Comment 4

15 years ago
When NSS signs something, it does not check that it has the complete cert 
chain for the cert that will verify the signature.  

When NSS generates a PKCS7 signature, it puts as much of the signing cert 
chain as it can find into the signature.  If it doesn't have the complete
chain, then it puts an incomplete chain in the signature. 

So, I suspect that what happened in this case is that an "object" was signed
and the cert DB did not have the intermediate CA cert, so the generated 
signature was missing the intermediate CA cert.

When a recipient of the signed object goes to verify the signature, if
the signature contains the whole cert chain, including all intermediate 
CA certs, then the recipient only needs to have the root CA cert in its
DB.
(Reporter)

Comment 5

15 years ago
following up for completeness' sake:
signtool automagically includes all the necessary intermediates necessary to
permit certificate path validation by the client.
You need to log in before you can comment on or make changes to this bug.