Bug 505682 - Allow configuration of NSS OCSP cache settings.
Allow configuration of NSS OCSP cache settings.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mod_nss (Show other bugs)
5.3
All Linux
high Severity high
: ---
: ---
Assigned To: Jack Magne
Chandrasekar Kannan
:
Depends On:
Blocks: 512842
  Show dependency treegraph
 
Reported: 2009-06-12 17:58 EDT by Jack Magne
Modified: 2015-01-04 18:39 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-19 12:04:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jack Magne 2009-06-12 17:58:46 EDT
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
Comment 1 Chandrasekar Kannan 2009-06-15 16:45:49 EDT
can we shoot this for rhel 5.5 ?
Comment 4 Marc Sauton 2009-10-28 15:04:59 EDT
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 15:21:54 EDT
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 16:10:44 EDT
I agree with Rob. We need to bite the bullet and provide this functionality.
Comment 36 errata-xmlrpc 2009-11-19 12:04:29 EST
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

Note You need to log in before you can comment on or make changes to this bug.