Using Certificates Signed by a Public Certificate Authority
Enabling TLS Encryption describes how to enable TLS using self-signed certificates and certificates signed by a private root Certificate Authority (CA). In this section, we describe how to enable TLS using certificates signed by a publicly-trusted CA, such as DigiCert or Let’s Encrypt.
The process of obtaining a signed certificate typically involves generating a key pair and a Certificate Signing Request (CSR), which is submitted to the CA. Once a signed certificate is obtained, it must be converted into a format supported by NuoDB. For details on how your organization obtains signed certificates, refer to the documentation for your chosen CA.
The following steps assume that the CA provides signed certificates in PEM format, and we will convert these into PKCS12 files (keystore and truststore) that the NuoDB Admin Process (AP) can load. For more information on converting between certificate formats, see the following resources:
To use certificates signed by a public CA, you must first set the NuoDB Admin nuoadmin.conf property value requireClientAuth to false.
If your domain is already running, then restart your NuoDB APs after making this configuration change.
"requireClientAuth": "false",| This setting will not take effect until NuoDB Admin is restarted. |
Provisioning a Certificate from a Public Certificate Authority
In a scenario where a single certificate is being obtained, the following steps demonstrate how to provision keystores and truststores under the Shared Admin Key trust model, but using a CA-signed certificate instead of a self-signed certificate for all processes.
Assuming that private key and certificate chain are stored in PEM files named privkey.pem and fullchain.pem respectively, you can create a PKCS12 keystore and truststore for APs as follows:
1. Create a keystore from PEM files.
openssl pkcs12 -export -name nuoadmin -out nuoadmin.p12 -inkey privkey.pem -in fullchain.pemYou will be asked to enter and verify a password.
2. Copy the certificate to the truststore.
nuocmd import certificate --keystore nuoadmin.p12 --store-password "$PASSWD" \
--truststore nuoadmin-truststore.p12 --truststore-password "$PASSWD"3. For the remaining steps, see steps 3 to 10 in Generating Keystores and Truststores: Shared Admin Key.
privkey.pem and fullchain.pem are the names of the key and certificate file when using Certbot to obtain a Let’s Encrypt certificate.
|
Exposing the Keystore to Database Processes
As described in Enabling TLS Encryption, admin certificates were generated using --ca, which adds the basic constraints extension of CA=true to the certificate (see RFC5280).
Publicly-trusted CAs do not provide certificates with this extension, which means that if you use certificates obtained by publicly-trusted CAs, the AP cannot act as a CA for database processes.
If an AP cannot act as a CA for database processes which it manages, database processes are passed the same certificate used by the AP as opposed to a certificate signed by it.
In physical deployments of NuoDB, the AP forks the database process and has access to the database process’s standard input, which the AP uses to securely pass the database process its own private key and certificate.
As a result, no configuration changes are necessary to support starting database processes when using admin certificates without the CA=true basic constraints extension.