IBM Support

MustGather: SSL problems on WebSphere Traditional

Troubleshooting


Problem

Collecting data for problems with the Java™ Security (JSSE/JCE) and SSL component in IBM WebSphere Application Server traditional. Gathering this MustGather information before calling IBM support will help you understand the problem and save time analyzing the data.

Resolving The Problem


Runtime:

This document is for collecting data for WEBSPHERE TRADITIONAL. If you want to collect data for Liberty, see MustGather: SSL problems on WebSphere Liberty or click the Liberty tab above.

 
  • Read first and MustGathers
  • Exchange data with IBM Support

    To diagnose or identify a problem, it is sometimes necessary to provide Technical Support with data and information from your system. In addition, Technical Support might also need to provide you with tools or utilities to be used in problem determination. You can submit files using one of following methods to help speed problem diagnosis:


  • SSL on WebSphere traditional trace specifications
    • SSL trace specification:
      *=info:SSL=all
    • Java virtual machine (JVM) Custom Property
      javax.net.debug=all
  • Diagnostic questions
    Please provide answers to the following diagnostic questions:
    1. Are you using the default Java Secure Socket Extension (JSSE) providers?
    2. Are you using any third party JCE framework with your application?
    3. Where is the SSL issue occurring?
      1. Between the client (browser) and the Web server?
        For example: When trying to access a Web resource on the Web server over HTTPS.
      2. Between the client (browser) and the Application Server built-in Web server?
        For example: When trying to access the Application Server administrative console.
      3. Between the Web server plug-in and the Application Server?
        For example: When trying to access a Web resource on the Application Server over HTTPS.
      4. Using SSL when connecting to directory servers (LDAP)?
      5. Using your own application to make an SSL connection?
        • Provide the exact url or remote server hostname called by your application.
  • Collect data for WebSphere traditional (step-by-step)
    • This section is for collecting data for WEBSPHERE TRADITIONAL. If you want to collect data for Liberty click here or see the Liberty tab above.
    • You may choose to follow this step-by-step document or you can watch the video in the Collect data for WebSphere traditional (video) section below.
    • Before you collect data, be sure to answer the Diagnostic questions in the section above.

      1. ADD THE javax.net.debug JVM PROPERTY
    • Set the following Java virtual machine (JVM) custom property for the JVM being traced:
      javax.net.debug=all
    To accomplish this, perform the following steps:
    Note: If you were not told which JVM to trace, or for some reason you are not sure which of the JVMs need this kind of tracing, set it on all of them.
    1. In the administrative console, set the javax.net.debug system property using one of the following options, depending on where the SSL issue is occurring:
      • For tracing an Application server, select the following:
        Servers > Server Types > WebSphere Application Servers > server_name > Expand Java and Process Management (under Server Infrastructure) >Process definition > Java Virtual Machine > Custom properties > New...
      • For tracing a Deployment Manager, select the following:
        System Administration > Deployment manager > Expand Java and Process Management (under Server Infrastructure) >Process definition > Java Virtual Machine > Custom properties > New...
      • For tracing a Node agent, select the following:
        System Administration > Node agents > (pick a node agent) > Expand Java and Process Management (under Server Infrastructure) >Process definition > Java Virtual Machine > Custom properties > New...
    2. Enter the following:
      Name: javax.net.debug
      Value: all
    3. Click Apply, then Save

      2. SET UP WEBSPHERE TRADITIONAL FOR SSL TRACING
    1. Expand Troubleshooting > Logs and trace > server_name
    2. Select Diagnostic Trace.
    3. Set the Maximum Number of Historical Files to 20.
    4. Click Apply
    5. Select Change log detail levels.
      • Set the trace specification to:
        *=info:SSL=all
    6. Click OK, then OK
    7. Select JVM Logs.
      • Under System.out, ensure that the Show application print statements box is checked under Installed Application Output.
    8. Click OK, then Save

      3. COLLECT WEBSPHERE TRADITIONAL SSL TRACES
    Avoid delay: It is important that SSL traces be gathered from server server startup.

    For each WebSphere server that you are tracing:
    1. Stop the server.
    2. Backup and clear the logs and FFDC directories.
    3. Start the server
    4. Reproduce the problem, making note of time when the problem occurs

      4. GATHER WEBSPHERE TRADITIONAL SSL DATA TO SEND TO IBM
    Avoid delay: All of the following data is required for proper problem determination of most issues. Do not send a subset of this data unless you were instructed to do so by IBM support.
     
    Data to send
    Instructions
    Diagnostic questions Answer the Diagnostic questions in the section above.
    A collector jar

    Note: You need to run the collector tool on each <PROFILE_ROOT> in which you enabled trace.
     
    From a temporary directory, run the Collector Tool, collector.sh or collector.bat, which is located in the <PROFILE_ROOT>/bin directory.

    If there is a message about the collector tool being deprecated, ignore it; this is the tool IBM support needs you to run.
    Java version Save the Java version by redirecting the output of the following command to a file
    • From <WAS_HOME>/java/bin, run:
      For Windows platforms,
      java -fullversion
      For Unix platforms,
      ./java -fullversion
    java.security <WAS_HOME>/java/jre/lib/security/java.security
    JSSE client-side trace
    (if requested)
    This file is only required if you were asked by IBM support to collect a JSSE client side trace.

    See the information in Exchanging information with IBM Technical Support for problem determination to send this diagnostic information to IBM support.

     
  • Collect data for WebSphere traditional (video)
    • This section is for collecting data for WEBSPHERE TRADITIONAL. If you want to collect data for Liberty click here or see the Liberty tab above.
    • You may choose to watch this video or follow the step-by-step instructions in the in the Collect data for WebSphere traditional (step-by-step) section above.
    • Before you collect data, be sure to answer the Diagnostic questions in the section above.

    The following video goes over the necessary steps to collect data for a SSL problem on WebSphere traditional.

    Please make sure to collect all the information described in the video. When all the information for your issue is ready, follow the instructions on Exchanging information with IBM Technical Support for problem determination to send the information and files that you collected.

  • Collect JSSE client-side trace

    JSSE client-side traces are required when you are observing SSL issues with a Java application that is interacting with a running WebSphere Application Server process.

    If you are asked to run JSSE client side traces, do the following for your Operating System:

    • Unix
      • If you are working on SSL issues when running wsadmin, you can use the -javaoption to enable JSSE tracing.
        Note: You can debug most client-side SSL issues with wsadmin
        1. Navigate to the bin directory of the profile
        2. Run the following command:
          ./wsadmin.sh -trace -javaoption -Djavax.net.debug=all
      • If you need to debug one of the other WebSphere client commands, like stopServer, serverStatus, etc. you can enable traces with the following technique:
        1. Open a Unix shell, then set the following environment variables:
          export WAS_TRACE="-Djavax.net.debug=all"
          export WAS_DEBUG="-Djavax.net.debug=all"
        2. Put timestamp and host information in the log file:
          1. Navigate to the bin directory of the profile
          2. Run the following command:
            date +"%m/%d/%Y %H:%M:%S $HOSTNAME" >>clientSSL.log 2>&1
        3. Run the client-side command, redirecting the output to the log file. For example:
          ./serverStatus.sh server1 -trace -user (USERNAME) -password (PASSWORD) >>clientSSL.log 2>&1
        4. To turn tracing off, unset the environment variables:
          unset WAS_TRACE
          unset WAS_DEBUG
          Note: You can use echo to show what environment variables are set to, for these you could use "echo $WAS_TRACE $WAS_DEBUG".
      • Alternatively you can modify the calling script to add javax.net.debug=all
        Modify the calling script to add the following to where Java is called:
        -Djavax.net.debug=all

       Send the resulting clientSSL.log file located in the profile's bin directory to IBM, along with any additional information that was requested.
       
    • Windows
      • If you are working on SSL issues when running wsadmin, you can use the -javaoption to enable JSSE tracing.
        Note: You can debug most client-side SSL issues with wsadmin
        1. Navigate to the bin directory of the profile
        2. Run the following command:
          wsadmin -trace -javaoption -Djavax.net.debug=all
      • If you need to debug one of the other WebSphere client commands, like stopServer, serverStatus, etc. you can enable traces with the following technique:
        1. Open a command window, then set the following environment variables:
          set WAS_TRACE="-Djavax.net.debug=all"
          set WAS_DEBUG="-Djavax.net.debug=all"
        2. Put timestamp and host information in the log file:
          1. Navigate to the bin directory of the profile
          2. Run the following commands:
            echo %date% %time% %computername% >>clientSSL.log 2>&1
            tzutil /g >>clientSSL.log 2>&1
        3. Run the client-side command, redirecting the output to the log file. For example:
          serverStatus server1 -trace -user (USERNAME) -password (PASSWORD) >>clientSSL.log 2>&1
        4. To turn tracing off, unset the environment variables:
          set WAS_TRACE=
          set WAS_DEBUG=
          Note: You can use echo to show what environment variables are set to, for these you could use "set WAS".
      • Alternatively you can modify the calling script to add javax.net.debug=all
        Modify the calling script to add the following to where Java is called:
        -Djavax.net.debug=all

       Send the resulting clientSSL.log file located in the profile's bin directory to IBM, along with any additional information that was requested.
       
 
 
 

Note: This document uses the term WebSphere traditional to refer to WebSphere Application Server v9.0 traditional, WebSphere Application Server v8.5 full profile, WebSphere Application Server v8.0 and earlier, WebSphere classic, traditional WebSphere, traditional WAS and tWAS.
 

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Component":"Java Security (JSSE\/JCE)","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF012","label":"IBM i"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"},{"code":"PF035","label":"z\/OS"}],"Version":"9.0;8.5","Edition":"Base;Network Deployment","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SSNVBF","label":"Runtimes for Java Technology"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Java SDK","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
02 July 2021

UID

swg21162961