Comment: 24.R1 updated the requirements/information across the article.
Remember to update to the correct version when it is time to publish externally.
This article includes updates for Smart ID Identity Manager 24.R1.
Bootstrapping requirements
The sign and encrypt engine must be bootstrapped before using it. This procedure encompasses the engine’s initial configuration and must be done before Identity Manager is used. Bootstrapping is different for development or test systems and for production systems. For development or test systems, there are tools that perform the bootstrapping. production systems must be bootstrapped manually because of security considerations.
Important information
Most descriptors need to have their certificates and keys bootstrapped before starting the application(s) for the first time. Whenever object history entries or secrets were created with the demo keys, a simple bootstrapping is no longer possible without resigning the object history, by using the batch_re-sign_history tool, and re-encrypting the secrets, by using the batch_secretfieldstore_change_encryption_key tool, see Change encryption key of secret field store.
Significant changes for Identity Manager 24.R1
PKCS#12 files containing demo keys are no longer included to avoid them ending up in production environments.
Various checks are introduced. For more informatio, see Sign and Encrypt engine bootstrap verification:
The old demo keys are explicitly blacklisted and Identity Manager will print an error log message, if any of those is encountered on startup of Identity Manager Operator and Identity Manager Admin.
Identity Manager Admin and Identity Manager Operator will no longer start without bootstrapping, as most descriptors have missing keys/certs by default.
Identity Manager Admin and Identity Manager Operator check on startup whether the configured key for encrypted fields matches the database and will abort if that is not the case.
Identity Manager Operator checks on startup if the currently configured key for history signing matches the database and will abort if that is not the case.
Bootstrap CA/certificate/key generation tooling has been refined, it now works properly on Docker and is limited to development or test use (see Bootstrapping development and test systems).
For production environments manual bootstrapping via Certificate Authorities is required. For more information, see Bootstrapping production Systems for details.Pin scrambling of signencrypt.xml now works in Docker deployments via dedicated tooling. See Scramble sensitive data in Identity Manager files.
Each descriptor now references its own key by default, instead of for example, ZIP signing and history signing sharing the same key.