PH15505: COLLECTIVES KEYSTORE MISMATCH

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

APAR status

• Closed as program error.

Error description

• The collective default keystore format has changed with
  version
  19.0.0.3 and onwards from JKS to PKCS12.
  
  When trying to join an application that was installed on
  version 19.0.0.6 core to a Liberty collective controller
  which
  was created on Liberty v ersion18.0.0.4., it had *.p12
  keystores produced by the collective join command but *.jks
  keystores in the resources folder:
  
  17608565 4 -rw-rw-r-- 1 jxadmin wasadmin 3339 Aug 5 14:09
  resources/collective/serverIdentity.jks
  17608566 4 -rw-rw-r-- 1 jxadmin wasadmin 1932 Aug 5 14:09
  resources/collective/collectiveTrust.jks
  26724966 4 -rw-rw-r-- 1 jxadmin wasadmin 3169 Aug 5 14:09
  resources/security/key.jks
  26724969 4 -rw-rw-r-- 1 jxadmin wasadmin 1932 Aug 5 14:09
  resources/security/trust.p12
  
  Because of the mismatch in keystore types, the applications
  do
  not work.
  

Local fix

• 1, Rename the trust.p12 under resources/security to trust.jks
  (it really does get created as a JKS file format but named as
  .p12)
  2, Rename all of the .p12 references in server.xml for the new
  uplevel member to .jks
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  Users who set up a collective controller    *
  *                  prior to 19.0.0.3, and adding a member at   *
  *                  or above 19.0.0.3 level to the controller   *
  ****************************************************************
  * PROBLEM DESCRIPTION: Controller to member communication      *
  *                      fails after joining a new collective    *
  *                      member to a collective controller that  *
  *                      was created prior to 19.0.0.3.          *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  If a collective member is added to a collective controller that
  was created prior to 19.0.0.3, the collective join command will
  create a trust keystore of type JKS but with an incorrect file
  extension of .p12.  Also, the collective configuration snippet
  of xml is created with a .p12 extension for all keystores where
  the keystore type for each should be .jks.  This will prevent
  future communication between the collective controller and the
  member that is being joined.
  

Problem conclusion

• The bug was fixed.
  
  The fix for this APAR is currently targeted for inclusion in fix
  pack 19.0.0.9. Please refer to the Recommended Updates page for
  delivery information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

Temporary fix

• 1) Rename the trust.p12 under resources/security to trust.jks
  2) Rname all of the .p12 references in server.xml for the new
  uplevel member to .jks
  

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

  LIBERTY PROFILE

• Fixed component ID

  5724J0814

Applicable component levels

• RCD0 PSY

     UP