TLS/SSL Encryption for Traps Components

Traps supports Transport Layer Security (TLS) versions 1.0 and 1.2 and Secure Sockets Layer (SSL) version 3.0. TLS/SSL, which is often referred to simply as SSL, enables clients to trust the identity of the server and the transmission of data and secures communication by encrypting traffic. Traps uses TLS/SSL as the communication protocol for securing traffic between the following components:

• ESM Server and Traps agents
• ESM Console and Administrative user
• ESM Console and Panorama
• ESM Console and WildFire
• ESM Server and Panorama
• ESM Server and WildFire
• BITS upload folder and Traps agents

Traps supports TLS 1.2 on Mac endpoints, and provides dual support of TLS 1.2 and 1.0 on Windows endpoints depending on the .NET library version:

• Older Windows versions (such as Windows XP), which use .NET 3.5, support TLS 1.0
• Newer Windows versions, which use .NET 4.5, support TLS 1.2

Enabling SSL for Traps components is a three step-process: First, you must request or issue a certificate for each ESM Server and ESM Console. Note that traffic between the ESM Server and WildFire does not require any additional configuration as the ESM Server encrypts traffic using the default trusted third-party certificates that comes with Windows. Next, you enable SSL encryption during the installation of the ESM Server and ESM Console. Finally, depending on the type of certificate, you deploy the certificate to your endpoints. For detailed instructions, see the following workflow:

1. Request or generate a certificate for each ESM component—server and console—with a purpose of server and client authentication. This certificate must be one that you can export with a password.
   The certificate can have a single name or a wildcard name. A single-name certificate requires the Common Name (CN) of the certificate to match the fully qualified domain name (FQDN) of the ESM component (for example, server.trapsserver.com). A wildcard-name certificate enables you to use the same certificate for multiple ESM components that share the same sub-domain (for example, *.trapsserver.com can be used for both server.trapsserver.com and console.trapsserver.com). Wildcard-name certificates are also useful in deployments that use multiple ESM Servers.

   If you use a wildcard-name certificate, it is recommended to configure the server name using the FQDN when installing the ESM software.

   Use one of the following basic approaches to obtain certificates:

   • Obtain a certificate from a trusted-party CA—The benefit of obtaining a certificate from a trusted third-party certificate authority (CA), such as GoDaddy, is that the endpoint will already trust the certificate because Windows updates and common browsers include root CA certificates from well-known CAs in their trusted root certificate stores.
   • Obtain certificates from an enterprise CA—Enterprises that have their own internal root CA can use it to issue certificates for ESM components. The benefit is that domain-joined clients probably already trust the enterprise CA. Another benefit of this method is that the private key does not leave the ESM component.
   • Generate self-signed certificates—A self-signed certificate is a certificate that is signed by the same entity whose identity it certifies. You can use IIS Manager or any other publicly available tool to generate a self-signed certificate and then deploy it to the endpoint.
2. Install the ESM software and enable SSL encryption (for full installation instructions, see Install the Endpoint Security Manager Server Software and Install the Endpoint Security Manager Console Software).
   1. During the installation of both the ESM Server and ESM Console, select the External Certificate (SSL) option and browse to the PKCS#12 or PFX file containing the certificate and private key.
      If you do not already have a PKCS#12 or PFX file, use your preferred method to generate it. For example, to do this in IIS, you can use the Export function in the MMC ConsoleCertificates snap-in. When you export the certificate and private key, it is required to set a password to protect the private key.
   2. Enter the certificate password.
      The installer binds the certificate to the selected agent-ESM communication port.

      If you install Traps on the ESM Server and ESM Console, and use either a self-signed or an enterprise CA certificate, you must also install the certificate on the server as described in the following step.
3. (Certificates issued by an enterprise CA and self-signed certificates) Install the certificate in the trusted root certificate store (CA certificates and self-signed certificates) of the computer account. Certificates issued by a trusted third-party CA are automatically trusted by the endpoint due to the chain of trust and do not require installation.
   1. Add the certificate to the endpoint using one of the following methods:
      • Copy the certificates manually.
      • Include the certificate in the master image for new endpoints.
      • Use a centralized deployment method such as an Active Directory Group Policy Object (GPO).
   2. Verify that the certificate appears in the appropriate store on the endpoint.