-
Notifications
You must be signed in to change notification settings - Fork 7.3k
ZOOKEEPER-4942: Add option to preserve JVM TLS certification revocation properties #2271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please fix the build, otherwise lgtm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
License header is missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we merge #2270 , do we still need this change?
| if (!crlEnabled.isSystem() || !ocspEnabled.isSystem()) { | ||
| if (crlEnabled.isTrue() || ocspEnabled.isTrue()) { | ||
| pbParams.setRevocationEnabled(true); | ||
| System.setProperty("com.sun.net.ssl.checkRevocation", "true"); | ||
| System.setProperty("com.sun.security.enableCRLDP", "true"); | ||
| if (ocspEnabled.isTrue()) { | ||
| Security.setProperty("ocsp.enable", "true"); | ||
| } | ||
| } else { | ||
| pbParams.setRevocationEnabled(false); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question here:
In the case when both parameters are set to 'system', we won't do anything: not altering system properties and not setting revocation in pbParams. Will that work correctly, I mean will pbParams revocation flag follow the system settings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doc:
If this flag is true, the default revocation checking mechanism of the underlying PKIX service provider will be used
When a PKIXParameters object is created, this flag is set to true. This setting reflects the most common strategy for checking revocation, since each service provider must support revocation checking to be PKIX compliant. Sophisticated applications should set this flag to false when it is not practical to use a PKIX service provider's default revocation checking mechanism or when an alternative revocation checking mechanism is to be substituted (by also calling the addCertPathChecker or setCertPathCheckers methods).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found the same docs, @anmolnar .
The code agrees that this defaults to the value of "com.sun.net.ssl.checkRevocation".
I think that's fine, the goal here is to use the JDK default settings.
This one CAN be overriden separately with the new property if we use a custom truststore.
(Also note that I have slightly changed the logic in the current #2277 PR).
|
#2277 is the current patch |
This patch implements Option B discussed in the ticket.
If the solution is accepted, then we will also need to update the docs.