SSL errors for security

You might encounter various problems after configuring or enabling Secure Sockets Layer (SSL). You may not be able to stop the deployment manager after configuring the SSL. You may not be able to access resource using HTTPS. The client and the server may not be able to negotiate the proper level of security. The problems mentioned here are only a few of the possibilities. Solving these problems is imperative to the successful operation of WebSphere® Application Server.

What type of problem are you having?

[AIX Solaris HP-UX Linux Windows]

Accessing resources using HTTPS

If you are unable to access resources using a Secure Sockets Layer (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 by entering the URL: 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. Click Frequently Asked Questions> SSL.
  • If you use the IBM Key Management (IKeyman) tool to create certificates and keys, remember to stash the password to a file when creating the Key Database (KDB) file with the IBM Key Management Tool.
    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.

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 WebSphere Application Server, or the problem displays only after enabling WebSphere Application Server security), what kind of error are you seeing?

[AIX Solaris HP-UX Linux Windows][IBM i]You get this error message org.omg.CORBA.INTERNAL: EntryNotFoundException or NTRegistryImp E CWSCJ0070E: No privilege id configured for: 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, 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. [AIX Solaris HP-UX Linux Windows]Review the SSL settings. In the administrative console, click Security > SSL certificate and key management. Under Configuration settings, click Manage endpoint security configurations > endpoint_configuration_name. Under Related items, click SSL configurations > SSL_configuration_name. You can also browse the file manually by viewing the install_root/properties/sas.client.props file.
  2. [IBM i]Review the SSL settings. In the administrative console, click Security > SSL certificate and key management. Under Configuration settings, click Manage endpoint security configurations > endpoint_configuration_name. Under Related items, click SSL configurations > SSL_configuration_name. You can also browse the file manually by viewing the app_server_root/properties/sas.client.props file.
  3. Check the property that is specified by the com.ibm.ssl.protocol file to determine which protocol is specified.
  4. Check the cipher types that are specified by the com.ibm.ssl.enabledCipherSuites interface. 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.
  5. Correct the protocol or cipher problem by using a different client or server protocol and cipher selection. Typical protocols are SSL or SSLv3.
  6. [AIX Solaris HP-UX Linux Windows][IBM i]Make the cipher selection 40-bit instead of 128-bit. For Common Secure Interoperability Version 2 (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". Make sure 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: 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

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". 
Make sure 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: 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.

[AIX Solaris HP-UX Linux Windows][IBM i]

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 WebSphere Application Server 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 WebSphere Application Server 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 Lightweight Directory Access Protocol (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 "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.

Note: 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 Version 6.1 and later releases. New capabilities were added that are not supported when the configurations are not migrated to the latest format. If you are migrating from a release prior to Version 6.1, you can use the convertSSLConfig task to convert your SSL configuration information to the centralized SSL configuration format.

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

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

Trace: 2008/06/18 16:57:57.798 01 t=8C50B8 c=UNK key=S2 (0000000A) 
Description: Log Boss/390 Error 
from filename: ./bbgcfcom.cpp 
at line: 376 
error message: BBOO0042E Function AsynchIOaccept failed with RV=-1, RC=124, RSN=050B0146, ?EDC5124I 
Too many open files. (errno2=0x0594003D)?? 

If this error appears, enter 'D OMVS,P. If you 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 that was used to create it.

Problem when configuring an LDAP repository with SSL

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

If you 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 you have certificates converted to SHA384withECDSA, and are trying to create a chained certificate from the administrative console by clicking SSL Certificate and Key management->Key stores and certificates ->key store >Personal certificate, 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

Handling expired chained certificates

when you have to replace part of a certificate chain, including CA (certificate authority) certificates and an individual part of a certificate chain has expired, you are required to update the entire chain. Specifically, for chained self-signed certificates, you have to create a brand new certificate chain in the keystore or renew the self-signed certificate. See Renewing a certificate in SSL for details. For a CA certificate chain, you are usually required to request a brand new certificate chain from your CA by presenting them with a new certificate request file (CSR) so that a new CA certificate chain can be generated.