#419 Ability to specify a local custom SSL truststore for JTOpen?

[Vlad]

Please add an ability to specify a location/password for a custome (non JRE default) SSL truststore via a the JT400 property.
Using global javax.net.ssl.trustStore system property is not always possible as it may conflict with other applications running on the same JVM.

[John Eberhard]

We are unable to due this at this time since JTOpen relies on the trust stored provided by the JVM. The JVM does not provide an easy way to use different trust store for different SSL connections.

JTOpen is open source, so if you can find someone to implement and contribute this enhancement, it can be added to JTOpen. If you want IBM to do the work, you will need to submit an official Request for Enhancement, which will be prioritize with respect with all other requests.

[Marcel Romijn]

Hello JTOpen team,

I'm replying to this (closed) issue because we are facing a similar situation.
Our (development) IBM i machines have certificates that are signed by a CA that is internal to the company and our customers may have the same situation.
This means that a secure connection with JTOpen will not work by default.
The alternative would be to provide the command-line System Properties to point to a trust store. However, due to technical reasons, we would like to avoid that.

We had a look at the JTOpen code base and adding a provision to supply a custom 'SSLSocketFactory' does not look that hard.
It would require some changes in classes: 'PortMapper', 'SecureAS400', 'SocketContainerJSSE' and 'SSLOptions'.
As soon as it is possible to provide a custom 'SSLSocketFactory', the SSL context is available to provide the functionality we like.
That is maybe also true for the person who created this issue in the first place.

If we would provide patches for these 4 classes, would the JTOpen team be willing to apply them into the JTOpen code base, provided they meet the team's standards?

Regards,
Marcel Romijn