NuoDB AdminAn interface for domain and database management. NuoDB Admin (nuoadmin) may be used instead of nuoagent and nuorestsvc services. When using nuoadmin, use nuocmd instead of the nuodbmgr Command Line Interface (CLI) tool. supports TLS encryption for all processes in the domain. NuoDB Admin is responsible for propagating certificates to database processes, so to enable TLS encryption for all processes, it is necessary to configure NuoDB Admin with a set of certificates, and also configure NuoDB Command (nuocmd) clients to be able to communicate with NuoDB Admin.
The following steps are necessary to configure TLS encryption:
1. Provision trusted certificates for all NuoDB Admin processes.
2. Provision key pair certificates for all NuoDB Admin processes.
3. Provision key pair certificates for all NuoDB Command clients.
Note: When TLS Encryption has been configured, you must pass the required client key and associated Client Authority (CA) certificate when running nuocmd commands. For more information on NuoDB Command and other command line tools, see Command Line Tools.
When TLS encryption has been configured, you may connect to a NuoDB database using TLS encryption. For more information, see Connecting to a database Using TLS and LDAP.
NuoDB recommends using one of the following two models in which certificates can be provisioned to enable TLS encryption.
Shared Admin Key
This trust model uses the same key pair certificate for all NuoDB Admin and NuoDB Command clients, which is then used as the trusted certificate for all processes. This model has several disadvantages, the most significant of which is the fact that the key is exposed to clients.
To avoid exposing a key to clients, it is possible to provision a separate key pair certificate for NuoDB Command clients, and include that among the set of trusted certificates for the admin processes. This allows the admin processes to communicate securely with each other (since they have the same certificate, which they all trust) and to communicate securely with NuoDB Command clients. This model still has the disadvantage of every admin process being provisioned with the same key pair certificate, which means if that a certificate has to be replaced (for example, because it has expired), then every admin process has to have its trusted certificates and key pair certificate also replaced.
Unique Admin Key
This model provisions a unique key pair certificate for each admin process, each signed by a Certificate Authority (CA) trusted by all entities (admin processes and client).
For all of the subcommands described in Using NuoDB Command to Generate TLS Keys and Certificates , the supported keystore and truststore formats are PKCS12 and JKS. These are industry-standard formats for X509 certificate data, and either of these formats can be used for a NuoDB Admin process's keystore, which contains its key pair certificate, and truststore, which contains the set of certificates trusted by the admin process.
To specify values for keystore and truststore properties, update nuoadmin.conf. For more information on nuoadmin.conf, see Configuration Files.
NuoDB Command uses PEM-encoded keys and certificates as described in RFC7468. The PEM file containing the client's key and certificate is specified using either the --client-key argument or the NUOCMD_CLIENT_KEY environment variable. This is analogous to the keystore for an admin process. The PEM file used to verify the certificate presented by the admin process (--api-server) is specified using the --verify-server argument or the NUOCMD_VERIFY_SERVER environment variable. This is analogous to the truststore for an admin process.
You may create your own key pair certificates using methods approved by your IT department. Alternatively, you may use NuoDB Command to create and install TLS authentication keys. The NuoDB Command key and certificate creation commands use the keytool utility from the Java SE Runtime Environment (a requirement for running NuoDB). For more information on the keytool utility, see https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html.
The following table describes NuoDB Command subcommands required for generating key pairs and certificates are described in the following table:
|
Subcommand |
Description |
|---|---|
create keypair
|
Generates a key pair and self-signed certificate, which is stored in a keystore. |
import certificate
|
Imports a certificate from a keystore into a truststore. |
sign certificate
|
Generates a signed certificate for an existing key pair using another key pair certificate. Both the subject and issuer keys and certificates are stored in keystores. |
show certificate
|
Outputs the PEM-encoded certificate and (optionally) outputs private key data for a key pair certificate. |
For more information on NuoDB Command and other command line tools, see Command Line Tools.
Note: NuoDB recommends that you review permissions for key pair certificates after you create them.
Note: The default expiry date for a key pair is one year. For information on rotating key pair certificates before their expiry, see Rotating Keypair Certificates.
create keypair OptionsThe following options are available when using the create keypair command:
|
Option |
Description |
|---|---|
--keystore
|
Specifies the keystore to store the generated key-pair into, which will be created if it does not exist. |
--store-type
|
Specifies the type of the keystore; derived from the |
--alias
|
Specifies the alias to store the key pair as; derived from the |
--store-password
|
Specifies the password for the keystore. |
--key-password
|
Specifies the password for the key-pair; defaults to --store-password value if not specified. |
--dname
|
Specifies the distinguished name of the certificate. |
--sub-altnames
|
Specifies the list of subjectAltNames for the certificate; must be prefixed by type, for example |
--resolve-san
|
Specifies whether to resolve subjectAltName using DNS, for example |
--algorithm
|
Specifies the key algorithm. RSA, DSA, or EC. The default is RSA. |
--validity
|
Specifies the validity of the certificate in days. The default is 365. |
--start-date
|
Specifies the start date of the certificate. |
--ca
|
Specifies whether the generated certificate should be used as a certificate authority. Note: The |
import certificate OptionsThe following options are available when using the create keypair command:
|
Option |
Description |
|---|---|
--keystore
|
Specifies the keystore to store the generated key-pair into, which will be created if it does not exist. |
--alias
|
Specifies the alias to store the key pair as; derived from the |
--truststore
|
Specifies the the keystore containing trusted certificates. |
--truststore-type
|
Specifies the type of the truststore; is derived from |
--truststore-password
|
Specifies the password for the truststore. |
--nuokey-cmd
|
Specifies the the path to the nuokeymgr executable (default: /opt/nuodb-3.4.2/etc/nuokeymgr). |
sign certificate OptionsThe following options are available when using the sign certificate command:
|
Option |
Description |
|---|---|
--keystore
|
Specifies the keystore to store the generated key-pair into, which will be created if it does not exist. |
--store-type
|
Specifies the type of the keystore; derived from the |
--alias
|
Specifies the alias of the certificate; is derived from |
--ca-keystore
|
Specifies the keystore containing the root CA certificate. |
--ca-store-type
|
Specifies the type of the CA keystore; is derived from |
--ca-alias
|
Specifies the alias of the CA certificate; is derived from |
--ca-store-password
|
Specifies the password for the CA keystore. |
--update
|
Updates the keystore with the signed certificate; if not specified, the certificate chain is written to standard output. |
show certificate OptionsThe following options are available when using the show certificate command:
|
Option |
Description |
|---|---|
--keystore
|
Specifies the keystore to store the generated key-pair into, which will be created if it does not exist. |
--cert-only
|
Specifies whether to export only the certificate. |
See the following topics: