[
https://issues.apache.org/jira/browse/NIFI-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough reassigned NIFI-1364:
----------------------------------
Assignee: Nathan Gough (was: Andy LoPresto)
> 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: Nathan Gough
> Priority: Major
> 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
(v7.6.3#76005)
