Advanced Public Key Infrastructure (PKI) Certificate Scenarios

On this page

This document discusses the use of advanced Public Key Infrastructure (PKI) systems and certificates issued by them with CockroachDB. security certificates with CockroachDB. PKI certificates are used in CockroachDB for TLS encryption and for node and client authentication.

Accessing the DB Console for a secure cluster

On accessing the DB Console for a secure cluster, your web browser will consider the CockroachDB-issued certificate invalid, because the browser hasn't been configured to trust the CA that issued the certificate.

For secure clusters, you can avoid getting the warning message by using a certificate issued by a public CA whose certificates are trusted by browsers, in addition to the CockroachDB-created certificates.

1. Request a certificate from a public CA (for example, Let's Encrypt). The certificate must have the IP addresses and DNS names used to reach the DB Console listed in the Subject Alternative Name field.
2. Rename the certificate and key files to ui.crt and ui.key.
3. Add the ui.crt and ui.key files to the trust store. ui.key must meet the permission requirements check on macOS, Linux, and other UNIX-like systems. If your cluster is deployed using containers, update the containers to include the new certificate and key.
4. The cockroach process reads certificates only when the process starts.

• In a manually-deployed cluster, load the ui.crt certificate without restarting the node by issuing a SIGHUP signal to the cockroach process:

    pkill -SIGHUP -x cockroach
  

  The SIGHUP signal must be sent by the same user running the process or by a user with adequate privileges to send signals to processes owned by another user, such as a user with sudo access.

• In a cluster deployed using the Kubernetes Operator, there is no way to send a SIGHUP signal to the individual cockroach process on each cluster node. Instead, perform a rolling restart of the cluster's pods.

Node key and certificates

A node must have the following files with file names as specified in the table:

Client key and certificates

A client must have the following files with file names as specified in the table:

Split node certificates

The node certificate discussed in the cockroach cert command documentation is multifunctional, which means the same certificate is presented for the node's incoming connections (from SQL and DB Console clients, and from other CockroachDB nodes) and for outgoing connections to other CockroachDB nodes. To make the certificate multi-functional, the node.crt created using the cockroach cert command has CN=node and the list of IP addresses and DNS names listed in Subject Alternative Name field. This works if you are also using the CockroachDB CA created using the cockroach cert command. However, if you need to use an external public CA or your own organizational CA, the CA policy might not allow it to sign a server certificate containing a CN that is not an IP address or domain name.

To get around this issue, you can split the node key and certificate into two:

• node.crt and node.key: node.crt is used as the server certificate when a node receives incoming connections from clients and other nodes. All IP addresses and DNS names for the node must be listed in the Subject Alternative Name field.
• client.node.crt and client.node.key: client.node.crt is used as the client certificate when making connections to other nodes. client.node.crt must have CN=node.

Node key and certificates

A node must have the following files with file names as specified in the table:

Optionally, if you have a certificate issued by a public CA to securely access the DB Console, you need to place the certificate and key (ui.crt and ui.key respectively) in the directory specified by the --certs-dir flag.

Client key and certificates

A client must have the following files with file names as specified in the table:

Split CA certificates

If you need to use separate CAs to sign node certificates and client certificates, then you need two CAs and their respective certificates and keys: ca.crt and ca-client.crt.

Node key and certificates

A node must have the following files with file names as specified in the table:

Optionally, if you have a certificate issued by a public CA to securely access the DB Console, you need to place the certificate and key (ui.crt and ui.key respectively) in the directory specified by the --certs-dir flag.

Client key and certificates

A client must have the following files with file names as specified in the table:

Certificate revocation with OCSP

CockroachDB now supports certificate revocation for custom CA certificate setups running an OCSP server.

To enable certificate revocation:

1. Ensure that your Certificate Authority sets the OCSP server address in the authorityInfoAccess field in the certificate.

2. Set the cluster setting security.ocsp.mode to lax (by default, the cluster setting is set to off).

     > SHOW CLUSTER SETTING security.ocsp.mode;
   

     security.ocsp.mode
     ----------------------
     off
     (1 row)
   
     Server Execution Time: 56µs
     Network Latency: 181µs
   

     > SET CLUSTER SETTING security.ocsp.mode = lax;
   

   For production clusters, you might want to set the setting to strict.

   Note:

   In the strict mode, all certificates are presumed to be invalid if the OCSP server is not reachable. Setting the cluster setting security.ocsp.mode to strict will lock you out of your CockroachDB database if your OCSP server goes down.

See also

• Public Key Infrastructure (PKI) and Transport Layer Security (TLS)
• Use the CockroachDB CLI to provision a development cluster.
• Manage PKI certificates for a CockroachDB deployment with HashiCorp Vault.
• Manual Deployment: Learn about starting a multi-node secure cluster and accessing it from a client.
• Start a Node: Learn more about the flags you pass when adding a node to a secure cluster
• Client Connection Parameters

Was this helpful?