IBM Support

PI77605: JAXRS Client APIs do not use configured SSL settings

Fixes are available

17.0.0.2: WebSphere Application Server Liberty 17.0.0.2
17.0.0.3: WebSphere Application Server Liberty 17.0.0.3
17.0.0.4: WebSphere Application Server Liberty 17.0.0.4
18.0.0.1: WebSphere Application Server Liberty 18.0.0.1
18.0.0.2: WebSphere Application Server Liberty 18.0.0.2
18.0.0.3: WebSphere Application Server Liberty 18.0.0.3
18.0.0.4: WebSphere Application Server Liberty 18.0.0.4
19.0.0.1: WebSphere Application Server Liberty 19.0.0.1
19.0.0.2: WebSphere Application Server Liberty 19.0.0.2
19.0.0.3: WebSphere Application Server Liberty 19.0.0.3
19.0.0.4: WebSphere Application Server Liberty 19.0.0.4
19.0.0.5: WebSphere Application Server Liberty 19.0.0.5
19.0.0.6: WebSphere Application Server Liberty 19.0.0.6
19.0.0.7: WebSphere Application Server Liberty 19.0.0.7
19.0.0.8: WebSphere Application Server Liberty 19.0.0.8
19.0.0.9: WebSphere Application Server Liberty 19.0.0.9
19.0.0.10: WebSphere Application Server Liberty 19.0.0.10
19.0.0.11: WebSphere Application Server Liberty 19.0.0.11
19.0.0.12: WebSphere Application Server Liberty 19.0.0.12
20.0.0.1: WebSphere Application Server Liberty 20.0.0.1
20.0.0.2: WebSphere Application Server Liberty 20.0.0.2
20.0.0.3: WebSphere Application Server Liberty 20.0.0.3
20.0.0.4: WebSphere Application Server Liberty 20.0.0.4
20.0.0.5: WebSphere Application Server Liberty 20.0.0.5
20.0.0.6: WebSphere Application Server Liberty 20.0.0.6
20.0.0.7: WebSphere Application Server Liberty 20.0.0.7
20.0.0.8: WebSphere Application Server Liberty 20.0.0.8
20.0.0.9: WebSphere Application Server Liberty 20.0.0.9
20.0.0.10: WebSphere Application Server Liberty 20.0.0.10
20.0.0.11: WebSphere Application Server Liberty 20.0.0.11
20.0.0.12: WebSphere Application Server Liberty 20.0.0.12

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The Liberty JAX-RS client allows users to specify an SSL
    configuration in the Liberty configuration (server.xml) that
    defines various settings like keystore location, truststore
    location, etc.  That configuration must declare a
    referenceable ID, and then JAX-RS clients can use those
    settings (rather than the JVM's default SSL settings).
    
    The client code might look something like this:
            ClientBuilder cb = ClientBuilder.newBuilder();
    cb.property("com.ibm.ws.jaxrs.client.ssl.config",
    "mySSLConfig"); // mySSLConfig is the ID for the ssl config
    in server.xml
            Client c = cb.build();
    WebTarget target = c.target("https://" + host + ":" + port +
    "/somePath");
            ...
    
    In most cases, the client will use the SSL settings defined
    in the Liberty configuration with the ID of "mySSLConfig".
    However, when using the path() method on the WebTarget
    object and using templates, the client will no longer use
    the "mySSLConfig" settings and will resort to the JDK's
    default SSL settings.  An example of the client code is:
    WebTarget newTarget =
    target.path("items/{itemNum}").resolveTemplate("itemNum",
    "17");
    
    In the above line of code the call to
    target.path("items/{itemNum}") contains a template.  That
    call will produce a WebTarget instance that does not
    preserve the SSL settings from the previous instance of
    WebTarget.  This can cause various types of SSL issues - for
    example, in cases where the configured SSL settings
    reference a keystore that contains an SSL certificate that
    does not exist in the JVM's default keystore.  That client
    would be able to successfully make some calls (those without
    the template path) to the remote service, but other calls
    (those that use the template path) would fail with SSL
    handshake errors.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server Liberty - JAX-RS                     *
    ****************************************************************
    * PROBLEM DESCRIPTION: JAXRS Client APIs do not use configured *
    *                      SSL settings                            *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The Liberty JAX-RS client allows users to specify an SSL
    configuration in the Liberty configuration (server.xml) that
    defines various settings like keystore location, truststore
    location, etc.  That configuration must declare a referenceable
    ID, and then JAX-RS clients can use those settings (rather than
    the JVM's default SSL settings).
    
    The client code might look something like this:
            ClientBuilder cb = ClientBuilder.newBuilder();
            cb.property("com.ibm.ws.jaxrs.client.ssl.config",
    "mySSLConfig"); // mySSLConfig is the ID for the ssl config in
    server.xml
            Client c = cb.build();
            WebTarget target = c.target("https://" + host + ":" +
    port + "/somePath");
            ...
    
    In most cases, the client will use the SSL settings defined in
    the Liberty configuration with the ID of "mySSLConfig".
    However, when using the path() method on the WebTarget object
    and using templates, the client will no longer use the
    "mySSLConfig" settings and will resort to the JDK's default SSL
    settings.  An example of the client code is:
            WebTarget newTarget =
    target.path("items/{itemNum}").resolveTemplate("itemNum",
    "17");
    
    In the above line of code the call to
    target.path("items/{itemNum}") contains a template.  That call
    will produce a WebTarget instance that does not preserve the SSL
    settings from the previous instance of WebTarget.  This can
    cause various types of SSL issues - for example, in cases where
    the configured SSL settings reference a keystore that contains
    an SSL certificate that does not exist in the JVM's default
    keystore.  That client would be able to successfully make some
    calls (those without the template path) to the remote service,
    but other calls (those that use the template path) would fail
    with SSL handshake errors.
    

Problem conclusion

  • The fix for this APAR ensures that the client's SSL settings are
    preserved when calling the path method and specifying a
    template.
    
    The fix for this APAR is currently targeted for inclusion in fix
    pack 17.0.0.2.  Please refer to the Recommended Updates page for
    delivery information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI77605

  • Reported component name

    WAS LIBERTY COR

  • Reported component ID

    5725L2900

  • Reported release

    CD0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2017-03-03

  • Closed date

    2017-03-10

  • Last modified date

    2017-03-10

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    WAS LIBERTY COR

  • Fixed component ID

    5725L2900

Applicable component levels

  • RCD0 PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud \u0026 Data Platform"},"Product":{"code":"SSD28V","label":"WebSphere Application Server Liberty Core"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"CD0","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
18 October 2021