Open trknz opened 2 months ago
#128
128
This isn't exactly the same situation. I'm referring to the SF case #419.
While I agree with MarcelRomijn's proposal, this case focuses on configuring Java properties at the JVM level, similar to how the javax.net.ssl.trustStore
works.
The use case involves third-party applications where users can't access the Java code. In such cases, the only way to change the default truststore location is through Java system properties.
Therefore, I suggest adding support of the new system properties com.ibm.as400.ssl.trustStore
and com.ibm.as400.ssl.trustStorePassword
, which jt400 should use when these properties are set.
Ah, my apologies, I misread your message.
Ah, my apologies, I misread your message.
It was probably my fault for not being clear enough. I've updated the case description with the additional details.
Please add the ability to specify a location and password for a custom (non-JRE default) SSL truststore via a JT400 property. Using the global javax.net.ssl.trustStore system property can cause conflicts with other applications running on the same JVM, so this feature is necessary to avoid such issues.
The use case involves third-party applications where users can't access the Java code. In such cases, the only way to change the default truststore location is through Java system properties.
Therefore, I suggest adding support of the new system properties com.ibm.as400.ssl.trustStore and com.ibm.as400.ssl.trustStorePassword, which jt400 should use when these properties are set.