Comment: Potentially a new New article?
Info |
---|
This article is new for Smart ID Identity Manager 24.R1. |
...
Most descriptors, such as EncryptedFields
and ObjectHistorySigner
, always require proper bootstrapping for secure operation. However, depending Depending on the subset of Identity Manager features to be used, certain descriptors may be configured with placeholder keys and certificates, for example, SignEmailDescriptor
, if E-Mail signing in Identity Manager is not enabled.
Production systems can neither rely on any default keys that were installed with some older version nor on the development and test bootstrapping tools. Certificates must instead be requested and issued by real Certification Authorities (CA), taking care that they fulfill all requirements, and then installed prior to the first start of the system.
Bootstrapping an already used system
If Identity Manager has already been used with test certificates, the insecure certificates have probably been used. Object history entries and secrets were likely created with the demo keys and any exported configurations may have been signed and encrypted with the demo keys too. In this case, the system must be bootstrapped again as described in this article. After the bootstrapping:
...
The first step is to go through the list of all descriptors and fill out this the table for all the descriptors.
Expand | ||
---|---|---|
|
...
|
...
|
...
|
...
|
...
|
...
Key usage: In most cases this is not required but recommended. In the list of descriptors, see certificate requirements.
|
...
|
...
|
Request certificates
For all the required descriptors, generate keypairs and Certification Signing Requests (CSRs) and request the certificates or create your own. If you want to store the keys in a Hardware Security Module (HSM), which is highly recommended, use it for generating keypairs.
...
Import the certificates into your HSM and/or place any of the credentials which are stored in PKCS#12 files to the correct location:
Tomcat on Windows: C:\PATH\TO\TOMCAT\webapps\idm-[admin|operator]\WEB-INF\classes\
Tomcat on Linux: /path/to/tomcat/idm-[admin|operator]/WEB-INF/classes/
Docker on Linux: /PATH/TO/smartid/docker/compose/certs/(additionally /PATH/TO/smartid/docker/compose/cacerts/ for CA certificates that need to be trusted)
Edit the XML configuration file(s) to reference the appropriate files:
Tomcat on Windows: C:\PATH\TO\TOMCAT\webapps\idm-[admin|operator]\WEB-INF\classes\engineSignEncryptConfig.xml
Tomcat on Linux: /path/to/tomcat/idm-[admin|operator]/WEB-INF/classes/engineSignEncryptConfig.xml
Docker on Linux: /PATH/TO/smartid/docker/compose/identitymanager/config/signencrypt.xml
Each file must be referenced by the path within the container, as opposed to the path on the host. For example:file:/certs/MYFILE.p12
Import the configZipSigner certificate or its issuer into the Identity Manager truststore (place it into/PATH/TO/smartid/docker/compose/cacerts/ on docker).