Previous Next JavaScript must be enabled to correctly display this content

## Guidelines for Configuring External Certificates for an Existing Default Secure Installation

Follow these steps to install external certificates in an existing secure NoSQL database installation that uses a default security configuration and a self-signed certificate:

Note:

This procedure assumes you already have a Java keystore and truststore setup. For more information see Java KeyStore Preparation.

1. Create a new security configuration that uses external certificates:

       security-> config create -root $NEW_KVROOT \
       -pwdmgr wallet -kspwd password \
       -param "client:serverIdentityAllowed=dnmatch
       (CN=myhost, OU=TeamA, O=MyCompany, L=Unknown,
       ST=California, C=US)" \
       -param "internal:serverIdentityAllowed=dnmatch
       (CN=myhost, OU=TeamA, O=MyCompany, L=Unknown,
       ST=California, C=US)" \
       -param "internal:clientIdentityAllowed=dnmatch
       (CN=myhost, OU=TeamA, O=MyCompany, L=Unknown,
       ST=California, C=US)" \
       -param "ha:serverIdentityAllowed=dnmatch
       (CN=myhost, OU=TeamA, O=MyCompany, L=Unknown,
       ST=California, C=US)" \
       -param "ha:clientIdentityAllowed=dnmatch
       (CN=myhost, OU=TeamA, O=MyCompany, L=Unknown,
       ST=California, C=US)"

   Note:

   `$NEW_KVROOT` should be a temporary directory that only holds the generated security files.

2. Replace the keystore and truststore files with your own on each server that will host a Storage Node. For example:

       copy store.keys store.trust client.trust $NEW_KVROOT/security/

3. It is easier to install an external certificate if the existing store does not needs to be kept accessible during the certificate installation. To do this, you only need to copy the entire new security configuration to each Storage Node and then restart all of the Storage Nodes.

   Note:

   Before starting the SNA, set the environment variable `MALLOC_ARENA_MAX` to `1`. Setting `MALLOC_ARENA_MAX` to `1` ensures that the memory usage is restricted to the specified heap size.

       copy -r $NEW_KVROOT/security $KVROOT
       java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar stop -root $KVROOT
       java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar start -root KVROOT&

4. If the existing store need to be kept accessible during the credential changes instead, then you should create an interim truststore and modify the security parameters having `dnmatch` field. On the configuration host, merge the truststore entries by using the `config merge-trust` command, and also import the root and intermediate certificate:

       java -Xmx64m -Xms64m \
       -jar $KVHOME/lib/kvstore.jar securityconfig \
       config merge-trust -root $KVROOT -source-root $NEW_KVROOT
       keytool -import -keystore $KVROOT/security/store.trust -file
       ca.cert.pem -alias root
       keytool -import -keystore $KVROOT/security/store.trust -file
       intermediate.cert.pem -alias intermediate
       copy $KVROOT/security/store.trust $KVROOT/security/client.trust

   Note:

   In a multiple Storage Node deployment, you need to copy the new configuration to each host's new configuration directory and run merge-trust on each host like in the example above.

5. Copy the updated client.trust file to the security directory on each host so that clients can use it to access the store.

6. To keep the store accessible during the process, change the dnmatch value in the security configuration to be a compatible one. The values specified in the various dnmatch(xxx) expressions are a regular expression, as specified by java.util.regex.Pattern. The compatible "dnmatch" value should be in the form of `old certificate DN | new certificate DN`. In this case, the `CN=NoSQL|` represents the DN of the original self-signed certificate.

       security-> config update \
       -secdir $KVROOT/security \
       -param "client:serverIdentityAllowed=dnmatch
       (CN=NoSQL|CN=myhost, OU=TeamA, O=MyCompany, L=Unknown,
       ST=California, C=US)" \
       -param "internal:serverIdentityAllowed=dnmatch
       (CN=NoSQL|CN=myhost, OU=TeamA, O=MyCompany, L=Unknown,
       ST=California, C=US)" \
       -param "internal:clientIdentityAllowed=dnmatch
       (CN=NoSQL|CN=myhost, OU=TeamA, O=MyCompany, L=Unknown,
       ST=California, C=US)" \
       -param "ha:serverIdentityAllowed=dnmatch
       (CN=NoSQL|CN=myhost, OU=TeamA, O=MyCompany, L=Unknown,
       ST=California, C=US)" \
       -param "ha:clientIdentityAllowed=dnmatch
       (CN=NoSQL|CN=myhost, OU=TeamA, O=MyCompany, L=Unknown,
       ST=California, C=US)"

   If clients set the login property `oracle.kv.ssl.hostnameVerifier`, change the value of the dnmatch field. For example:

       oracle.kv.ssl.trustStore=client.trust
       oracle.kv.transport=ssl
       oracle.kv.ssl.protocols=TLSv1.2
       oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL|CN\=myhost,
       OU\=TeamA, O\=MyCompany, L\=Unknown, ST\=California, C\=US)

7. Check that all Replication Nodes are online and then restart each Storage Node one by one using the following commands:

       java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar stop -root $KVROOT

       java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar start -root $KVROOT&

8. Copy the updated store.keys file to the security directory on each host. Then, check that all Replication Nodes are online and restart each Storage Node one by one using the following commands:

       java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar stop -root $KVROOT

       java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar start -root $KVROOT&

9. For all Storage Nodes, remove the obsolete certificate `mykey` in store.trust. Also, rename the new certificate `mykey_2` to `mykey` using the following command:

       keytool -delete -keystore $KVROOT/security/store.trust \
       -alias mykey

       keytool -changealias -keystore \
       $KVROOT/security/store.trust -alias mykey_2 -destalias mykey