| Info |
|---|
This article includes is valid new for Smart ID Identity Manager 24.R1 or later. |
...
5.0.1. |
This article provides guidance and troubleshooting tips for addressing common error scenarios related to the sign and encrypt engine and now how to solve them.!!!!!THIS NEEDS A THOROUGH REWRITE !!!!!
| Note |
|---|
Before doing any repair procedures, creating a backup of the IDM Identity Manager applications, config configuration files, and database is recommended. |
| Table of Contents |
|---|
!!!!! old contents below !!!!!
...
Error messages on startup
Upon startup of IDM Identity Manager you might see one or more error messages like the one below:
...
...
Compromised
...
key
...
detected:
...
Descriptor
...
[SelfServiceJWTSigner
...
(version:
...
1)]
...
in
...
engineSignEncrypt
...
config
...
xml.
...
This
...
is
...
a
...
SECURITY
...
RISK
...
on
...
productive
...
systems.
...
It
...
is
...
ESSENTIAL
...
to
...
replace
...
it
...
with
...
a
...
new
...
secure
...
key.
...
This means that one or more blacklisted keys (such as publicly known demo keys (considered compromised and unfit for productive use) are still in use. Each message indicates the offending descriptor and version from the config xmlconfiguration XML.
For replacing these keys see Bootstrap information about how to replace the keys, see Bootstrapping the sign and encrypt engine in Identity Manager.
| Warningnote |
|---|
|
Startup
...
fails with exception message
Startup of IDM Identity Manager might fail with an exception message like this in the log:.
Example
| 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 Potential causes:
The key configured for the ObjectHistorySigner descriptor in the current version (version 2 in the example aboveerror message) is wrong, maybe you configured the wrong P12 file might been configured.
The object history got corrupted ( by accident or deliberate manipulation - , forensic analysis may be advisable).
A quick workaround to
...
restart the application is to
...
switch to a new chain name for idm-operator
...
:
History verification will still fail
...
after the chain name change.
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.
...
Error accessing the sign and encrypt engine
...
Startup of IDM Identity Manager might fail with an exception message like this in the log:
...
Error
...
accessing
...
the
...
sign
...
and
...
encrypt
...
engine
...
(
...
There's
...
no
...
keystore
...
at
...
classpath:hybridEncKeypair.p12)
This means that the config xml configuration XML for the sign and encrypt engine references a file that does not exist at the given location. All files referenced via the location "classpath:" usually need to be inside the WEB-INF\classes\ folder of the web application.
In IDM versions before 24.R1 that folder did contain all demo keys, which were since removed. Furthermore, the engineSignEncryptConfig.xml shipped in WAR files of 24.R1 and above references additional P12 files not used or not bootstrapped previously (by default we use a dedicated P12 file per descriptor, instead of sharing them).
So the above error can happen for example in these scenarios:
Scenario A: Tomcat WAR deployment created without bootstrapping
See Bootstrapping Development And Test Systems for instructions on how to create and configure the bootstrap CA and P12 files.
Scenario B: Tomcat WAR deployment upgraded from a bootstrapped 23.10.x or lower version
In this case most likely only sign.p12 and hybridEncKeypair.p12 were bootstrapped and you need to create the remaining files.
There are multiple options:
Option 1: Re-Bootstrap to add missing files
| Note |
|---|
This assumes you use the cacerts.zip bootstrap script, getting the respective certs and keys from a different CA is out of scope of this document. |
You mostly follow the steps from Bootstrapping Development And Test Systems , but with some changes, as we want to retain the previously bootstrapped P12 files.
| Note |
|---|
Ideally you still have the cacerts folder that was created during the previous bootstrapping, so you can re-use the same CA. Otherwise you need to create a new bootstrap CA via the createCA.sh / createCA.bat command during bootstrapping. |
Regardless of whether you created a new CA or used the old one, the most important change is this:
| Warning |
|---|
After running createP12.sh / createP12s.bat, remove the freshly generated hybridEncKeypair.p12 and sign.p12 (we will not replace those, as they were bootstrapped already and we would break history signature and secret fields otherwise). |
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
...
| language | xml |
|---|
...
For docker deployment the files have to be placed into the docker/compose/certs folder, which is mounted into /certs inside the container. These files need to be referenced as shown below (replace example.p12 with the proper filename):
| Code Block |
|---|
file:/certs/example.p12 |
For more information, see Bootstrapping the sign and encrypt engine to bootstrap any missing keys/certificates.