Dear Reader,
During a recent migration of a Solution Manager (SolMan) Java system, I encountered a challenging issue that may be helpful for others performing similar migrations. This post summarizes the symptoms, root cause, analysis, and key recommendations to avoid the same pitfalls.
Issue Overview
The migration was planned using the backup/restore method. After restoring the system from the source backup, the following error occurred when attempting to update the UMEBackend connection in the Config Tool:
———————————————————————————————————————————————————
com.sap.security.core.server.secstorefs.InvalidStateException: Internal error during the decryption process.
Caused by: javax.crypto.BadPaddingException: Invalid PKCS#5 padding length: 115
———————————————————————————————————————————————————
Initial troubleshooting steps included:
Copying the security folder, bootstrap directory, and Config Tool from source to targetPerforming a Homogeneous System Copy using SWPMChanging the keyphrase
However, none of these attempts resolved the issue.
Root Cause Identified
The underlying issue was eventually traced to a SAPJVM version mismatch between the source and target systems:
Source: SAPJVM 8.1.096Target: SAPJVM 8.1.063
Once the target SAPJVM was updated to match the source version, the PAS (Primary Application Server) started successfully.
However, the additional application server continued to fail with the following error in the Config Tool:
————————————————————————————————————–
software version 7.00.000.001 is incompatible with file version 7.50.000.005
————————————————————————————————————–
Deeper Analysis & Final Resolution
A detailed comparison of the encryption algorithms revealed a mismatch in the Secure Store (Secstore.key) configuration of source and target:
————————————————–
Source: 7.00.000.001 | 3DESÂ
Target: 7.50.000.005 | AES256
————————————————–
Attempts to regenerate the secstore.properties and secstore.key files using SAP Note 2126229 did not resolve the issue.
The breakthrough came from SAP Note 3153525 , which explains changes in SecureStoreFS encryption algorithms. After adjusting the encryption algorithm accordingly, the additional application server started successfully.
Key Recommendations for Future Java Migrations
To prevent similar issues, I highly recommend performing the following pre-checks during Java system migrations:
1. Validate SAPJVM Versions
     Ensure that the SAPJVM version on the target system is equal to or newer than the source.
     A mismatch can cause secure store decryption failures.
2. Verify Secure Store Encryption Algorithm Consistency
     Compare the secstore.key files from both systems:
     Path: /usr/sap/<SID>/SYS/global/security/data/Secstore.key
    a. Check the version prefix before the | separator:
7.50.000.005 → AES2567.50.000.004 → AES1287.00.000.001 → 3DES
    b. Both systems must use compatible encryption algorithms.
      If they differ, consider re-encryption of secure store or upgrading the system as needed.
Thanks for reading! Feel free to drop comments or questions.
Â
​ Dear Reader,During a recent migration of a Solution Manager (SolMan) Java system, I encountered a challenging issue that may be helpful for others performing similar migrations. This post summarizes the symptoms, root cause, analysis, and key recommendations to avoid the same pitfalls.Issue OverviewThe migration was planned using the backup/restore method. After restoring the system from the source backup, the following error occurred when attempting to update the UMEBackend connection in the Config Tool:———————————————————————————————————————————————————com.sap.security.core.server.secstorefs.InvalidStateException: Internal error during the decryption process.Caused by: javax.crypto.BadPaddingException: Invalid PKCS#5 padding length: 115———————————————————————————————————————————————————Initial troubleshooting steps included:Copying the security folder, bootstrap directory, and Config Tool from source to targetPerforming a Homogeneous System Copy using SWPMChanging the keyphraseHowever, none of these attempts resolved the issue.Root Cause IdentifiedThe underlying issue was eventually traced to a SAPJVM version mismatch between the source and target systems:Source: SAPJVM 8.1.096Target: SAPJVM 8.1.063Once the target SAPJVM was updated to match the source version, the PAS (Primary Application Server) started successfully.However, the additional application server continued to fail with the following error in the Config Tool:————————————————————————————————————–software version 7.00.000.001 is incompatible with file version 7.50.000.005————————————————————————————————————–Deeper Analysis & Final ResolutionA detailed comparison of the encryption algorithms revealed a mismatch in the Secure Store (Secstore.key) configuration of source and target:————————————————–Source: 7.00.000.001 | 3DES Target: 7.50.000.005 | AES256————————————————–Attempts to regenerate the secstore.properties and secstore.key files using SAP Note 2126229 did not resolve the issue.The breakthrough came from SAP Note 3153525 , which explains changes in SecureStoreFS encryption algorithms. After adjusting the encryption algorithm accordingly, the additional application server started successfully.Key Recommendations for Future Java MigrationsTo prevent similar issues, I highly recommend performing the following pre-checks during Java system migrations:1. Validate SAPJVM Versions     Ensure that the SAPJVM version on the target system is equal to or newer than the source.     A mismatch can cause secure store decryption failures.2. Verify Secure Store Encryption Algorithm Consistency     Compare the secstore.key files from both systems:     Path: /usr/sap/<SID>/SYS/global/security/data/Secstore.key    a. Check the version prefix before the | separator:7.50.000.005 → AES2567.50.000.004 → AES1287.00.000.001 → 3DES    b. Both systems must use compatible encryption algorithms.      If they differ, consider re-encryption of secure store or upgrading the system as needed.Thanks for reading! Feel free to drop comments or questions.   Read More Technology Blog Posts by SAP articlesÂ
#SAP
#SAPTechnologyblog
