Bug 505682 - Allow configuration of NSS OCSP cache settings.
Summary: Allow configuration of NSS OCSP cache settings.
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mod_nss
Version: 5.3
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Jack Magne
QA Contact: Chandrasekar Kannan
Depends On:
Blocks: 512842
TreeView+ depends on / blocked
Reported: 2009-06-12 21:58 UTC by Jack Magne
Modified: 2018-10-20 04:03 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-19 17:04:29 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1596 0 normal SHIPPED_LIVE mod_nss bug fix update 2009-11-19 17:04:26 UTC

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.


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