Couchbase Server 7.1 introduces a range of security enhancements for TLS certificates. These are used to encrypt and decrypt data transmitted over the network and can also authenticate users.
We’re excited to introduce four enhancements:
- Multiple Certificate Authorities
- Encrypted TLS Private Keys
- Additional TLS Certificate Formats
- Cluster-wide TLS version 1.3
Multiple Certificate Authorities
Prior to Couchbase Server 7.1, a cluster could manage only one root certificate. All nodes and clients were obliged to rely on this single certificate authority (CA). This didn’t have the flexibility we wanted for our customers.
We are happy to announce that Couchbase Server 7.1.0 now allows multiple root certificates to be used in a cluster. This allows an individual node to use a CA that is also used by one or more other nodes or a CA used by no other node.
This may be used during CA certificate rotation: a new CA is uploaded, node certificates are changed one by one, and finally, the old CA is removed. This means 100% uptime while changing CA certificates.
Multiple Certificate Authorities also allow for different certificate chains, one or more for Application -> Cluster network encryption and another for client authentication.
Encrypted TLS Private Keys
TLS network encryption is performed using a pair of keys, one is a public key, and the other is a private key. As you can tell by the name, the public key is intended to be distributed as widely as possible and there isn’t any need to protect it. The private key on the other hand must be treated as a guarded secret. An attacker who gets hold of the private key can potentially impersonate users and systems or use it to decrypt network traffic that has been encrypted using the private key.
With Couchbase Server 7.1.0, we allow administrators to use an encrypted private key using PKCS #5 v2 algorithms like AES 256. This feature prevents storing the TLS private key unencrypted on the system. If an attacker could get hold of the private key, they wouldn’t be able to use it without the associated passphrase.
The Private Key Passphrase is stored internally with Couchbase Server’s Secrets Management capability. It can also be provided externally by configuring Couchbase Server to issue a REST call or executing a customer-provided script. This allows maximum flexibility for key management.
Some examples of secrets stores that can be used:
- Secrets Managers
- CyberARK
- Hashicorp Vault
- Cloud Backend
- AWS Secrets Management
- Azure Key Vault
- Infrastructure Keystores
- Kubernetes Secrets
- Docker Secrets
- Hardware Solutions
- Trusted Platform (TPM)
- Hardware Security Module (HSM)
Additional TLS Certificate Formats
Prior versions of Couchbase Server support only the Public Key Cryptography Standard #1 (PKCS #1) type certificates.
Couchbase Server 7.1.0 supports the PKCS #8 format and beta support for the PKCS #12 format. This reduces the need to convert certificates before loading them into the cluster.
The PKCS #8 is the Private-Key Information Syntax Standard used for encrypted or unencrypted private keys.
PKCS #12 is the Personal Information Exchange Syntax Standard. It is a container format containing multiple embedded objects, such as multiple certificates.
Cluster-wide TLS 1.3
Over time, security algorithms and protocols improve, becoming more secure and adding additional features to make it more difficult to intercept or tamper with communications.
TLS version 1.3 was introduced in Couchbase Server 7.0, but it was an incomplete solution, so the cluster-wide minimum TLS setting could not be set to require TLS version 1.3 as the minimum for all services.
With Couchbase Server 7.1.0, all services support TLS version 1.3 and so it can be configured as the mandatory minimum allowed level of TLS. This provides more secure ciphers, and it also allows for both faster encryption and decryption of data compared to earlier versions of TLS.
Notable TLS usage changes
In a Couchbase Server 7.1.0 cluster, we require that incoming nodes being added to a cluster have a trusted TLS certificate present before they are added. The node addition will then be performed over an encrypted connection. This will be a mandatory requirement in clusters configured to use TLS with CA-managed certs.
We also restrict the ability to change Certificate Authority settings. Only security administrators on a localhost of a node in the existing cluster can make the changes.
