PI33475: UNDER CERTAIN CIRCUMSTANCES, WORKLIGHT SERVER MAY USE JVM KEYSTORE RATHER THAN APP SERVER KEYSTORE.

IBM MobileFirst Platform Foundation Interim Fix README for 6.3
IBM Worklight Interim Fix README for 6.2.0.1

APAR status

• Closed as program error.

Error description

• Under some conditions, the Worklight Server may use the JVM's
  SSL keystore rather than the application server's SSL keystore.
   This may cause unexpected results if the application is
  expecting the application server's keystore to be used.
  

Local fix

• If the application is not using multiple keystores, it is
  possible to force the application to use the application
  server's keystore by setting the following JVM properties:
  
  javax.net.ssl.keyStore with the app server keystore location as
  value
  
  javax.net.ssl.keyStorePassword with the keystore password as
  value
  
  javax.net.ssl.keyStoreType with the keystore type as value
  (PKCS12)
  
  javax.net.ssl.trustStore with the app server truststore
  location as value
  
  javax.net.ssl.trustStorePassword with the truststore password
  as value
  javax.net.ssl.trustStoreType with the truststore type as value
  (PKCS12)
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * Mobile users                                                 *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * The HTTP adapter doesn't leverage the WebSphere SSL          *
  * configuration and uses the JRE truststore as the current     *
  * truststore instead of getting the one associated to the SSL  *
  * configuration defined in WebSphere                           *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * -                                                            *
  ****************************************************************
  

Problem conclusion

• By default the HTTP adapter doesn't leverage the WebSphere SSL
  configuration and concatenates the JRE truststore with the
  Worklight truststore referenced by the properties :
  ssl.keystore.path, ssl.keystore.password, ssl.keystore.type.
  
  To leverage the WebSphere SSL configuration, the
  ssl.websphere.config property must be set  to true. In this case
  in order :
  
  1) If the ssl.keystore.path, ssl.keystore.password,
  ssl.keystore.type properties are set, the adapter will use the
  truststore referenced in these properties without concatenating
  it with the JRE truststore
  2) If the ssl.websphere.alias property is set, the adapter will
  use the SSL configuration associated with the alias set in this
  property.
  3) If the ssl.keystore.path, ssl.keystore.password,
  ssl.keystore.type and ssl.websphere.alias properties are not set
  the WebSphere outbound dynamic configuration is used.
  
  The runtime file must be rebuilt with Studio in order that it
  generates the new ssl.websphere.config and ssl.websphere.alias
  properties.
  

Temporary fix

Comments

APAR Information

• 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

  WL/MFPF CONSUME

• Fixed component ID

  5725I4301

Applicable component levels

• R620 PSY

     UP

• R630 PSY

     UP