Skip to content
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

Add Support for Custom SSL Truststore Configuration via JT400 Property #199

Open
trknz opened this issue Aug 26, 2024 · 4 comments
Open

Comments

@trknz
Copy link

trknz commented Aug 26, 2024

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.

@pjyoung-ibm
Copy link
Member

pjyoung-ibm commented Aug 27, 2024

#128

@trknz
Copy link
Author

trknz commented Aug 27, 2024

#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.

@pjyoung-ibm
Copy link
Member

Ah, my apologies, I misread your message.

@trknz
Copy link
Author

trknz commented Aug 27, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants