Closed Bug 122720 Opened 19 years ago Closed 19 years ago

CA certs loaded but not shown in cert manager.

Categories

(NSS :: Libraries, defect, P1)

x86
All
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ssaux, Assigned: rrelyea)

References

Details

Attachments

(1 file)

This is the NSS bug for PSM bug 121487
blocks 121487
Blocks: 121487
Priority: -- → P1
Target Milestone: --- → 3.4
No longer blocks: 121487
Bob, could you take a look at this bug?
Assignee: wtc → relyea
This single patch may fix the whole problem. I have an additional suggested
patch for PSM as well.
Comment on attachment 68210 [details] [diff] [review]
Don't use the trust bits if none are sset.

>-    if ( cert->trust ) {
>+    if ( cert->trust && (cert->trust->sslFlags|cert->trust->emailFlags|
>+				cert->trust->objectSigningFlags)) {

Just curious, why are you using | as opposed to || here?
Because they're bit fields, not Booleans. The test is 'if all the bits in all
the trust flags are '0' then treat the trust field and non-existant and use the
extensions in the cert to determine if this is a CA cert or not'

More accurately ((sslflags|emailflags|objectSigningFlags) == 0).

It's also slightly more efficent code (the C compilier doesn't have to to the
implicit cast to bool for each single element, just the final cast of the whole
thing).
So it is just a terse way of saying
sslflags == 0 && emailflags == 0 && objectSigningFlags == 0 ?

Yes
Adding "blocks 121487" (see comment 1).
Blocks: 121487
Bob had checked this patch in to the tip of NSS (1.24), but is not yet used by
Mozilla (client tag currently on 1.23). I'm testing whether this fixes bug 121487.

No longer blocks: 121487
(Re adding "blocks 121487". Is that a bugzilla bug or what?).
Blocks: 121487
This is now on the client tag.

I was unable to reproduce 121487 with the cert in question, however I have found
another bug 125557. The problem occurs if you have at least 16 certs in your
database, some (random) certs would not show up in your listing. Which certs and
how many depends on your dbsize mod 16. Fix for this second problem should be in
NSS by this evening, and in PSM by Monday.

bob
BTW resolving this problem fixed (since the tag has moved).
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Revision 1.23 of certdb/certdb.c claims that it was committed to fix this bug 
and bug 121487.  See 
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/security/nss/lib/certdb&command=DIFF_FRAMESET&file=certdb.c&rev2=1.23&rev1=1.22

That change had the effect that any certs imported by CERT_ImportCerts have
the VALID_PEER or VALID_CA trust flags set.  

Those trust flags are OVERRIDES.  They cause a lot of cert validity checking 
to be skipped during cert verification.  One consequence of setting the 
VALID_CA trust bit is that it turns any intermediate CA into a valid object 
signing CA, completely defeating the logic that checks for an EKU extension 
to enable object signing.

These OVERRIDE trust bits should NEVER be set routinely.  They should ONLY 
be set when necessary to make a badly constructed cert work. 

So, this "fix" actually introduced a serious bug into NSS, turning all
imported CA certs into object signing CA certs.  

The original problem of PSM not displaying some CA certs should have been
fixed without necessitating that the VALID_CA override be set in all CA
certs.  Perhaps PSM remains dependent on this incorrect behavior.

This NSS flaw needs to be fixed.  I will file a new bug about this.
QA Contact: sonja.mirtitsch → libraries
You need to log in before you can comment on or make changes to this bug.