The previous two articles explain the two ways to establish SSL connections in a WebSphere environment, one step further:
What is the difference between the two? essentially the same is the case with the JVM to establish the socket connection, the difference is to configure the JVM socket connection mode.
two ways to configure the priority level? system variables are prioritized in a way that overrides the WebSphere configuration. See the following article for details. http://www.ibm.com/developerworks/websphere/techjournal/0502_benantar/0502_benantar.html
How to choose? you should typically choose to have WebSphere Manage your SSL socket connection, as this is one of the container's work, but if you adopt a third-party jar package that has a call to the sslcontext.getinstance () statement, Then there is no choice but to handle your keystore and truststore carefully, because in this way it does not read the WebSphere SSL configuration, you can only specify KeyStore and Truststore by system variables, but the system variable is global, Will overwrite the WebSphere configuration, so you have to handle two keystore carefully. Of Course if you want to specify KeyStore but do not want to overwrite the relevant configuration of WebSphere, it is also possible to continue calling the JDK API after Sslcontext.getinstance () to set the current instance key Store and Truststore, such settings are local only to the current instance visible, but often the third-party jar package does not expose the instance. Another option is to import all your certificate into the KeyStore and Truststore of the WebSphere configuration, Then let Javax.net.ssl.keystore point to the SAL configuration's KeyStore file, so you don't have to worry about a problem being overwritten by another, because the only problem with the same file is whether you can get the WebSphere KeyStore and truststore passwords.
A practical problem analysis and resolution of the five: the difference and choice between the two methods
