Whether added during server installation or later through the console, server certificates that are used for sensor communications must meet the following requirements.

  • The files you provide must be valid certificate and key files (that is, they must be recognized as a certificate/key pair by the OpenSSL library).
  • Certificate files must be in unencrypted ASCII PEM format – this includes both the certificate file and the key file.
  • 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.
  • Certificates 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 certificates remain 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, but should not match any of the existing accessible DNS addresses. It should contain a unique element (for example, virtual_a prefix) that allows the server to support multiple different certificates behind the same DNS hostname. Allowed characters include the hyphen and alphanumeric characters (a to z and 0 to 9). Invalid SAN DNS entries can silently fail and might cause connectivity loss to the server.
  • The CN field is not used for validation of new certificates 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.
  • When generating replacement custom certificates, the SANs must once again be unique and non-routable. They must be unique not only amongst themselves, but also unique to the certificates they are replacing. As the Carbon Black EDR server compares old and new certificates for veracity, it ensures old SANs are not honored when the new certificate is deployed. To do this, the old SANs cannot be reused.
  • Applicable for EL 8 environments only: FIPS-compliant OpenSSL on EL 8 enforces stricter certificate validations.
    • Purpose of the Certificates: Certificates should state usage via Key Usage x509 extensions.
    • Certificate Signing Algorithms: Must be one of the following: SHA-256 (Secure Hash Algorithm 256-bit), SHA-384 (Secure Hash Algorithm 384-bit), or SHA-512 (Secure Hash Algorithm 512-bit).
    • Certificate Asymmetric Encryption Algorithm: RSA with a minimum key size of 2048 bits.

The following example shows how to set up the SAN portion of the certificate if you want to upload two certificates. The first SAN.DNS entry is used for the primary cluster node and the second is used for the minions.

Certificate A

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

Certificate B

   CN=<something>
   SAN.DNS.1=virtual-b.primary
   SAN.DNS.2=virtual-b.minion