SSO breaks after upgrading to AEM 6.5.25 on-prem: BadPaddingException on all decrypts | Community
Skip to main content
J
JibrilSa
Level 1
July 9, 2026
Question

SSO breaks after upgrading to AEM 6.5.25 on-prem: BadPaddingException on all decrypts

  • July 9, 2026
  • 1 reply
  • 13 views

SSO (SAML) breaks after an in-place upgrade to AEM 6.5.25 (CFP-25)

 

Environment: on-premise AEM Author, upgraded from 6.5.10 to 6.5.25.

Immediately after applying CFP-25, every SSO-related decrypt operation fails with:

javax.crypto.BadPaddingException: pad block corrupted

This appears to break decryption of the SAML keystore/truststore passwords and replication transport passwords. As a result, SSO fails and the CMS becomes inaccessible, except by disabling SAML authentication and using the manual login route.

 

The master key is stored in the JCR under /etc/key; it was never migrated to the filesystem bundle. The key value itself was not changed during the upgrade. I simply installed the CFP package, waited until it was complete and restarted the instance, as per the instructions. 

 

The workaround that resolved the issue (currently on test environments) was to rewrite the stored /etc/key value from the older obfuscated format to the raw value, so the newer crypto bundle could read it correctly. Since the underlying key value remained the same, existing encrypted data stayed valid, and decrypt operations started working again after a restart. I did this locally using a custom Groovy script.

 

I have not confirmed whether this is the intended or supported fix, and I have not found this behavior documented in the release notes or known issues.

 

Questions:

  1. Has anyone else seen this issue on AEM 6.5.25, CFP-25, or an earlier service pack?

  2. Did CFP-25 change how the /etc/key master key is read or encoded? If so, when did this behavior change?

  3. Is rewriting /etc/key from the older obfuscated format to the raw value the correct approach, or is the supported remediation to re-encrypt the affected passwords after the upgrade?

1 reply

A
akhil_merupula
Level 4
July 9, 2026

Hi ​@JibrilSa,

 

Your workaround is correct. CFP-25 updated the com.adobe.granite.crypto bundle, and the newer version no longer reads the obfuscated format that older AEM versions stored in /etc/key.

 

Rewriting /etc/key to the raw value is the right fix, not re-encrypting passwords. Since the underlying key didn’t change, all existing encrypted values stay valid.

 

To confirm: check the com.adobe.granite.crypto bundle version before/after in Felix console (/system/console/bundles). If the major version changed with CFP-25, that’s your root cause.

 

Recommend raising an Adobe Support ticket to get a hotfix or official confirmation, this type of crypto bundle regression should be documented in the release notes.

Terms & ConditionsAccessibility statement

Loading footer...