Please use the form below to provide your feedback. Because your feedback is valuable to us, the information you submit in this form is recorded in our issue tracking system (JIRA), which is publicly available. You can track the status of your feedback using the ticket number displayed in the dialog once you submit the form.

A newer version of this documentation is available.

View Latest

Certificate Rotation

      +
      Certificates should be rotated periodically, to ensure optimal security.

      Rotating Certificates

      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.

      Node-to-Node Encryption and Certificate Rotation

      Couchbase Server supports Node-to-Node Encryption, whereby network traffic between the individual nodes of a cluster is encrypted.

      Note that prior to Couchbase Server Version 7.1, node-to-node encryption, which is managed by means of the Couchbase CLI, needed to be disabled before management of either root or intermediate certificates could be performed. This restriction is lifted in version 7.1: therefore, root and intermediate certificates can now be managed while node-to-node encryption is enabled.