Andy LoPresto created NIFI-1364:
-----------------------------------
Summary: 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
Fix For: 0.6.0
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)
