WAS v8.5 > Reference > Troubleshooting tips
Errors configuring SSL encrypted access for security
You might have errors returned when we are trying to configure SSL for encrypted access. This article describes some of the common errors you might encounter and makes suggestions on how to fix the problems.
What kind of error are you seeing?
- The Java Cryptographic Extension (JCE) files were not found. error when launching iKeyman
- Unable to verify MAC. error when the wrong keystore password is used
- "SSL handshake failure" error when no trusted certificate is found
- The certificate alias cannot be found in the keystore
If we do not see a problem that resembles yours, or if the information provided does not solve your problem, see Troubleshooting help from IBM for further assistance.
"The Java Cryptographic Extension (JCE) files were not found." error when launching iKeyman
You might receive the following error when we attempt to start the iKeyman tool:
"The Java Cryptographic Extension (JCE) files were not found. Please check the JCE files have been installed in the correct directory."When you click OK, the iKeyman tool closes. To resolve this problem:
- Set the JAVA_HOME parameter so that is points to the Java Developer Kit that is shipped with WebSphere Application Server.
For example, the command is similar to: export JAVA_HOME=/opt/WebSphere/AppServer/java
If WAS is installed on your c: drive, the command would be: set JAVA_HOME=c:\WebSphere\AppServer\java
- Rename the file install_dir/java/jre/lib/ext/gskikm.jar to gskikm.jar.org.
The file is located in the install_dir/java/jre/lib/ext/ directory.
By default, the file is located in the following directory: app_server_rootedition_name/java/ext.
"Unable to verify MAC." error when the wrong keystore password is used
You might receive the following error when the keystore password is not being used correctly.
CWPKI0033E: The keystore located at "C:/WebSphere/AppServer/profiles/AppSrv01/etc/trust.p12" failed to load due to the following error: Unable to verify MAC.
Change the Password field that references this keystore using the correct password. The default password is WebAS. Never use this password in a production environment.
"SSL handshake failure" error when no trusted certificate is found
You might receive the following error when we attempt to add the signer to the local truststore:
CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN "CN=BIRKT40.austin.ibm.com, O=IBM, C=US" was sent from target host:port "9.65.49.131:9428".
The signer might need to be added to the local truststore C:/WASX_c0602.31/AppServer/profiles/Dmgr09/etc/trust.p12 located in the SSL configuration alias DefaultSSLSettings. The truststore is loaded from the SSL configuration file.
The extended error message from the SSL handshake exception is:
- "No trusted certificate found."
This error indicates the signer certificate from the specified target host and port has not been located in the specified truststore, the SSL settings, and the SSL configuration file. If this occurs in a client process, there are several things that we can do:
- Enable the signer exchange prompt.
- Run the retrieveSigners script. For more information, see retrieveSigners command.
- Manually export the signers from the server and import them to the client.
If this issue occurs in a server process, then complete one of the following procedures:
- In the dmgr console, find the target endpoint (host name and port) and determine the certificate used by the SSL configuration associated with it. Extract the SSL certificate to a file, and import it into the sending server truststore referenced in the error message.
- In the dmgr console, find the sending server truststore. Go to signer certificates, add from Port, and connect directly to the target host and port, which are indicated in the message, to retrieve the signer directly into the truststore.
- Manually extract the signer from the target server and host keystore using the iKeyman utility, and import the signer into the truststore of the server sending the certificate.
As default, Websphere Application Server uses the key.p12 and trust.p12 files for any communication between Websphere appservers (for example between nodeagent and appserver or vice versa). If WAS is looking for a certificate in some file other than these, then it is possible the application establishes the secure socket layer (SSL) configuration using system properties, established with the System.setProperty() method. That is, SSL configurations are managed for each of your processes, and we have had to maintain individual settings for each SSL configuration in the topology.
Prior to WAS v6.1, the WAS management processes allowed the individually-managed SSL configurations which were set by system properties. Your pre-v6.1 system properties settings were processed successfully.
With WAS v6.1, central management of SSL configuration occurs. Applications that use SSL connections based on values set for system properties instead of using the centrally managed default dynamic SSL configuration can experience handshake failures. Nodeagent to appserver communications is being governed by the default dynamic SSL configuration in WAS v6.1 and not through the system properties you set. You may need to adjust the application to use the centrally managed SSL configuration of WAS v6.1.
The certificate alias cannot be found in the keystore
You might receive the following error when the certificate alias is not found in the referenced keystore:
CWPKI0023E: The certificate alias "default" specified by the property com.ibm.ssl.keyStoreClientAlias is not found in KeyStore "c:/WebSphere/AppServer/profiles/Dmgr01/config/cells/myCell/key.p12".
This error indicates the certificate alias that was specified cannot be found in the referenced keystore. Either change the certificate alias or verify alias exists in the specified keystore.
Related concepts:
Troubleshooting help from IBM