Carbon Black EDR uses HTTPS and TLS to secure communications between endpoints and the server, and to ensure that the endpoint communications only with the Carbon Black EDR server that it trusts, and the server communications with trusted endpoints only.

When you install a new Carbon Black EDR server, the cbinit configuration program you run after installation installs a legacy certificate suitable for use with the standard “pinning” validation method.

By default, the certificate installed during cbinit is produced by the server itself. As an alternative to the default legacy certificate, you can substitute your own certificate during the server post-installation initialization process. In either case, the certificate is named “Legacy” where certificates appear in the console, and it is protected from deletion.

A server certificate for sensor communications must meet the following requirements:

  • The files must be recognized as a valid certificate and key pair by the OpenSSL library.

  • Both the certificate file and the key file must be in unencrypted ASCII PEM format.

  • The certificate must have valid dates when uploaded – that is, its "not valid before" date should be in the past and its "not valid after" date should be in the future.

  • The certificate must have two distinct SAN DNS entries to address the Carbon Black EDR cluster scenario where sensors must resolve primary and minion virtual addresses to different IP addresses or FQDNs. This is required for every server certificate, even in standalone configurations, so that the certificate remains valid if a standalone instance is upgraded to a cluster. The second SAN field is a single virtual address used for all minions, but it is mapped to a different IP address or FQDN hostname as needed by the sensor itself.

  • SAN DNS entries must meet the standards for hostname formatting. Allowed characters include the hyphen and alphanumeric characters (a to z and 0 to 9). Invalid SAN DNS entries can silently fail.

  • The CN field is not used for validation of a new certificate because it has been deprecated. Sensors perform their own local resolution of virtual names to real server addresses, so no additional DNS entries are required.

The example below shows how you can set up the SAN portion of the certificate. The first SAN.DNS entry is used for the primary node and the second for the minions.

Certificate A

CN=<something>
SAN.DNS.1=virtual-a.master
SAN.DNS.2=virtual-a.minion

When you substitute your own certificate using cbinit, Carbon Black EDR runs tests to confirm that the certificate is valid for this use. If the certificate passes the test, it is used for this server. Otherwise, the default, server-provided legacy certificate is used instead, an error message appears, and the certificate import failure is logged to /var/log/cb/cli. The cbinit process continues if the substitution fails.

The server certificate and key are copied into the server as /etc/cb/certs/cb-server.crt and /etc/cb/certs/cb-server.key , and are also stored in the Carbon Black EDR database.

Important:

Additional certificate management features are available in Carbon Black EDR, including support for adding multiple certificates after server initialization. See “Managing Certificates” in the VMware Carbon Black EDR User Guide.