Troubleshooting
Problem
After creating a server or while starting the server, the workbench may not reflect the correct state of the server. The following are examples of the problem scenarios:
- The server is started, but in the Servers View the status of the server displays as Stopped.
- When attempting to start a server, the console view displays the server as successfully started by displaying the message, "Server
open for e-business". However, the status of the server in the Server View remains in a 'starting' state.
Cause
The workbench has problems establishing a connection to the server.
Resolving The Problem
There are many reasons the workbench might not be able to connect to a started server. The following is a list of troubleshooting tips:
Untrusted certificate due to hostname verification
In Java 11 and higher, hostname verification is ON by default. If a user attempts to connect to the server, the request fails due to a mismatch between the hostname on the soap connection and the existing certificate.
If the user starts the server from the Eclipse Servers View, they see the following error message because the connection to obtain the status fails:
If the user clicks 
, they see the following error message because the connection to obtain the status fails:
, they see the following error message because the connection to obtain the status fails:
The user has two options to resolve this problem:
OPTION 1. Regenerate the truststore certificate (preferred)
Perform the following 6 steps to regenerate the truststore certificate:
1. Generate and replace the truststore certificate
Use the wsadmin tool to issue the genAndReplaceCertificates command shown in the following code snippet:
$AdminTask genAndReplaceCertificates {-keyStoreName NodeDefaultKeyStore -certificateAlias default -sanDNSName <hostname-1>,<hostname-2>...<hostname-n> -sanIPAddress <ipaddress-1>,<ipaddress-2>...<ipaddress-n> }
Replacing <hostname-1>,<hostname-2>...<hostname-n> with the hostnames for the certificate
and <ipaddress-1>,<ipaddress-2>...<ipaddress-n> with the IP addresses for the certificate
For more information about the genAndReplaceCertificates command, see the following article:
2. Export the certificate from the server
Issue the following command from the server directory where trust.p12 is located:
keytool -exportcert -keystore trust.p12 -storepass <server keystore password> -storetype PKCS12 -alias root -file </c/WDT/trustH.cer>
Replacing <server keystore password> with the truststore password
and </c/WDT/trustH.cer> with the name of the file to contain the exported certificate
3. Import the certificate to the Eclipse JVM
Ensure that the certificate is imported into the correct JVM. This can be determined by opening the eclipse.ini file and checking the -vm entry, which Eclipse uses to identify which JVM to use.
Issue the following command from the JVM directory where cacerts is located:
keytool -import -keystore cacerts -storepass <JVM password> -alias root -file </c/WDT/trustH.cer>
Replacing <JVM password> with the JVM password
and </c/WDT/trustH.cer> with the name of the file containing the exported certificate
4. Restart Eclipse
5. Ensure the hostname in the server definition exactly matches one of the hostnames specified in the genAndReplaceCertificates command in Step 1
6. Retry starting the server
OPTION 2. Override to use the hostname to connect to the server
Perform the following 7 steps to override to use the hostname to connect to the server:
1. View the existing certificate
Issue the following command from the server directory where trust.p12 is located:
keytool -list -keystore trust.p12 -storepass <server truststore password> -storetype PKCS12 -v
Replacing <server truststore password> with the truststore password
From the output, note the hostname value:
2. Export the certificate from the server
Issue the following command from the server directory where trust.p12 is located:
keytool -exportcert -keystore trust.p12 -storepass <server truststore password> -storetype PKCS12 -alias root -file </c/WDT/trustH.cer>
Replacing <server truststore password> with the truststore password
and </c/WDT/trustH.cer> with the name of the file to contain the exported certificate
3. Import the certificate to the Eclipse JVM
Issue the following command from the JVM directory where cacerts is located:
keytool -import -keystore cacerts -storepass <JVM password> -alias root -file </c/WDT/trustH.cer>
Replacing <JVM password> with the JVM password
and </c/WDT/trustH.cer> with the name of the file containing the exported certificate
4. Add the following entry to eclipse.ini:
-Dcom.ibm.websphere.management.soapTestedConnectionUseHostname=true
5. Restart Eclipse
6. Ensure the hostname in the server definition exactly matches the hostname output by the keytool - list command in Step 1
7. Retry starting the server
The workbench uses either Remote Method Invocation (RMI) or SOAP to establish a connection to the server. Each server profile has port values defined for each of these protocols. The values of the ports in the workbench must match those of the server.
To view the value of the port specified on the server, start the Administrative Console. In the Administrative Console, select Servers > Application Servers >serverName >Ports. Record the port values of the BOOTSTRAP_ADDRESS (RMI) and SOAP_CONNECTOR_ADDRESS (SOAP) to verify if they match those in the workbench.
For more information about how to access the Administrative Console, see the following article:
http://www-01.ibm.com/support/knowledgecenter/SSZLC2_7.0.0/com.ibm.commerce.install.doc/tasks/tig_start_was_admin_console.htm?lang=en
To view the value of these ports specified in the workbench, double-click the server in the Servers View to open the server editor. In the server editor, verify the port values under the Server section match those of the server. If not, correct the port values specified in the workbench and try your connection again.
Firewall
If there is a firewall between the development machine and the server, verify that you are using the SOAP connection type for the server. In addition, verify the firewall allows connections through the configured SOAP connector port. The SOAP connectors are designed to be more tolerant to the firewall.
Invalid security settings
If the server security is enabled, the correct security credentials must be provided. Open the server editor by double-clicking the server in the Servers View and expand the Security section. Verify the Security is enabled on this server check box is selected, and a valid user ID and password for the secure server are provided. A valid user ID and password are ones that can authenticate against the server security registry, for example, credentials that can be used as a login to the Administrative Console.
Invalid runtime used in the workbench to define the server
When defining a server in the workbench, you must specify a runtime for the target server. The server runtime environment defined in the workbench must match the target server and its version-level.
To verify the version level of the target server, view the Welcome page of the Administrative Console.
To verify the server runtime of the server in the workbench, open the server editor and verify the runtime specified in the Runtime field under the General section matches the version level of the server. If it does not, correct the server runtime used in the workbench server to match that of the target server.
Local server IP address changed
If the server is running on the same machine as the workbench, when the IP address of the machine changes the workbench may have difficulty reconnecting to the server. This scenario occurs most often in a wireless network environment where the IP address of the machine may change when moving from a local area network (LAN) to a wireless adapter. The details and workarounds for this issue are referenced in the following technote:
| http://www.ibm.com/support/docview.wss?uid=swg21287363 |
SOAP connector runs out of Operating System network resources
There is a known issue that can cause the SOAP connector to continuously consume Operating System network resources over a long period of time. Eventually this can exhaust the Operating System network resources, and as a result the workbench is unable to establish further connections. In addition to the information mentioned in the technote below, the following output may be displayed multiple times on the console for the IBM® WebSphere® Application Server when this problem occurs:
08/11/07 10:49:37:343 EST] 000000f6 HttpConnectio E Unable to read and handle request: null
08/11/07 10:49:37:343 EST] 000000f6 HttpConnectio E Unable to read and handle request: null
[08/11/07 10:49:41:296 EST] 000000eb HttpConnectio E Unable to read and handle request: null
The details and workarounds for this issue are referenced in the following technote:
http://www.ibm.com/support/docview.wss?uid=swg1PK38909
If the information above does not help to resolve the issue please contact IBM Support for further assistance using the Service Request (SR) tool: (http://www.ibm.com/software/support/probsub.html)
You can also visit the WebSphere Application Server Support website: http://www.ibm.com/software/webservers/appserv/was/support/, contact 1-800-IBM-SERV (U.S. only) or consult the Software Support Handbook:
http://www14.software.ibm.com/webapp/set2/sas/f/handbook/contacts.html
Mismatched Security Algorithm Settings
If the SSL certificate of WebSphere Application Server does not meet the more stringent security requirements of newer Java(tm) virtual machines (JVMs), then the communication to WebSphere Application Server fails. For example, the server status might show as stopped even though it is started.
The problem occurs when Rational Application Developer is using Oracle Java runtime environment (JRE) version 7 update 40 or newer, or an IBM(r) Runtime Environment for Java 1.7 SR6 or newer. In these versions of JREs, the use of an x.509 certificate with RSA keys of less than 1024 bits in length is disallowed. This new behavior is the result of adding a key size requirement in these JREs in the jre/lib/security/java.security file as follows:
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
This means that any certificate signed with the MD2 message digest algorithm or with a Rivest Shamir Adleman (RSA) key of length less than 1024 bits, is not acceptable. By default, the key size for certificates in WebSphere Application Server V7 is 1024 whereas for WebSphere Application Server V8.x it is 2048. If the customer creates a profile with a key size smaller than the default, the workbench fails to communicate with WebSphere Application Server and the server status is not detected correctly. This situation occurs because the newer values (key size less than 1024) do not adhere to the requirements of the key size for Oracle JRE version 7 update 40 or newer, or an IBM Runtime Environment for Java 1.7 SR6 or newer. Therefore, use the default values only when a new profile is created.
Related Information
[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Application Server Toolkit (AST)","Platform":[{"code":"PF016","label":"Linux"},{"code":"PF033","label":"Windows"}],"Version":"7.0;6.1.1;6.1;6.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SSRTLW","label":"Rational Application Developer for WebSphere Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Server Tooling","Platform":[{"code":"PF033","label":"Windows"},{"code":"PF016","label":"Linux"}],"Version":"7.0","Edition":"All Editions","Line of Business":{"code":"LOB45","label":"Automation"}}]
Product Synonym
RAD;RSA;WID;AST;WDT
Was this topic helpful?
Document Information
Modified date:
30 May 2023
UID
swg21266028