[GR-32212] Add support for runtime configuration of default trusted KeyStore. #3652
Conversation
| */ | ||
| RuntimeClassInitialization.initializeAtBuildTime(sun.security.util.UntrustedCertificates.class); | ||
| RuntimeClassInitialization.initializeAtBuildTime(org.jcp.xml.dsig.internal.dom.XMLDSigRI.class); |
There was a problem hiding this comment.
This class queries "java.specification.version", but it's not strictly necessary to have it explicitly initialized at buildtime. Your call on whether to keep it here or not
|
Looks good to me, however you should be careful to not confuse users by saying certificate file when you mean trustStore used to validate third party certificates. |
| when a new certificate file is specified at runtime via setting the | ||
| "javax.net.ssl.trustStore\*" system properties, the new certificates will still | ||
| be checked against the <java.home>/lib/security/blacklisted.certs loaded at | ||
| image buildtime. |
There was a problem hiding this comment.
Hello @teshull, I was wondering if this blacklisted certificates that are used to decide trust, should be additive. What I mean is, should users be able to specify additional certificates dynamically during runtime usage of the generated native application? If they are not allowed to do so, then a native application/image generated with a specific build time JDK will have to be regularly rebuilt, whenever any new blacklisted certs are added into the JDK itself, which may not always be feasible. I can understand why it would be a bad thing to completely override this blacklisted certificates file at runtime but "adding" new certificates perhaps should be possible? Of course, I haven't looked at the technical implementation aspects of this to know if this is feasible.
There was a problem hiding this comment.
Hi @jaikiran, I think it is best to leave this as is and not allow the user to add additional blacklisted certificates. In OpenJDK, it is not possible for the user to specify the blacklist, so adding support for this to me seems like an unneeded deviation from OpenJDK.
Too, now that they can modify the truststore at runtime, that should be sufficient for updating certificate info without a rebuild
|
I agree with @matthyx, the documentation in this PR refers "certificates" and "keystores", when actually we are dealing with the "truststore". I think consistently using "truststore" in this documentation will avoid any confusion. |
graalvmbot
force-pushed
the
github/tshull/GR-32212_truststoremanager
branch
from
b32df02 to
32fcac3
Compare
|
Thanks for your work @teshull ! I'm really looking forward to testing this :) |
Adds support for allowing the user to specify a new default certificate file during runtime.