Details
-
Task
-
Status: Resolved
-
Major
-
Resolution: Information Provided
-
0.4.1
-
None
Description
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
Attachments
Issue Links
- is related to
-
NIFI-1324 Upgrade to correct version of BouncyCastle
- Resolved
- links to