Jack Magne 2018-09-20 21:51:17 EDT

Commit downstream / origin/TOMCATJSS_7_2_BRANCH

commit c7e9138d59833ca0b9437fd130d3d9cb2fdf393d
Author: John Magne <jmagne.redhat.com>
Date:   Thu Sep 20 21:35:20 2018 -0400

    Fix for Bug 1630469 - CC: tomcatjss: unable to enable OCSP checking from peer AIA extension.
    
        Now the server.xml can be configured to enable ocsp AND leave other settings null, to trigger
        NSS to use the AIA extension to locate the ocsp responder.
    
        ex:
    
         <Connector name="Secure" port="18443" ...
             .....
             enableOCSP="true"  ocspCacheSize="1000" ocspMinCacheEntryDuration="60" ocspMaxCacheEntryDuration="120" ocspTimeout="10"

 Jack Magne 2018-09-20 21:57:38 EDT

Testing instructions:

In order to test this functionality do the following:

Create a CA
Create a KRA and make sure the AIA extension of each system cert for the KRA points to something like this:

http://test.host.com:8080/ca/ocsp

This is what you get by default if a simple kra install is done and points to the security domain of the CA during pkispawn.

Stop the KRA and reconfigure the Connector of the SSL port in the kra instances "server.xml" file such as this:

<Connector name="Secure" port="18443" ...
             .....
             enableOCSP="true"  ocspCacheSize="1000" ocspMinCacheEntryDuration="60" ocspMaxCacheEntryDuration="120" ocspTimeout="10"

Note that we have left out the settings for ocspResponderURL and ocspSigingCertNickname, or whatever the actual strings are. This means that ONLY enableOCSP="true" is set. This means that NSS will ultimately be forced to find the ocsp responder url from a given cert's AIA extension, instead of a default value we may have configured here.

Now restart the KRA while putting a tail on teh CA's log.

While the KRA restarts we should observe the CA's internal ocsp responder coming to life, verifying various certs associated with the KRA.


Note: That of course certs can be applied for with the AIA extension pointing to  outboard ocsp responders as well. When we want specific certs to hit specific responders, this is how it should be tested.

I tested this BZ on the 10.5.9-7.el7_6, As jack mentioned steps in the #comment 3, I'm able to see the CA's internal OCSP is coming up.

Marking this bug as verified.

Steps which followed to verify this BZ:
- Install standalone CA
- Install standalone KRA
- Modify KRA's server.xml file
  - Remove "ocspResponderURL=*" and "ocspSigingCertNickname=*"
  - Set enableOCSP=true
- Restart the KRA
- While restarting KRA, put tail on CA's debug log. KRA subsystem pick up OCSP URI (CA's internal OCSP URI) from certificates AIA extension.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0167