Cloud Pak Foundational Services upgraded to the websphere liberty version - 26.0.0.5. With this version upgrade, we are observing that after a container restart of our service using liberty - our service goes unreachable. On checking the logs, we are observing an FFDC -
javax.crypto.BadPaddingException
com.ibm.ws.security.token.ltpa.LTPAKeyInfoManager
Please note, we do not use LTPA keys and this comes with liberty. Therefore, we do not have any configuration set for this ltpa.keys.
Steps / Observation
- The issue is triggered by a container restart in isolation— the pod itself does not restart.
- After the restart, we confirmed that the ltpa.keys file isnot regenerated. We believe this is because the cleanup of the existing LTPA state does not occur on container restart, leading to akey mismatch that produces the BadPadding Exception.
- We are aware from open-liberty#34866 that LTPA is now a required component in Liberty even when the application does not explicitly configure or use it.
Ask
Is there a supported mechanism by which Liberty can automatically clean up the LTPA keys on container restart to prevent this mismatch? If not, is there an alternative approach (e.g., a config option, a startup hook, or a known workaround) to avoid this FFDC and the resulting service unavailability?
Cloud Pak Foundational Services upgraded to the websphere liberty version - 26.0.0.5. With this version upgrade, we are observing that after a container restart of our service using liberty - our service goes unreachable. On checking the logs, we are observing an FFDC -
Please note, we do not use LTPA keys and this comes with liberty. Therefore, we do not have any configuration set for this ltpa.keys.
Steps / Observation
Ask
Is there a supported mechanism by which Liberty can automatically clean up the LTPA keys on container restart to prevent this mismatch? If not, is there an alternative approach (e.g., a config option, a startup hook, or a known workaround) to avoid this FFDC and the resulting service unavailability?