Please report any other irregularities here.
In NSS 3.11.x signtool, it is not possible to sign a JAR using a cert that lacks an extension that explicitly identifies it as an object signing cert. We have a trust flag that *should* solve that problem, acting as an override, causing the cert to be treated as if it had the desired extension. That that trust flag presently has no effect on the NSS library functions used by signtool. The code paths used by signtool never read the trust flags and alter the nsCertType field in the CERTCertificate struct to reflect the cert usages that should be enabled by trust flags. This is a regression. In the past, trust flags HAVE been able to make non-code signing certs usable as code signing certs. This may be due to changes in the NSS libs, or in signtool itself, or both. I don't know how far back this regression goes. It may be all the way to 3.4. I am investigating this. I remember discovering that some paths do, and some paths do not, take the trust flags into account back when I was working with Julien on bug 201134. I am trying to refresh my memory on those discoveries now.
This problem is another manifestation of a bug that was previously found and fixed on the trunk, I believe. It was previously encountered by libPKIX code. See the description of the problem in bug 390381 comment 11 and the solutions proposed in bug 390381 comment 19 (and surrounding comments). That manifestation of this bug was fixed on the trunk with the checkin of attachment 309337 [details] [diff] [review] (the last patch attached to bug 390381). I am inclined to try to fix this bug by backporting that attachment to the NSS 3.11 branch. I will test that. Other alternatives include: - committing one of the other changes proposed in bug 390381 comment 19, - (assuming this bug is already fixed on the trunk) document this bug as a known bug in NSS 3.11, but don't fix it there.
Priority: -- → P1
Version: 3.11 → 3.8.1
The "fix" in attachment 309337 [details] [diff] [review] does not fix this problem. Tht fix is for CA trust flags only. It applies overrides for CA trust flags but not for "peer" trust flags. So, backporting that attachment (which is trivial to do, it applies cleanly) may be necessary, but is not sufficient. There also appears to be another problem. It seems that we can no longer set both the peer and CA trust flags. The following sequence of commands certutil -d DBDIR -M -n nickname -t ,,CP certutil -d DBDIR -L only reports the ,,C flag. The P flag appears to be lost. :( Looks like I will need to fix that, too.
Priority: P1 → P2
Target Milestone: 3.11.10 → ---
You need to log in before you can comment on or make changes to this bug.