Troubleshooting
Problem
When you experience SSL/TLS Java™ communication issues, it is helpful to identify the keystore and truststore file paths and gather Java™ security trace data to help you determine the cause of the issue.
Environment
IBM i OS
Resolving The Problem
To determine what SSL/TLS keystore and truststore a Java™ application is using, you can set the JVM property javax.net.debug=true and re-create the error. There are several ways to set the property. The easiest method is to set it as a command-line argument during the Java™ program invocation from a command line within Qshell or PASE.
For example:
java -Djavax.net.debug=true <YourProgramName>
Where: <YourProgramName> is the name of the Java program.
Note: If the Java™ invocation cannot be easily altered, you can set the property in the '/QIBM/UserData/Java400/SystemDefault.properties' file. If you view or edit the file by using the EDTF command, it will look like this:
************Beginning of data**************
javax.net.debug=true
************End of Data********************
NOTE: The SystemDefault.properties file must have a CCSID of 819 or 1252 to allow Java to read it successfully. To create the SystemDefault.properties file do the following;
For example:
java -Djavax.net.debug=true <YourProgramName>
Where: <YourProgramName> is the name of the Java program.
Note: If the Java™ invocation cannot be easily altered, you can set the property in the '/QIBM/UserData/Java400/SystemDefault.properties' file. If you view or edit the file by using the EDTF command, it will look like this:
************Beginning of data**************
javax.net.debug=true
************End of Data********************
NOTE: The SystemDefault.properties file must have a CCSID of 819 or 1252 to allow Java to read it successfully. To create the SystemDefault.properties file do the following;
STRQSH
touch -C 819 /QIBM/UserData/Java400/SystemDefault.properties
The following is an example of what you will see in the trace:
...
Setting up default SSLSocketFactory
Use default IbmJSSE2 impl class: com.ibm.jsse2.SSLSocketFactoryImpl
class com.ibm.jsse2.SSLSocketFactoryImpl is loaded
init keymanager of type IbmX509
IBMJSSEProvider2 Build-Level: -20191119
keyStore is: /QOpenSys/QIBM/ProdData/JavaVM/jdk80/32bit/jre/lib/security/cacerts
keyStore type is: jks
keyStore provider is:
init keystore
trustStore is: /QOpenSys/QIBM/ProdData/JavaVM/jdk80/32bit/jre/lib/security/cacerts
trustStore type is: jks
trustStore provider is:
init truststore
The previous stack trace shows the default cacerts Java Keystore or JKS-type KeyStore and TrustStore are being used currently. Whereas, the following trace data shows the *SYSTEM or Digital Certificate Manager default store is being used currently.
Example
touch -C 819 /QIBM/UserData/Java400/SystemDefault.properties
The following is an example of what you will see in the trace:
...
Setting up default SSLSocketFactory
Use default IbmJSSE2 impl class: com.ibm.jsse2.SSLSocketFactoryImpl
class com.ibm.jsse2.SSLSocketFactoryImpl is loaded
init keymanager of type IbmX509
IBMJSSEProvider2 Build-Level: -20191119
keyStore is: /QOpenSys/QIBM/ProdData/JavaVM/jdk80/32bit/jre/lib/security/cacerts
keyStore type is: jks
keyStore provider is:
init keystore
trustStore is: /QOpenSys/QIBM/ProdData/JavaVM/jdk80/32bit/jre/lib/security/cacerts
trustStore type is: jks
trustStore provider is:
init truststore
The previous stack trace shows the default cacerts Java Keystore or JKS-type KeyStore and TrustStore are being used currently. Whereas, the following trace data shows the *SYSTEM or Digital Certificate Manager default store is being used currently.
Example
| socketfactory: SSLSocketFactory.createSocket() socketfactory: host = 10.1.1.1 socketfactory: port = 9030 sslsocket: SSL Socket created. sslsocket: host = 10.1.1.1 sslsocket: port = 9030 sslctx: SSLContextImpl.isInitialized() sslctx: SSLContextImpl.initialize() sslctx: Keyring name = *SYSTEM sslctx: SSLContextImpl.getDefaultCipherSuites() sslctx: SSLContextImpl.getSupportedProtocols() sslsocket: SSLSocket.setEnabledProtocols() sslsocket: protocols = Locating the trace output: The trace output will go to the stdout, stderr file descriptor stream files set-up for the Java™ program. For a simple program that is called from Qshell, the output would be sent to the screen. The client can press F6 at any time within a Qshell Interpreter session to print the scroll to a spool file. If you cannot locate the output, the best option is to contact the owner of the Java™ program. Another option is to set the: "os400.stderr" and "os400.stdout" system properties to direct the output to a specific file. You should refer to the following documentation for more information: https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzaha/sysprop2.htm |
[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"7.1.0"}]
Historical Number
545573472
Was this topic helpful?
Document Information
Modified date:
22 April 2020
UID
nas8N1012589