Errors after enabling SSL error messages
If you are unable to access resources using a SSL URL (beginning with https:), or encounter error messages which indicate SSL problems, verify that your HTTP server is configured correctly for SSL by browsing the welcome page of the HTTP server using SSL by entering the URL: https://hostname.
If the page works with HTTP, but not HTTPS, the problem is with the HTTP server.
- Refer to the documentation for your HTTP server for instructions on correctly enabling SSL. If you are using the IBM HTTP Server or Apache, go to:http://www.ibm.com/software/webservers/httpservers/library.html . Click Frequently Asked Questions> SSL.
- If you are use the IBM Key Management (IKeyman) tool to create certificates and keys, remember to stash the password to a file when creating the KDB file with the IBM Key Management Tool.
- Go to the directory where the KDB file was created, and see if there is a .sth file.
- If not, open the KDB file with the IBM Key Management Tool, and click Key Database File > Stash Password. The following message displays: The password has been encrypted and saved in the file.
If the HTTP server handles SSL-encrypted requests successfully, or is not involved (for example, traffic flows from a Java client application directly to an enterprise bean hosted by the WAS, or the problem appears only after enabling WAS security), what kind of error are you seeing?
- javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. Reason: handshake failure
- javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. Reason: unknown certificate
- javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. Reason: bad certificate
- org.omg.CORBA.INTERNAL... EntryNotFoundException or NTRegistryImp E SECJ0070E: No privilege id configured for: error when programmatically creating a credential.
For general tips on diagnosing and resolving security-related problems, see Security components troubleshooting tips
If you do not see a problem that resembles yours, or if the information provided does not solve your problem, seeObtaining help from IBM
javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. Reason: handshake failure
If you see a Java exception stack similar to the following example
[Root exception is org.omg.CORBA.TRANSIENT: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET: JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. Reason: handshake failure:host=MYSERVER,port=1079 minor code: 4942F303 completed: No] at com.ibm.CORBA.transport.TransportConnectionBase.connect (TransportConnectionBase.java:NNN)Some possible causes are...
- Not having common ciphers between the client and server.
- Not specifying the correct protocol.
To correct these problems...
- Review the SSL settings. Click WebSphere Administrative Console Security Settings > SSL Configuration Repertoires > DefaultSSLSettings (or other named SSL settings).
- Select the SSL option from the Additional Properties menu. You can also browse the file manually by viewing the $WAS_HOME/properties/sas.client.props file.
- Check the property specified by the com.ibm.ssl.protocol file to determine which protocol is specified.
- Check the cipher types specified by the com.ibm.ssl.enabledCipherSuites. You might want to add more cipher types to the list. To see which cipher suites are currently enabled: Fo to the properties page of the SSL settings as described above, and look for the Cipher Suites property. To see the list of all possible cipher suites, go to the properties page of the SSL settings as described above, then view the online help for that page. From the help page, click Configure additional SSL settings.
- Correct the protocol or cipher problem by using a different client or server protocol and cipher selection. Typical protocols are SSL or SSLv3.
- Make the cipher selection 40-bit instead of 128-bit. For CSIv2, set both of the following properties to false in the sas.client.props file, or set security level=medium in the administrative console settings...
- com.ibm.CSI.performMessageConfidentialityRequired=false
- com.ibm.CSI.performMessageConfidentialitySupported=false
javax.net.ssl.SSLHandshakeException: unknown certificate
If you see a Java exception stack similar to the following example, it might be caused by not having the personal certificate for the server in the client truststore file
ERROR: Could not get the initial context or unable to look up the starting context. Exiting. Exception received: javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context using the provider url: "corbaloc:iiop:localhost:2809". Verify that the host and port information is correct and that the server identified by the provider url is a running name server. If no port number is specified, the default port number 2809 is used. Other possible causes include the network environment or workstation network configuration. [Root exception is org.omg.CORBA.TRANSIENT: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET: JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. Reason: unknown certificate:host=MYSERVER,port=1940 minor code: 4942F303 completed: No]To correct this problem...
- Check the client truststore file to determine if the signer certificate from the server personal certificate is there. For a self-signed server personal certificate, the signer certificate is the public key of the personal certificate. For a certificate authority signed server personal certificate, the signer certificate is the root CA certificate of the CA that signed the personal certificate.
- Add the server signer certificate to the client truststore file.
javax.net.ssl.SSLHandshakeException: bad certificate
If you see a Java exception stack similar to the following example, it can be caused by having a personal certificate in the client keystore used for SSL mutual authentication but not having extracted the signer certificate into the server truststore file so that the server can trust it whenever the SSL handshake is made
ERROR: Could not get the initial context or unable to look up the starting context. Exiting. Exception received: javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context using the provider url: "corbaloc:iiop:localhost:2809". Verify that the host and port information is correct and that the server identified by the provider url is a running name server. If no port number is specified, the default port number 2809 is used.Other possible causes include the network environment or workstation network configuration. [Root exception is org.omg.CORBA.TRANSIENT: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET: JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. Reason: bad certificate: host=MYSERVER,port=1940 minor code: 4942F303 completed: No]To verify this problem, check the server truststore file to determine if the signer certificate from the client personal certificate is there. For a self-signed client personal certificate, the signer certificate is the public key of the personal certificate. For a certificate authority signed client personal certificate, the signer certificate is the root CA certificate of the CA that signed the personal certificate.
To correct this problem, add the client signer certificate to the server truststore file.
org.omg.CORBA.INTERNAL... EntryNotFoundException or NTRegistryImp E SECJ0070E: No privilege id configured for: error when programmatically creating a credential
If you encounter the following exception in a client application attempting to request a credential from a WAS using SSL mutual authentication
ERROR: Could not get the initial context or unable to look up the starting context. Exiting. Exception received: org.omg.CORBA.INTERNAL: Trace from server: 1198777258 at host MYHOST on port 0 >>org.omg.CORBA.INTERNAL: EntryNotFoundException minor code: 494210B0 completed: No at com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthFailReason. map_auth_fail_to_minor_code(PrincipalAuthFailReason.java:99)or a simultaneous error from the WAS that resembles
[7/31/02 15:38:48:452 CDT] 27318f5 NTRegistryImp E SECJ0070E: No privilege id configured for: testuserThe cause might be that the user ID sent by the client to the server is not in the user registry for that server.
To confirm this problem, check that an entry exists for the personal certificate that is sent to the server. Depending on the user registry mechanism, look at the native operating system user ID or LDAP server entries.
To correct this problem, add the user ID to the user registry entry (for example, operating system, LDAP directory, or other custom registry) for the personal certificate identity.
See Also
Troubleshooting by component: What is not working?