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