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 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