+

Search Tips   |   Advanced Search

SSL errors for security


Stopping the deployment manager after configuring Secure Sockets Layer

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

The error occurs because the deployment manager did not propagate the new SSL certificate to the node agents, which 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 dmgr processes.

(Windows) To end the processes, use the Task Manager.

(UNIX) Run the command to end the process

To identify the specific process to stop, get the process ID from the specific WAS pid file. For example...


Access resources using HTTPS

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

If the page works with HTTP, but not HTTPS, the problem is with the HTTP server.

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 that is hosted by WAS, or the problem displays only after enabling WAS security), what kind of error are you seeing?

For general tips on diagnosing and resolving security-related problems, see Security components troubleshooting tips

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 we see a Java exception stack similar to the following example:

Some possible causes are:

To correct these problems:

  1. Check the property specified by the com.ibm.ssl.protocol file to determine which protocol is specified.

  2. Check the cipher types specified by the com.ibm.ssl.enabledCipherSuites interface. We 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.

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

    • com.ibm.CSI.performMessageConfidentialityRequired=false
    • com.ibm.CSI.performMessageConfidentialitySupported=false


javax.net.ssl.SSLHandshakeException: unknown certificate

If we 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:

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

A Java exception stack error might display if the following situations occur:

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

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 we encounter the following exception in a client application attempting to request a credential from a WAS using SSL mutual authentication:

...or a simultaneous error from the WAS that resembles:

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 an entry exists for the personal certificate 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 we 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 "com.ibm.ssl.enableSignerExchangePrompt" signer property 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.

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 administrative 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 v6.1 and later releases. New capabilities were added that are not supported when the configurations are not migrated to the latest format. If we are migrating from a release prior to v6.1, we can use the convertSSLConfig task to convert our SSL configuration information to the centralized SSL configuration format.


Stand-Alone configuration fails when digital certificates are defined with the NOTRUST option

If our digital certificates are defined with the NOTRUST option, it is possible that we might receive the following error message:

If this error appears, enter 'D OMVS,P. If we have a NOTRUST issue a large number appears under 'OPNSOCK'.

Check your digital certificates and make sure they are not marked with the NOTRUST option. This can occur if the certificates were created with a date beyond the expiration date of the CERTAUTH used to create it.


Problem when configuring an LDAP repository with SSL

When configuring an LDAP repository with SSL, configure the LDAP repository on the node before the node is registered with the administrative agent.

If we attempt to configure the LDAP repository after registering the node with the agent, federated repositories looks for the SSL certificates in the trust store of the administrative agent instead of in the trust store of the node.


Problem when creating a chained certificate for SHA384withECDSA

If we have certificates converted to SHA384withECDSA, and are trying to create a chained certificate from the administrative console by clicking...

...and then create a new chained certificate, the supported key size should be 384. If it is not, the certificate cannot be created.

To resolve, enable Javascript to show the correct key size on the panel


Related:

  • Troubleshoot and support
  • Retrieving signers using the retrieveSigners utility at the client
  • Application deployment troubleshooting tips