Symptoms

The symptoms vary slightly depending on whether you are using AM/OpenAM for SAML2 federation or as an OAuth provider.

SAML2 federation

The following error is shown in the Federation debug log if you are using AM/OpenAM for SAML2 federation:

An error similar to the following is also seen in the container log. For example, this error is shown in the catalina.out log for Apache Tomcat™:

Java.security.unrecoverablekeyexception Failed To Decrypt Safe Contents Entry

OAuth provider

The following error is shown in the OAuth2Provider debug log if you are using AM/OpenAM as an OAuth provider:

Recent Changes

Changed the password for an AM/OpenAM keystore or truststore.

Renewed expired certificates.

Causes

Most likely there's a mismatch between the key passphrase and keystore passphrase.

This can also happen if you have a site configuration and have made changes to your certificate or passwords but not copied the files to all servers in the site.

Solution

This issue can be resolved by synchronizing the passwords using the keytool command:

1. Update .storepass or .keypass respectively with the new password to ensure they match. You should also ensure they match on all servers if you have a site configuration. For example, you can use keytool commands such as the following depending on your keystore format:
   • JCEKS format: $ keytool -storepasswd -new newpassword -keystore keystore.jceks -storetype JCEKS$ keytool -keypasswd -alias yourfqdnalias -new newpassword -keystore keystore.jceks -storetype JCEKS
   • JKS format: $ keytool -storepasswd -new newpassword -keystore keystore.jks$ keytool -keypasswd -alias yourfqdnalias -new newpassword -keystore keystore.jks
2. Restart the web application container in which AM/OpenAM runs to apply the changes.

Default keystore details - AM 5 and later; OpenAM 13.5.x

After installing AM/OpenAM, a default keystore is available in /path/to/openam/security/keystores/keystore.jceks (AM 7 and later) or /path/to/openam/openam/keystore.jceks (Pre-AM 7). The defaultpassword is changeit and is stored in /path/to/openam/security/secrets/default/.storepass (AM 7 and later) or /path/to/openam/openam/.storepass (Pre-AM 7).

This keystore contains multiple default test aliases; the exact test aliases included vary by version as shown in the documentation:

• AM 7 - Security Guide › About the Default Keystores and Secret Stores
• AM 6.5 - Setup and Maintenance Guide › JCEKS and JKS Keystore Comparison
• AM 6 - Setup and Maintenance Guide › JCEKS and JKS Keystore Comparison
• AM 5.x - Setup and Maintenance Guide › JCEKS and JKS Keystore Comparison
• OpenAM 13.5 - Administration Guide › JCEKS and JKS Keystore Comparison

See Security Guide › Configuring Secrets, Certificates, and Keys for further information.

Default keystore details - OpenAM 13

After installing OpenAM, a default keystore is available in the OpenAM configuration directory /path/to/openam/openam/keystore.jks. The defaultpassword is changeit and is stored in /path/to/openam/openam/.storepass. The only key in this keystore is for a self-signed certificate (default alias: test). The defaultpassword is also changeit and is stored in /path/to/openam/openam/.keypass

Related Training

N/A

I am supplied with a jks keystore named ABCC_client.store. When I import this keystore to cacerts and try connecting it says No such Algorithm error. PFA the stacktrace

But if I use this keystore independently i.e without adding it to cacerts it works.

Some googling led to me to http://joewlarson.com/blog/2009/03/25/java-ssl-use-the-same-password-for-keystore-and-key/ which says that password might me different for the key and the keystore.

make sure KeyStore password and The Keypassword are same .

The private key password defined in your app/config is incorrect. First try verifying the the private key password by changing to another one as follows:

The above example changes the password from password to changeit. This command will succeed if the private key password was password.

I had the same error when we imported a key into a keystore that was build using a 64bit OpenSSL Version. When we followed the same procedure to import the key into a keystore that was build using a 32 bit OpenSSL version everything went fine.

In order to not have the Cannot recover key exception, I had to apply the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files to the installation of Java that was running my application. Version 8 of those files can be found here or the latest version should be listed on this page. The download includes a file that explains how to apply the policy files.

Tags: exception, java, security, sed