When installing a new CRL into the certificate database (softoken), the object ID of the new CRL is the same as object ID of the old one. The way the CRL cache will check for an object modification is to first look up if it exists, and then check for its subject. With the current implementation, both tests would pass. The fix is to create a new object ID when the new CRL is installed. This way the CRL cache will know to flush itself and try to fetch a new CRL.
Bob, This needs to get resolved for in order for the CRL cache to be able to pick up changes to the objects. I am planning on checking it in tomorrow.
Assigned the bug to Bob.
Moved to NSS 3.7, priority P1.
Moved to target milestone 3.8 because the original NSS 3.7 release has been renamed 3.8.
The problem that prompted the creation of this defect report was resolved in NSS 3.6 . See bug 167649 . The workaround was for NSS to automatically invalidate the CRL cache for a given CA when a CRL for that CA is imported to softoken. I am marking this bug WONTFIX since it means we don't need to do this complicated fix to softoken.