IBM Support

Troubleshooting: Unable to open PKCS12 keystores due to an UnrecoverableKeyException

Troubleshooting


Problem

During startup of the WebSphere Application Server or WebSphere Liberty a failure occurs and startup is aborted; or performing management operations on a PKCS12 keystore an error occurs preventing the keystore operation.  An error that indicates a failure to load a keystore is recorded in the logs.
Additionally, attempts to roll back to a previous SDK version do not resolve the problem. 

Symptom

In the log files on the affected server, or during keystore management operations, you might observe any number of messages and thread stacks related to failing to load or manage a PKCS12 keystore:
  • com.ibm.security.pkcsutil.PKCSException: Error extracting SafeBags from PFX (java.io.IOException: java.lang.reflect.InvocationTargetException)
  • java.io.IOException: Error extracting keyentry aliases from PFX
  • java.io.IOException: Integrity check failed: java.security.UnrecoverableKeyException: Failed PKCS12 integrity checking
  • java.io.IOException: ObjectIdentifier() -- data isn't an object ID (tag = 48)
  • java.security.UnrecoverableKeyException: Failed PKCS12 integrity checking
  • Key store file <FILE_NAME> did not verify, make sure the file or keyring exists, check key store type and password.
    • This specific message can also be due to an incorrect password, recommend verifying the password used for the keystore first.
  • Private key not stored as PKCS#8 EncryptedPrivateKeyInfo
The errors can be embedded in other exceptions:
  • CWPKI0061E: Error while initializing keymanager for the NodeDefaultSSLSettings SSLContext. The NodeDefaultKeyStore keystore at /opt/IBM/WebSphere/AppServer/profiles/myServer/config/cells/myCell/nodes/myNode/key.p12 might have a personal certificate with a password that is different from the keystore password. The extended error message is as follows: Private key not stored as PKCS#8 EncryptedPrivateKeyInfo: java.io.IOException: ObjectIdentifier() -- data isn't an object ID (tag = 48)
The errors displayed in the admin console during a keystore management operation (including deletion, importing, exporting, receiving from a certificate authority, or renewing a certificate):
  • If the keystore itself was initially created that uses the stronger algorithms, the operation fails with this error:
 Error: An error occurred deleting <CERTIFICATE NAME>: CWPKI0033E: The keystore located at "/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/wstemp/-1288659335/workspace/cells/<<REDACTED>>Cell01/nodes/<<REDACTED>>Node01/deleted.p12" failed to load due to the following error: Error extracting keyentry aliases from PFX.
  • If the keystore was initially created with the weaker algorithms (but some certificates are using the stronger algorithms), the operation fails with this error:
An error occurred deleting <<CERTIFICATE NAME>>: Private key not stored as PKCS#8 EncryptedPrivateKeyInfoObjectIdentifier() - data isn't an object ID (tag = 48)
  • During a certificate import (or export), if the keystore is using the weaker algorithms, you might see a generic error reported if the keystore exists.
    This error can normally be seen if the password is entered incorrectly (the operation does this check after pressing OK or Apply).  Recommend verifying the password as a first step if you see this specific error message before proceeding.
CWPKI0663E: Key store file key.p12 did not verify, make sure the file or keyring exists, check key store type and password.

Cause

An upgrade in the algorithms used in generating new PKCS12 keystores (or new certificates within existing PKCS12 keystores) affects older environments where the newer, stronger algorithms are not supported. 
If keystores (or certificates) generated in the newer IBM SDK 8.0.8.0 (or IBM Semeru Runtimes 11.0.12.0) are copied over to be used on the older environments, errors can occur. 

Resolving The Problem

Upgrading the IBM SDK to 8.0.8.0 (or IBM Semeru Runtime 11.0.12.0) or later permanently resolves the issue.
image-20240214154354-1
Rolling back your IBM SDK or fix pack does not resolve this issue!
The problem is related to the fact that the stronger algorithms in use in the keystores are unsupported in the older SDKs.
Solution - Upgrade the IBM SDK
Note: It is highly recommended to upgrade the SDK, as the stronger algorithms are preferred going forward. 
Make sure that the IBM SDKs installed are upgraded to 8.0.8.0 or later (or 11.0.12.0 and later for IBM Semeru Runtime) in all environments.  The upgraded environments can open keystores that use either set of algorithms, and can generate new keystores and certificates that use the newer algorithms.
On WebSphere Application Server 8.5.5, you can use managesdk to switch the SDK (usually to the bundled variant) if multiple SDKs are installed.  However, the managesdk command might need to make a connection to the Deployment Manager, and can use the key.p12 (and trust.p12) in the profile's /etc directory. 
However, once you do upgrade the IBM SDKs in your environments, if the keystore.pkcs12.legacy property was previously configured, remove the property to re-enable the use of stronger algorithms on new certificates and keystores.
  • Alternative Workaround- Enabling Weaker Algorithms
    Upgrading to IBM SDK 8.0.8.0 (or IBM Semeru Runtime 11.0.12.0 or later) permanently resolve the issues.
    If you cannot upgrade all the SDKs to the newer versions mentioned in this document, configure the keystore.pkcs12.legacy property and convert PKCS12 keystores to use the weaker algorithms to workaround the issues.  
    1. Enabling Weaker Algorithms Across the Installation
    • Apply the following custom property in the java.security file on any environments that use the newer SDKs to force the use of the weaker algorithms.  The property doesn't have a value. 
      * Available on IBM SDK 8.0.8.0 (and IBM Semeru Runtime 11.0.12.0) or later
    keystore.pkcs12.legacy
    • The property can also be set as a JVM argument:
    -Dkeystore.pkcs12.legacy
    2. Convert Affected Keystores to use Weaker Algorithms
    • Determine which PKCS12 keystores use the weaker algorithms, and then run the keytool -importkeystore command with the property enabled on the newer SDK.
      • keytool -importkeystore -srckeystore sourcekey.p12 \
                -destkeystore newkeystore.p12 -srcstoretype PKCS12 \
                -deststoretype PKCS12 -J-Dkeystore.pkcs12.legacy
        • NOTE: If the destination keystore doesn't currently exist, keytool attempts to create the keystore for you... but cannot create a keystore with a password shorter than 6 characters.
      • If the preceding command fails due to one of the following errors, you must target the individual aliases one at a time to proceed.  Ensure the argument -srckeypass matches the source keystore's password, and -destkeypass matches the new keystore password.
        • keytool error: java.lang.Exception: The destination pkcs12 keystore has different storepass and keypass. Please retry with -destkeypass specified.
        • keytool error: java.lang.Exception: if -alias not specified, -destalias and -srckeypass must not be specified
        • keytool -importkeystore -srckeystore sourcekey.p12 \
                  -destkeystore newkeystore.p12 -srcstoretype PKCS12 \
                  -deststoretype PKCS12 -J-Dkeystore.pkcs12.legacy \
                  -srckeypass SOURCE_PASSWORD -destkeypass NEW_PASSWORD -alias ALIAS_NAME
    • Take the new keystore and replace it with the original:
      • In a WebSphere Application Server deployment manager environment, where you have multiple nodes in a single cell, copy the new keystore file in place of the original.  Then, synchronize your nodes.
      • For other environments (such as WebSphere Liberty, or a stand-alone WebSphere Application Server instance), copy the new keystore in place of the original.
    3. Restart the Application Servers
    • Restart your application server instances to ensure the keystores, and java.security, are reloaded.
  • Additional Info on Mixed Environments
    A mixed environment is one that meets the following criteria:
    • A deployment manager that is upgraded to the latest SDK, but the nodes (specifically instances installed on a different system, or within a different installation) are not upgraded.
    • A deployment manager cell where different application server instances (running WebSphere Application Server 8.5.5) are set up to use different IBM SDKs (managesdk command). 
    • A set of WebSphere Liberty instances that are running different SDK versions, including collective controllers and their members.
    If you have a mixed environment, the workaround can be applied until you can upgrade the IBM SDK. 
    • First, enable weaker algorithms with the keystore.pkcs12.legacy property on the IBM SDK 8.0.8.0 or later environment.
      • You do not need to set the property on any older SDK environment.
    • Then, convert any keystores that are affected to use the weaker algorithms so they can be used with the earlier SDK environments.
  • Optional Debugging
    Determining Which Keystores are Affected
    Usually the errors are due to a recent change to a keystore in the configuration (such as a certificate renewal), and those keystores have an updated timestamp. 
    If you are performing management operations on a keystore in the admin console, check that keystore (as well as the deleted.p12 keystore). 
    If you do not know which keystores are impacted (perhaps an automated renewal occurred), inspect the timestamps of the files.  Then, use keytool or openssl to help identify which keystore does not load.
    Keytool
    The keytool -list command (run on the older IBM SDK) can verify whether a keystore can be opened.  A keystore with newer algorithms fails with the following error:
    keytool -list -keystore keystore.p12 -storetype PKCS12
    keytool error (likely untranslated): java.io.IOException: Error extracting keyentry aliases from PFX
    OpenSSL
    This command outputs debug information about the algorithms used on certificates (keys) and the keystore (the -noout argument suppresses the full list output).
    openssl pkcs12 -info -in /path/to/keystore.p12 -noout
    • If the weaker algorithms (PBE with SHA1) are in use:
      Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 50000
      PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 50000
    • If the stronger algorithms (PBES2 and AES) are in use:
      Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
      PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
    • You can also see a mixed set of algorithms.  Indicates some of the keys (or just the keystore itself) use the weaker algorithms:
      Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
      PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 1
    • If you see a warning message about an unsupported bag type, this is indicating a newer algorithm is in use, but openssl doesn't know what that algorithm is.  It's very likely you are running an older version of openssl if you see this message.
      Warning unsupported bag type: crlBag
  • Additional Questions
    I have a JKS keystore, is that affected?
    No.  The JKS keystores use different algorithms (and is a different format altogether) from the PKCS12 keystores.
    For reference, the cacerts keystore is in the JKS keystore format. 
    Are the CMSKeystore instances affected (plugin-key.kdb)?
    No. The CMSKeystore uses the CMS keystore format (.kdb files) and doesn't use the algorithms that are used by a PKCS12 keystore. 
    What is the deleted keystore (deleted.p12)?
    This keystore is used to store any certificates that are deleted from the admin console or during renewal operations (including automated ones).  A copy of the deleted certificate (or deleted signer) is exported (with an adjusted name, mainly to indicate which keystore the certificate originated from) to the NodeDefaultDeletedStore or DmgrDefaultDeletedStore (representing the file deleted.p12). 
    How is the deleted keystore related to the UnrecoverableKeyException?
    The deleted.p12 keystore contains exported copies of recently deleted (or renewed) certificates, which use the current algorithms based on the IBM SDK installed and any arguments or properties configured.
    If you later roll back your environment sometime after the deleted.p12 keystore is updated, keystore management operations can produce error messages.
    If you cannot upgrade the SDK, you need to convert the deleted.p12 keystore to restore normal operations.  
    What if the keystore affected is one I received from a Certificate Authority, or a keystore that I'm trying to use for importing a shared personal certificate into other environment?
    If the keystore was created with the stronger algorithms by your CA, you need to convert the keystore first to use the weaker algorithms (such as keytool -importkeystore), then perform the import or export operations as normal. 
    Can I create a new keystore in the WebSphere Application Server admin console that use the legacy algorithms?
    Yes. The admin console uses the java.security or the JVM arguments outlined earlier in this technote to dictate which algorithms to use on an upgraded IBM SDK. 
    You can use the admin console to create new (empty) keystores in the Security > SSL Certificate and Key Management > Keystores and Certificates panel with the weaker algorithms. 
    By default, if you create new keystore in IBM SDK 8.0.8.0 without any options or properties mentioned in this technote, the new keystore uses the preferred stronger algorithms
    What if I import or export certificates to another keystore?  What algorithms are used?
    The import and export operations are also directly related to the options and properties mentioned in this technote. 
    By default the newer SDKs use the stronger algorithms for encoding certificates in keystores during the import or export operations. 
    What if I renew my certificate (or they auto-renwed), or receive a new CA certificate.  Do these certificates use the stronger algorithms?
    Yes. IBM SDK 8.0.8.0 renews certificates by using the stronger algorithms. 
    If you have a mixed environment, such as a node that is still on an older IBM SDK, you can have issues with those certificates.  Converting the keystore to use the older algorithms (and re-synchronizing the node) can restore normal operations for an affected keystore if unable to upgrade the IBM SDK.
    What if I receive a PKCS12 keystore with the stronger algorithms (possibly from a Certificate Authority) on the older IBM SDK?
    The keystore you received must be converted to the weaker algorithms before they can be used with an older IBM SDK.
    What if my java.security file is updated with a new IBM SDK service release?
    Upgrades to the IBM SDK can replace the java.security file, and stores a backup of the previous version.  If you rely on the legacy settings configured in there, you can readd those settings manually after the upgrade.
    I need to run managesdk to change the SDK version to the 1.8_64_bundled, but it failed with "Private key not stored as PKCS#8 EncryptedPrivateKeyInfoObjectIdentifier() - data isn't an object ID (tag = 48)".
    As part of the solutions outlined in this document, upgrading the SDK to the latest version resolves the issue, but if you have multiple SDKs installed on WebSphere Application Server 8.5.5, you might need to run the following:
    managesdk -enableProfileAll -sdkName 1.8_64_bundled
    The quickest way to resolve this is to disable administrative security temporally, and then run the managesdk command.
    Can you convert a keystore to use the stronger algorithms?
    If you would like to convert an entire keystore to use the stronger algorithms, on IBM SDK 8.0.8.0 or later run the following command:
    keytool -importkeystore -srckeystore sourcekey.p12 \
            -destkeystore newkeystore.p12 -srcstoretype PKCS12 \
            -deststoretype PKCS12
    NOTE: If the destination keystore doesn't currently exist, keytool attempts to create the keystore for you... but cannot create a keystore with a password shorter than 6 characters.
    On IBM SDK 8.0.7.15 (and other versions up to IBM SDK 8.0.8.0), how do I enable the weaker algorithms?
    In the java.security file, you can enable the following properties to accomplish the same as the keystore.pkcs12.legacy setting:
    keystore.pkcs12.certProtectionAlgorithm=PBEWithSHAAnd40BitRC2
    keystore.pkcs12.certPbeIterationCount=50000
    keystore.pkcs12.keyProtectionAlgorithm=PBEWithSHAAnd3KeyTripleDES
    keystore.pkcs12.keyPbeIterationCount=50000
    The properties can be set as JVM arguments too. In the following keytool example, if you were to convert a keystore to use the older algorithms you'd do the following:
    keytool -importkeystore -srckeystore sourcekey.p12 \
            -destkeystore newkeystore.p12 -srcstoretype PKCS12 \
            -deststoretype PKCS12 \
            -J-Dkeystore.pkcs12.certProtectionAlgorithm=PBEWithSHAAnd40BitRC2 \
            -J-Dkeystore.pkcs12.certPbeIterationCount=50000 \
            -J-Dkeystore.pkcs12.keyProtectionAlgorithm=PBEWithSHAAnd3KeyTripleDES \
            -J-Dkeystore.pkcs12.keyPbeIterationCount=50000
     
Table of Available Keystore Actions
Older SDKs are only able to open keystores that use the weaker algorithms, while the newer SDKs can open keystores that use either set of algorithms.
NOTE: While not represented in the table, IBM SDK 8.0.7.15 and later also use the stronger algorithms, but was fully implemented in IBM SDK 8.0.8.0.
Open Keystore
Create Keystore
Import / Export / Add Certificates
Certificate Renewal
IBM SDK 8.0.7.10 (and earlier)
Weaker Algorithms
 Stronger PBES2/AES Algorithms
IBM SDK 8.0.8.0 (and later) & IBM Semeru Runtime 11.0.12.0
Weaker Algorithms
Certificates are stored with stronger algorithms
Stronger PBES2/AES Algorithms

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB67","label":"IT Automation \u0026 App Modernization"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"ARM Category":[{"code":"a8m50000000CdL1AAK","label":"WebSphere Application Server traditional-All Platforms-\u003ESecurity-\u003ESSL-\u003ESSL - Certificates"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"},{"Type":"MASTER","Line of Business":{"code":"LOB67","label":"IT Automation \u0026 App Modernization"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSD28V","label":"WebSphere Application Server Liberty Core"},"ARM Category":[{"code":"a8m3p000000F7yQAAS","label":"IBM WebSphere Liberty-All Platforms-\u003ELiberty Security-\u003ELiberty - SSL"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"},{"Type":"MASTER","Line of Business":{"code":"LOB67","label":"IT Automation \u0026 App Modernization"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSAW57","label":"WebSphere Application Server Network Deployment"},"ARM Category":[{"code":"a8m50000000CdL1AAK","label":"WebSphere Application Server traditional-All Platforms-\u003ESecurity-\u003ESSL-\u003ESSL - Certificates"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
13 June 2024

UID

ibm16966722