Description of problem: The package currently supports enabling NSS's OCSP functionality through various configuration parameters. Unfortunately, the configuration does not account for the OCSP caching functionality in NSS as of NSS 11.7. It would be great to allow the user to tune this behavior. Version-Release number of selected component (if applicable): 1.0.8-1 How reproducible: Always. Steps to Reproduce: 1. Configure our TPS or RA server for OCSP. 2. Go to a TPS page protected by a client cert. 3. Note that the OCSP has been consulted for this cert. 4. Use the CA's EE interface to put the same cert in the "on hold" state. 5. Proceed to the same TPS page. Actual results: The recently revoked user can still get in. Expected results: It would be nice to have the option to configure Mod_Nss such that the caching behavior can be controlled as desired. Additional info: Information about how to control NSS's OCSP behavior: The following function can be called in the initialize procedure to modify how the caching is done. http://mxr.mozilla.org/security/ident?i=CERT_OCSPCacheSettings extern SECStatus CERT_OCSPCacheSettings(PRInt32 maxCacheEntries, PRUint32 minimumSecondsToNextFetchAttempt, PRUint32 maximumSecondsToNextFetchAttempt); Also the crucial defaults seem to be set this way: #define DEFAULT_OCSP_CACHE_SIZE 1000 #define DEFAULT_MINIMUM_SECONDS_TO_NEXT_OCSP_FETCH_ATTEMPT 1*60*60L #define DEFAULT_MAXIMUM_SECONDS_TO_NEXT_OCSP_FETCH_ATTEMPT 24*60*60L #define DEFAULT_OSCP_TIMEOUT_SECONDS 60 #define MICROSECONDS_PER_SECOND 1000000L The parameters: maxCacheEntries: This controls the size of the cache. A value of -1 supposedly disables the cache altogether. The default is 1000. minimuSecondsToNextFetchAttempt: This is the least amount of time before a new fetch for a cert is done. The default is 60 mins. maximumSecondsToNextFetchAttempt: This is an upper bound to how long it might take for the next fetch. Apparently an OCSP response can send back information about how often it would be a good idea to contact it. This upper bound is here to step in even if the server says don't call me for several days. The default is one day. Proposed new config params something like: NSSOCSPCacheSize NSSOCSPMinCacheEntryDuration NSSOCSPMaxCacheEntryDuration As a bonus it might be nice to be able to configure the OCSP timeout, to control how long to wait for an answer. Now it is set to 60 secs. SECStatus CERT_SetOCSPTimeout(PRUint32 seconds); http://mxr.mozilla.org/security/ident?i=CERT_SetOCSPTimeout
can we shoot this for rhel 5.5 ?
How can one disable NSSOCSP caching? In Jack's initial description, I would say this is much more important than a great feature "to allow the user to tune this behavior.", the actual results are a serious issue: Known scenario for Certificate System subsystems access relaying on NSS OCSP: TPS's agent client auth, issue-tracker 359251
I don't believe that one can disable caching without this proposed tuning. Once this is done then setting maxCacheEntries < 0 will disable the cache.
I agree with Rob. We need to bite the bullet and provide this functionality.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1596.html