The AM/OpenAM server does not start after restarting the web application container or you cannot log in to the console.
An error similar to the following is shown in the web application container log (for example, catalina.out for Tomcat) when this happens:
amUpgrade:09/10/2019 03:48:28:285 PM BST: Thread[http-nio-8180-exec-4,5,main]: TransactionId[023449de-60cf-49fd-fa18-965a4853b1b97-1] ERROR: Unable to parse product versions for comparison; Current: null war: ForgeRock Access Management 6.5.1 Build 24e379e3e1 (2019-April-05 09:02) org.forgerock.openam.upgrade.UpgradeException: Unable to parse product versions for comparison. Current: null war: ForgeRock Access Management 6.5.1 Build 24e379e3e1 (2019-April-05 09:02)
You may also see the following in the web application container log just before the "Unable to parse product versions for comparison" error:
amSetupServlet:09/10/2019 03:47:01:588 PM BST: Thread[localhost-startStop-1,5,main]: TransactionId[023449de-60cf-49fd-fa18-965a4853b1b97-0] ERROR: AMSetupServlet.checkConfigProperties java.io.IOException: Can't open boot keystore at com.sun.identity.setup.BootstrapData.readBootJson(BootstrapData.java:165) at com.sun.identity.setup.BootstrapData.<init>(BootstrapData.java:132) at com.sun.identity.setup.AMSetupServlet.checkConfigProperties(AMSetupServlet.java:332) at com.sun.identity.setup.AMSetupServlet.init(AMSetupServlet.java:215) ... Caused by: java.security.KeyStoreException: Exception trying to fetch key with alias dsameUserPwd at org.forgerock.openam.utils.AMKeyProvider.getSecret(AMKeyProvider.java:564) at com.sun.identity.setup.BootstrapData.readBootJson(BootstrapData.java:162) ... 19 more
Restarted the web application container in which AM/OpenAM runs.
Modified the keystore.
Imported a certificate into the truststore used by AM/OpenAM.
Enabled SSL for existing AM/OpenAM installation.
AM cannot connect to the configuration store. This can happen for a number of reasons, including (but not limited to):
- Certificate files are missing, corrupt or contain out-of-date information.
- SSL is not configured properly and is failing.
- AM/OpenAM URL has not been updated in the boot.json file to reflect the scheme change from HTTP to HTTPS after enabling SSL for an existing installation.
- The configuration store is not up and running.
There are two other known causes for this error that can occur when you try to upgrade AM/OpenAM to a later version:
- The com.iplanet.am.version property is empty or corrupted; this property value is used to determine when the upgrade process should be started: AM/OpenAM (All versions) upgrade fails when com.iplanet.am.version is empty or corrupted
- The LDAP connection fails with a "No subject alternative DNS name matching" error in addition to this error as a result of stricter LDAP SSL hostname validation: LDAP connection fails with No subject alternative DNS name matching error in AM 5.1.x, 5.5.2, 6.x, 7.x and DS 5.5.1, 5.5.2, 6.x, 7.x
This issue can be resolved by restoring the connection to the configuration store as follows depending on your cause:
- Ensure all certificate files exist, are readable and not corrupt. For example, you
should ensure you have the following files in your keystore location:
keystore.jceks (or keystore.jks) .keypass .storepassYou may need to restore one or more of these files from a backup or a different server.
- Configure SSL properly. The following resources should help:
- Ensure the configuration store is up and running before you restart the web application container in which AM/OpenAM runs. If startups are scripted, you should ensure the configuration store starts first.