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 can load. For more information on converting between certificate formats, see the following resources:

https://www.digicert.com/ssl-support/openssl-quick-reference-guide.htm

https://www.feistyduck.com/library/openssl-cookbook/online/ch-openssl.html#openssl-key-and-certificate-management

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 NuoDB Admin processes as follows:

1. Create a keystore from PEM files.

$ openssl pkcs12 -export -name nuoadmin -out nuoadmin.p12 -inkey privkey.pem -in fullchain.pem
Enter Export Password: <enter PASSWD value>
Verifying - Enter Export Password: <enter PASSWD value>

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 Example 1 - Shared Admin Key of Enabling TLS Encryption.

Note: 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 admin process cannot act as a CA for database processes.

If an admin process cannot act as a CA for database processes which it manages, database processes are passed the same certificate used by the admin process as opposed to a certificate signed by it.

In physical deployments of NuoDB, the admin process forks the database process and has access to the database process's standard input, which the admin process 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.