Bug 505682

Summary: Allow configuration of NSS OCSP cache settings.
Product: Red Hat Enterprise Linux 5 Reporter: Jack Magne <jmagne>
Component: mod_nssAssignee: Jack Magne <jmagne>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: high Docs Contact:
Priority: high    
Version: 5.3CC: benl, cfu, dpal, emaldona, kchamart, kwright, msauton, rcritten, rrelyea, shaines, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-19 17:04:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 512842    

Description Jack Magne 2009-06-12 21:58:46 UTC
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):


How reproducible:


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.


 extern SECStatus
 CERT_OCSPCacheSettings(PRInt32 maxCacheEntries,
                         PRUint32 minimumSecondsToNextFetchAttempt,
                         PRUint32 maximumSecondsToNextFetchAttempt);

 Also the crucial defaults seem to be set this way:


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:


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.

 CERT_SetOCSPTimeout(PRUint32 seconds);


Comment 1 Chandrasekar Kannan 2009-06-15 20:45:49 UTC
can we shoot this for rhel 5.5 ?

Comment 4 Marc Sauton 2009-10-28 19:04:59 UTC
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

Comment 6 Rob Crittenden 2009-10-28 19:21:54 UTC
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.

Comment 7 Jack Magne 2009-10-28 20:10:44 UTC
I agree with Rob. We need to bite the bullet and provide this functionality.

Comment 36 errata-xmlrpc 2009-11-19 17:04:29 UTC
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.