Note
Before doing any repair procedures, a backup of the IDM applications, config files and database is recommended.

Table of Contents

Error Message(s) Logged On Startup: Compromised key detected ...

...

For replacing these keys see 24.R1: Bootstrap the sign and encrypt engine in Identity Manager.

Warning

Replacing the EncryptedFields descriptor's key requires re-encryption of existing secrets via the batch_secretfieldstore_change_encryption_key tool. See 24.R1: Change Encryption key of secret field store.

Replacing the ObjectHistorySigner descriptor's key requires re-signing existing history entries via the batch_re-sign_history tool.

Replacing the ConfigZipSigner descriptor's key means any previously exported encrypted config ZIP files cannot be decrypted anymore (versioning to enable decryption with historical keys is not yet supported here).

...

Code Block

Aborting deployment! Unable to verify the last Object History entry of the chain [PRIME1]. There appears to be an error in the engineSignEncrypt configuration of the descriptor [ObjectHistorySigner (version: 2)]. The referenced key is probably wrong. Another possible explanation for this error is that the ObjectHistory entry was manipulated. Offending entry id: [4711]. Please check the engineSignEncrypt config xml and the referenced keys! If the configured key is correct, the entry might be corrupted. This can be worked around by starting a new chain.

Some potential causes:

...

The key configured for the ObjectHistorySigner descriptor in the current version (2 in the example above) is wrong, maybe you configured the wrong P12 file.
The object history got corrupted (by accident or deliberate manipulation - forensic analysis may be advisable).
A quick workaround to get the application to start again would be switching to a new chain name for idm-operator (history verification will still fail, though):

...

Tomcat deployment: set chain name in system.properties

Code Block
... etc. ... commonHistoryService.chainName=NEW_CHAIN_NAME_GOES_HERE ... etc. ...

...

Docker-deployment: set chain name in docker-compose.yml

Code Block
... etc. ... environment: ... etc. ... - 'SYSTEM_PROPERTIES={ "commonHistoryService.chainName": "NEW_CHAIN_NAME_GOES_HERE", ... etc. ...

You can solve this properly by re-signing the history entries via the batch_re-sign_history tool.

Startup Fails With Exception Message: Error accessing the sign and encrypt engine ( There's no keystore ...

...

Scenario A: Tomcat WAR deployment created without bootstrapping

See 24.R1: Create custom certificates for Tomcat installations (non-Docker) for instructions on how to create and configure the bootstrap CA and P12 files.

...

You mostly follow the steps from 24.R1: Create custom certificates for Tomcat installations (non-Docker), but with some changes, as we want to retain the previously bootstrapped P12 files.

...

Option 2: Create copies of previously shared P12 files

Follow these steps:

copy sign.p12 three times, to signJWT.p12, signJWS.p12 and signConfig.p12
copy hybridEncKeypair.p12 to encryptConfig.p12
if emailSigning.p12 is also missing, copy sign.p12 to emailSigning.p12
if deviceEncCA.p12 is also missing, copy sign.p12 to deviceEncCA.p12
set the pins for the newly created files in WEB-INF\classes\engineSignEncrypt.xml, based on the pin of the respective source file

Scenario C: Docker deployment with an outdated signencrypt.xml

An outdated docker/compose/identitymanager/config/signencrypt.xml is being used, which does not reference the bootstrapped files from the docker/compose/certs folder mounted into the container as /certs/.
Make sure you use the correct Smart ID docker config release for your IDM version, so you have a suitable signencrypt.xml file, similar to this:

...

example Docker signencrypt.xml referencing mounted P12 files

...