[ 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)