Bootstrapping of the sign and encrypt engine must be done before the system is used for the first time. Bootstrapping of productive production systems involves involve use of various certificate authorities to generate keys and issue certificates used by IDMIdentity Manager.
Most descriptors, such as EncryptedFields and ObjectHistorySigner, always require proper bootstrapping for secure operation. However, depending on the subset of IDM Identity Manager features to be used, certain descriptors may be configured with placeholder keys and certificates (e.g. , for example, SignEmailDescriptor, if E-Mail signing in IDM Identity Manager is not enabled).
Productive 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 IDM 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 documentationarticle. After the bootstrapping:
if any object history entries exist, they must be resigned
...
by using the batch_re-sign_history tool
...
.
if any secrets exist in the
...
database, they
...
must be re-encrypted
...
by using the batch_secretfieldstore_change_encryption_key tool
...
as described in Change Encryption key of secret field store
...
.
any previously exported configuration’s signature
...
will not be verifiable.
any previously encrypted exported configuration
...
will not be readable.
Bootstrapping procedure
Identify requirements
The first step is to go through the list of all descriptors, and fill out this table for all the descriptors.
setup Setup required: Is this descriptor required in your installation? Most descriptors are required. However, a few are only required if you use the feature they support. See In the list of descriptors, see use-case.
placeholderPlaceholder: Will Are you going to use a placeholder? If a descriptor is required but you don’t need its use case, use a placeholder with some dummy certificate. See In the list of descriptors, see use-case.
HSM: Where will you store the keys and/or certificates? Most keys and/or certificates can be stored in an HSM. An HSM is much more secure than a file. See storageIn the list of descriptors, see storage.
Key type / or size: Are you using RSA or ECC? What keysize? See key size? In the list of descriptors, see key requirements.
Key usage: in In most cases this is not required but recommended. See In the list of descriptors, see certificate requirements.
Validity: See In the list of descriptors, see certificate requirements.
Trusted by: who Who needs to trust the certificate. ? You may need to install the certificate or the issuer’s certificate to a machine. See In the list of descriptors, see general requirements and certificate requirements.
Issuer: Who will issue this certificate? This will depend on who needs to trust it. You can use more than one CA. Choices The choices are:
any CA, e.g. , for example, your own SmartID Certificate Manager or a public CA.
a trusted S/MIME CA. This is needed in case you want IDM Identity Manager to sign emails, otherwise clients may fail to validate the emails.
for placeholders or certificates that don’t do not require trust, you can create your own keypairs and certificates with any suitable tool you like. See 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. Note that getting
Getting certificates from a CA may take some time
...
, for example, due to manual verification steps.
...
It is recommended to plan accordingly
...
to have enough time to acquire all necessary keys and certificates before beginning the bootstrapping procedure.
Configure certificates in
...
Identity Manager
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
Note: each file needs to 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 IDM Identity Manager truststore (place it into /PATH/TO/smartid/docker/compose/cacerts/ on Docker).