Secure Sockets Layer errors

 

+

Search Tips   |   Advanced Search

 

1. Stop the deployment manager after configuring Secure Sockets Layer
2. Access resources using HTTPS
3. javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. Reason: handshake failure
4. javax.net.ssl.SSLHandshakeException: unknown certificate
5. javax.net.ssl.SSLHandshakeException: bad certificate
6. org.omg.CORBA.INTERNAL: EntryNotFoundException or NTRegistryImp E CWSCJ0070E: No privilege id configured for: error when programmatically creating a credential
7. "Catalog" tablet is blank (no item displayed) in GUI application client
8. Modifying SSL Configurations after migration using -scriptCompatibility true >

 

Stop the deployment manager after configuring Secure Sockets Layer

After configuring the Secure Sockets Layer repertoires, if you stop the deployment manager without also stopping the node agents, you might receive the following error message when you restart the deployment manager:

CWWMU0509I: The server "nodeagent" cannot be reached. It appears to be stopped.
CWWMU0211I: Error details may be seen in the file:
           /opt/WebSphere/AppServer/logs/nodeagent/stopServer.log

The error occurs because the deployment manager did not propagate the new SSL certificate to the node agents. The node agents are using an older certificate file than the deployment manager and the certificate files are incompatible. To work around this problem, manually stop the node agent and deployment manager processes.

To end the processes, use the Task Manager.

Run the command to end the process

We need to consider certain items when identifying the specific process to stop. For each process that is stopped, WAS stores the process ID in a pid file and find these *.pid files. For example, the server1.pid for a stand-alone install action might be found at:

install_root/logs/server1.pid

 

Access resources using HTTPS

If you are unable to access resources using an SSL URL (beginning with https:), or encounter error messages that indicate SSL problems, verify that your HTTP server is configured correctly for SSL. Browse the welcome page of the HTTP server using SSL...

https://host_name

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

  and click...

  Frequently Asked Questions | SSL

• If you use the iKeyman tool to create certificates and keys, remember to stash the password to a file when creating the Key Database (KDB) file.

  1. Go to the directory where the KDB file is created, and see if an .sth file exists.

  2. If not, open the KDB file with the IBM Key Management Tool, and click...

     Key Database File | Stash Password

     The following message is displayed:

     The password has been encrypted and saved in the file

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, see Troubleshooting 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: CWWJE0080E:   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:

1. Review the SSL settings. In the console, click...

   Security | SSL certificate and key management | Configuration settings | Manage endpoint security configurations | endpoint_configuration_name | Related items | SSL configurations | SSL_configuration_name

   You can also browse the file manually by viewing...

   install_root/properties/sas.client.props

2. Check the property that is specified by the file...

   com.ibm.ssl.protocol

   ...to determine which protocol is specified.

3. Check the cipher types that are specified by the interface...

   com.ibm.ssl.enabledCipherSuites

   You might want to add more cipher types to the list. To see which cipher suites are currently enabled, click Quality of protection settings (QoP), and look for the Cipher Suites property.

4. Correct the protocol or cipher problem by using a different client or server protocol and cipher selection. Typical protocols are SSL or SSLv3.

5. 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 console settings:
   • com.ibm.CSI.performMessageConfidentialityRequired=false
   • com.ibm.CSI.performMessageConfidentialitySupported=false

 

javax.net.ssl.SSLHandshakeException: unknown certificate

If global security is enabled, outbound SSL communication can fail for applications that set the following global properties:

• javax.net.ssl.keystore
• javax.net.ssl.truststore

This is because WAS uses Apache SOAP internally to perform system management operations. When global security is enabled, Apache SOAP uses SSL to communicate between nodes. The "javax.net.ssl.keystore" and "javax.net.ssl.truststore" system properties are being set for each SOAP communication. Applications using these properties will have their values changed. The key files defined in the SSL repertoire used by the SOAP service will be used for outbound JSSE communication instead of the key files specified in the application. If the application relies on the "cacerts" file, this same problem will also occur.

The recommended solution is to use Socket Factories, which define their own keystore/truststore, without using the System properties.

Other scenarios may also cause the same error. 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 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: CWWJE0080E:  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:

1. 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 (CA)-signed server personal certificate, the signer certificate is the root CA certificate of the CA that signed the personal certificate.

2. Add the server signer certificate to the client truststore file.

 

javax.net.ssl.SSLHandshakeException: bad certificate

If global security is enabled, outbound SSL communication can fail for applications that set the following global properties:

• javax.net.ssl.keystore
• javax.net.ssl.truststore

This is because WAS uses Apache SOAP internally to perform system management operations. When global security is enabled, Apache SOAP uses SSL to communicate between nodes. The "javax.net.ssl.keystore" and "javax.net.ssl.truststore" System properties are being set for each SOAP communication. Applications using these properties will have their values changed. The key files defined in the SSL repertoire used by the SOAP service will be used for outbound JSSE communication instead of the key files specified in the application. If the application relies on the "cacerts" file, this same problem will also occur.

The recommended solution is to use Socket Factories, which define their own keystore/truststore, without using the System properties.

Other scenarios may also cause the same error. A Java exception stack error might display if the following situations occur:

• A personal certificate exists in the client keystore that is used for SSL mutual authentication.

• The signer certificate is not extracted into the server truststore file, and thus the server cannot trust the certificate whenever the SSL handshake is made.

The following message is an example of the Java exception stack error:

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 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: CWWJE0080E: 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 CWSCJ0070E: 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 CWSCJ0070E: No privilege id  configured for: testuser

...the 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.

 

"Catalog" tablet is blank (no item displayed) in GUI application client

This error message occurs when you install an ActiveX client sample application that uses the PlantsByWebSphere Active X to EJB Bridge.

The cause is that the server certificate is not in the client trustore that is specified in the client.ssl.props file. Although the signer property...

com.ibm.ssl.enableSignerExchangePrompt

...might be set to true, the auto-exchange prompt only supports a command-line prompt. If the sample application relies on a graphical user interface and does not provide access to a command prompt, for example using standard in and standard out, the auto-exchange prompt does not function.

Note that the applet client under the Client Technology Samples does not have access to the command prompt and it cannot see the auto-exchange prompt. Thus, the applet client cannot rely on the auto-exchange prompt feature.

To correct this problem, retrieve the certificate manually using the retrieveSigners utility.

 

Modifying SSL Configurations after migration using -scriptCompatibility true

After migrating using scriptCompatibility true, all attributes of the SSL configurations cannot be edited through the console. In particular, the hardware cryptography settings cannot be displayed or edited.

By using the scriptCompatibility true flag, the SSL configurations are not migrated to the new format for support in the 6.1 release. New capabilities were added that are not supported when the configurations are not migrated to the latest format.

To solve this problem, create new SSL configuration definitions to replace those in the pre 6.1 format or continue to edit those configurations using scripting.

---

 

Related concepts

Troubleshooting

 

Related tasks

Retrieve signers using the retrieveSigners utility at the client
Troubleshoot security configurations

 

Related Reference

Application deployment troubleshooting tips