The CA certificate is used to sign all sensor client-side certificates for establishing a secure communication channel between the sensor and server. Therefore, regenerating these certificates is a critical task that requires careful attention to details.

For more information about cb.conf, see the Carbon Black EDR Server Configuration Guide.

To ensure a secure and smooth transition, carefully perform the following steps to regenerate the CA certificate, handle the revocation and issuance of sensor client certificates, and manage the validation process.

Procedure

  1. Stop the Carbon Black EDR enterprise or cluster before regenerating any certificates. This action prevents potential conflicts or issues during the regeneration.
  2. Use the cbssl certs utility to regenerate the CA certificate. You have two options:
    • Generate a new CA certificate by running the following command:

      /usr/share/cb/cbssl certs --regenerate client-ca

    • Use a custom certificate. To do so, provide the path to your certificate and key:

      /usr/share/cb/cbssl certs --regenerate client-ca --client-ca-cert-file <user_client-ca-crt> --client-ca-cert-key <user-client-ca_key>

      Note: If you have utilized your own CA certificate during the installation process to sign sensor client certificates, and you intend to continue using your custom CA certificate during the certificate regeneration, it is crucial to ensure that both CA certificates have distinct common names (CN) if they are signed using different signing algorithms; for example, if one certificate is signed using SHA-1 and the other is signed using SHA-256. This requirement is imposed by OpenSSL, which states that certificates in the CA bundle must possess unique CN names if the signing algorithms differ.
  3. If you have a Carbon Black EDR cluster deployment, you must synchronize the regenerated certificate across the cluster. Run the following command:
    /usr/share/cb/cbcluster sync-certs --cert client-ca
  4. After the certificate regeneration and applicable synchronization are complete, start the Carbon Black EDR enterprise or cluster.
    This step ensures that Nginx, the web server component, operates using the newly created CA bundle that contains both the new and old CA certificates. By using this updated CA bundle, Carbon Black EDR allows sensors that are using client certificates that are signed by the old CA to check into the server. After these sensors check in and receive the new client certificate, subsequent check-ins are authenticated using the new CA certificate.
  5. Revoke all existing sensor client certificates and issue fresh ones that are signed by the new CA certificate:
    /usr/share/cb/cbssl sensor_certs --revoke --group-name '*'

    After the revocation, online sensors that check in will receive new client certificates from the server.

    Some sensors might be offline before or during Step 5. After they come back online, they send a register POST request that indicates that they are registered and must establish a session for check-in. However, the server rejects these requests because the sensor client certificates have been revoked.

  6. To address the issue with offline sensors as described in Step 5, you must disable client certificate revocation validation on the standalone server or the primary node in a cluster environment. Edit the /etc/cb/cb.conf configuration file and set the EnforceClientCertRevocation parameter to False (default value is True). Restart the Carbon Black EDR services.
    Note: If the PrimaryCheckinProxy configuration is disabled, add EnforceClientCertRevocation=False to the primary node and all minion nodes. Restart the Carbon Black EDR services.
  7. After all sensors are checked-in, set EnforceClientCertRevocation=True in cb.conf. Restart the Carbon Black EDR services.