You can use existing CA-signed certificates to secure connections and data by importing the certificates into the keystore, and referencing them your
boot.properties file. Use the
keytool command to import an existing certificate into the keystore.
The following process imports a CA-signed certificate into the keystore, with the alias example-com. Replace this alias with the alias of your certificate:
Stop the server if it is running.
Back up your existing
keytoolcommand to import your existing certificate into the keystore, substituting your specific information:
The name of your certificate file.
The certificate password.
The existing certificate alias.
destination keystore password
The password for the keystore.
keytool \ -importkeystore \ -srckeystore example-cert.p12 \ -srcstoretype PKCS12 \ -srcstorepass changeit \ -srcalias example-com \ -destkeystore keystore.jceks \ -deststoretype JCEKS \ -destalias openidm-localhost Importing keystore example-cert.p12 to keystore.jceks… Enter destination keystore password: changeit
The keytool command creates a trusted certificate entry with the specified alias and associates it with the imported certificate. The certificate is imported into the keystore with the alias
openidm-localhost. If you want to use a different alias, you must modify your
resolver/boot.propertiesfile to reference that alias, as shown in the following step.
The certificate entry password must be the same as the IDM keystore password. If the source certificate entry password is different from the target keystore password, use the
-destkeypassoption with the same value as the
-deststorepassoption to make the certificate password match the target keystore password. If you do not make these passwords the same, no error is generated when you import the certificate (or when you read the certificate entry in the destination keystore), but IDM will fail to start with the following exception:
java.security.UnrecoverableKeyException: Given final block not properly padded.
If you specified an alias other than
openidm-localhostfor the new certificate, change the value of
resolver/boot.propertiesfile to that alias. For example, if your new certificate alias is
example-com, change the
boot.propertiesfile as follows:
Restart the server.
When using CA-signed certificates for encryption, it is a best practice to delete all unused default certificates from the keystore and truststore using the
keytool command, as shown in the following examples:
To delete the
openidm-localhostcertificate from the keystore:
keytool \ -delete \ -alias openidm-localhost \ -keystore /path/to/openidm/security/keystore.jceks \ -storetype JCEKS \ -storepass changeit
To delete the
openidm-localhostcertificate from the truststore:
keytool \ -delete \ -alias openidm-localhost \ -keystore /path/to/openidm/security/truststore \ -storepass changeit
You can use similar commands to delete custom certificates from the keystore and truststore, specifying the certificate alias in the request.
The Java and IDM truststore files include a number of root CA certificates. Although the probability of a compromised root CA certificate is low, it is a best practice to delete unused root CA certificates.
To review the list of root CA certificates in the IDM truststore:
keytool \ -list \ -keystore /path/to/openidm/security/truststore \ -storepass changeit
On UNIX/Linux systems, you can find additional lists of root CA certificates in files named
Before making changes to Java environment keystore files, verify any Java-related
cacerts files are up-to-date and that you have a supported Java version installed.
You can delete root CA certificates with the
keytool command. For example, to remove the hypothetical
examplecomca2 certificate from the truststore:
keytool \ -delete \ -keystore /path/to/openidm/security/truststore \ -storepass changeit \ -alias examplecomca2
On Windows systems, you can manage certificates with the Microsoft Management Console (MMC) snap-in tool. For more information, see Working With Certificates.