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