Matt,
We found the "ocsp.enable" Java Security setting in
$JRE/lib/security/java.security, but setting that did NOT change the
behavior and the node with the revoked certificate could still join the
cluster.
Looking at the posts referenced by NIFI-1364 [1], they all seem to discuss
needed code changes. For example, the first link [2], includes this
example.
PKIXParameters params = new PKIXParameters(anchors);
// Activate certificate revocation checking
params.setRevocationEnabled(true);
// Activate OCSP
Security.setProperty("ocsp.enable", "true");
It looks like "ocsp.enable" may only matter if revocation is enabled in the
first place and that appears to be what the
PKIXParameters.setRevocationEnabled(true) call accomplishes. I don't know
the clustering code well enough to dive in, but if you can point out where
to look I can try digging into it myself. For now, it still appears that
cluster nodes are not rejected due to OCSP revocation.
Thanks,
Joe
[1] https://issues.apache.org/jira/browse/NIFI-1364
[2] https://blogs.oracle.com/xuelei/entry/enable_ocsp_checking
On Mon, Dec 19, 2016 at 5:57 PM, Joe Skora <[email protected]> wrote:
> Thanks, I'll check on the configuration used for the tests and reply back
> here once that's clear.
>
> On Mon, Dec 19, 2016 at 12:48 PM, Matt Gilman <[email protected]>
> wrote:
>
>> The existing OCSP logic is part of the REST API filter chain. The
>> communications you're referring to are happening outside of that. Have you
>> tried enabling OCSP as part of the SSL/TLS handshake as was mentioned in
>> the JIRA [1]. Using the built-in features should allow us to use it
>> throughout the application regardless of the communications in question
>> (cluster protocol, site to site, REST API, etc).
>>
>> Matt
>>
>> [1] https://issues.apache.org/jira/browse/NIFI-1364
>>
>> On Mon, Dec 19, 2016 at 12:18 PM, Joe Skora <[email protected]> wrote:
>>
>> > Matt,
>> >
>> > It's not clients we are concerned with, but cluster servers.
>> >
>> > The test process used Java 1.8.0_65 and NiFi 0.7.1 to do the following.
>> >
>> > 1. Configure a cluster with valid certificates for each node,
>> > 2. revoke one node's certificate,
>> > 3. restart the cluster,
>> > 4. confirm with keytool that the node is invalid, and
>> > 5. test whether the node can still join the cluster.
>> >
>> > The expectation was that in #5 the node would not be able to join to the
>> > cluster, but it could.
>> >
>> > Whether the OCSP check should be handled by NiFi or Java, it doesn't
>> appear
>> > to be happening.
>> >
>> > Thanks,
>> > Joe
>> >
>> > On Mon, Dec 19, 2016 at 11:22 AM, Matt Gilman <[email protected]>
>> > wrote:
>> >
>> > > Joe,
>> > >
>> > > If a server connects through the REST API it should be subject to the
>> > same
>> > > checks as a regular user. Can you provide more details regarding the
>> > > requests that aren't being checked correctly?
>> > >
>> > > Additionally, there was some discussion whether we need the additional
>> > > checks in the first place as we may be able to leverage checks built
>> into
>> > > Java [1].
>> > >
>> > > Matt
>> > >
>> > > [1] https://issues.apache.org/jira/browse/NIFI-1364
>> > >
>> > > On Mon, Dec 19, 2016 at 10:57 AM, Joe Skora <[email protected]> wrote:
>> > >
>> > > > This could very soon be a show stopper for us.
>> > > >
>> > > > Does anyone have any thoughts that might help us get this straight?
>> > > >
>> > > > On Wed, Dec 14, 2016 at 2:23 PM, Joe Skora <[email protected]>
>> wrote:
>> > > >
>> > > > > Running Apache NiFi 0.7.1, we see clients rejected due to OCSP
>> > > revocation
>> > > > > of their certificates but we think we are seeing instances where
>> > > servers
>> > > > > using OCSP revoked certificates are still able to connect to a
>> > cluster.
>> > > > >
>> > > > > Should OCSP revocation cause these servers to be rejected by the
>> > > cluster?
>> > > > >
>> > > > > Could this be a configuration problem even though the revoked
>> clients
>> > > > > certificates are rejected?
>> > > > >
>> > > > > Thanks,
>> > > > > Joe
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
