[
https://issues.apache.org/jira/browse/NIFI-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15767342#comment-15767342
]
Matt Gilman edited comment on NIFI-1364 at 12/21/16 3:40 PM:
-------------------------------------------------------------
Following a conversation on the mailing list [1] I did some testing of
certificate revocation specifically for clients of the REST API and the cluster
protocol. I was able to successfully use Java's built-in OCSP verification for
both. We should consider the following for this JIRA:
1) Remove the legacy OCSP verification
2) Support configuration of Java's built-in OCSP verification. Specifically,
when building an SSLContext I believe we need to configure the
TrustManagerFactory as below. Though I believe this is only applicable when
TrustManagerFactory.getDefaultAlgorithm() is PKIX. Probably makes sense to
revert to the current implementation when it is not:
{code}
PKIXBuilderParameters pbParams = new PKIXBuilderParameters(trustStore, new
X509CertSelector());
pbParams.setRevocationEnabled(true);
Security.setProperty("ocsp.enable","true");
TrustManagerFactory trustManagerFactory =
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init(new CertPathTrustManagerParameters(pbParams));
{code}
There are a couple places (cluster protocol, site to site, etc) where these
changes would be required as mentioned in the JIRA description. We should
consider consolidating these during this effort. Additionally, there are other
OCSP features that we should consider offering support for [2].
One thing I noted during my testing that is likely a follow on JIRA. When a
node in the cluster with a valid certificate was chosen as the coordinator the
behavior was as expected. Nodes with valid certificates joined. Nodes with
revoked certificates could not. However, if a node with a revoked certificate
was chosen as the coordinator, no nodes could join the cluster.
[1]
https://lists.apache.org/thread.html/fe6d34c375a459d3aaf997e9350f3bbba141d562a733dfd496697ccd@%3Cdev.nifi.apache.org%3E
[2]
http://docs.oracle.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html#AppC
was (Author: mcgilman):
Following a conversation on the mailing list [1] I did some testing of
certificate revocation specifically for clients of the REST API and the cluster
protocol. I was able to successfully use Java's built-in OCSP verification for
both. We should consider the following for this JIRA:
1) Remove the legacy OCSP verification
2) Support configuration of Java's built-in OCSP verification. Specifically,
when building an SSLContext I believe we need to configure the
TrustManagerFactory as below. Though I believe this is only applicable when
TrustManagerFactory.getDefaultAlgorithm() is PKIX. Probably makes sense to
revert to the current implementation when it is not:
{code}
PKIXBuilderParameters pbParams = new PKIXBuilderParameters(trustStore, new
X509CertSelector());
// Make sure revocation checking is enabled
pbParams.setRevocationEnabled(true);
// Enable On-Line Certificate Status Protocol (OCSP) support
Security.setProperty("ocsp.enable","true");
TrustManagerFactory trustManagerFactory =
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init(new CertPathTrustManagerParameters(pbParams));
{code}
There are a couple places (cluster protocol, site to site, etc) where these
changes would be required as mentioned in the JIRA description. We should
consider consolidating these during this effort. Additionally, there are other
OCSP features that we should consider offering support for [2].
One thing I noted during my testing that is likely a follow on JIRA. When a
node in the cluster with a valid certificate was chosen as the coordinator the
behavior was as expected. Nodes with valid certificates joined. Nodes with
revoked certificates could not. However, if a node with a revoked certificate
was chosen as the coordinator, no nodes could join the cluster.
[1]
https://lists.apache.org/thread.html/fe6d34c375a459d3aaf997e9350f3bbba141d562a733dfd496697ccd@%3Cdev.nifi.apache.org%3E
[2]
http://docs.oracle.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html#AppC
> Audit OCSP certificate validation
> ---------------------------------
>
> Key: NIFI-1364
> URL: https://issues.apache.org/jira/browse/NIFI-1364
> Project: Apache NiFi
> Issue Type: Task
> Components: Core Framework
> Affects Versions: 0.4.1
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Labels: certificate, ocsp, security
>
> While upgrading the version of BouncyCastle libraries used, I had to re-write
> the OCSP certificate validation code because BC split the PKIX code into a
> separate module and renamed many classes & methods. During this re-write, I
> made the code compile using the new logic, but I am unsure that OCSP
> validation needs to occur outside of the SSL/TLS negotiation, or that the
> current mechanism is correct.
> Questions:
> * Can we use Java's built-in OCSP validation? [1][2]
> * Is the current mechanism correct, where a local cache is used with custom
> internal classes representing OCSP requests and statuses, and it queries a
> pre-specified OCSP responder as opposed to the per-certificate OCSP responder
> listed in each certificate's Authority Information Access OCSP URI [3]? I
> think this design decision stems from a legacy environment which may not
> apply to current use cases.
> More information: [4]
> [1] https://blogs.oracle.com/xuelei/entry/enable_ocsp_checking
> [2]
> https://stackoverflow.com/questions/8506661/check-x509-certificate-revocation-status-in-spring-security-before-authenticatin
> [3]
> https://blog.ivanristic.com/2014/02/checking-ocsp-revocation-using-openssl.html
> [4]
> https://raymii.org/s/articles/OpenSSL_Manually_Verify_a_certificate_against_an_OCSP.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
