Certificates should be rotated periodically, to ensure optimal security.
Certificate rotation (which means the replacement of existing certificates with new ones) is needed when:
Any certificate expires.
A new CA authority is substituted for the old; thus requiring a replacement root certificate for the cluster.
New or modified constraints need to be imposed on one or more certificates.
A security breach has occurred, such that existing certificate-chains can no longer be trusted.
Certificate-rotation should be planned well before certificates expire. No root or intermediate certificate should ever be used to issue certificates with an expiration date later than that of the issuing certificate itself.
Certificate-rotation on the server-side does not require that either the cluster or any of its nodes be restarted. However, following rotation of a server-side’s root certificate and chains, all corresponding client-chains must also be rotated accordingly.
Note that when a certificate is to be rotated, a new private key should always be created, and used to generate an entirely new, replacement certificate.
Couchbase Server supports Node-to-Node Encryption, whereby network traffic between the individual nodes of a cluster is encrypted.
Node-to-node encryption, which is managed by means of the Couchbase CLI, must be disabled before the rotation of either a root or an intermediate certificate is performed.
To determine the status of node-to-node encryption, use the node-to-node-encryption command with the
If the command output shows that node-to-node encryption is enabled, disable it; using the same command, with the
Once certificate-rotation has been concluded, use the same command with the
--enable flag, to re-enable node-to-node encryption.
Note that the node certificates for a cluster can be rotated without node-to-node-encryption being disabled.