Skip to main content
Code42 Support

Configure TLS strict certificate validation

Available in:

StandardPremiumEnterprise
Small Business
Applies to:

Overview

Transport Layer Security (TLS) is an industry-standard protocol for message transport security. TLS is the default transport layer protocol for Code42 servers.

This article describes how to configure Code42 apps in a TLS environment to use the certificate that the administrator has previously configured for administration console access. Code42 apps then trust the server connection by means of the certificate provided by the Code42 server. This provides a more secure connection that defends against man-in-the-middle attacks.

About TLS

TLS supports the message application for server-to-server and client-to-server communication outside of the web-based administration console.

The TLS protocol operates over TCP and not HTTPS. By default, client-to-server communications use port 4287, and server-to-server communications use port 4288.

Considerations

  • You can configure this strict validation feature only for 6.0 endpoints.
  • TLS strict certificate validation uses the same certificate used to connect to the Code42 server administration console. By default, the Code42 server includes a self-signed SSL certificate. Instead of using this self-signed certificate, we recommend that you install a certificate signed by a recognized certificate authority (CA).
  • Maintain a backup of your certificates and renew certificates before they expire. Certificates are only valid until the date specified in the "Valid-To" field in the certificate.
  • Do not enable validation on Code42 apps until a trusted certificate is configured on all your Code42 servers.
  • Once you configure strict validation, we recommend that you do not disable it.
  • If the Code42 app does not connect due to failed validation of the Code42 server's certificate, the system logs the failed validation, the Code42 app closes the connection, and the app enters the retry routine. The most common reasons for failure are an expired certificate on the Code42 server, a certificate misconfiguration, or a lack of common trusted root certificates. If any of these occur, take appropriate steps, such as renewing your certificates.
Block port 4282 to prevent fallback
By default, failed connections from Code42 apps to the Code42 server fall back from port 4287 to port 4282. To enforce strict certificate validation to ensure that only TLS connections are made with the Code42 server, you must block port 4282 to prevent fallback.

Before you begin

Enable TLS strict certificate validation

  1. Sign in to the administration console.

  2. Double-click the logo in the upper-left corner of the administration console.
    The command-line interface appears in the administration console.
  3. At the top of the command-line interface, enter the followingprop.setcommand:

prop.set c42.sabre.server.certificate.useHttpsCertificate true save all

This causes all Code42 servers to use the same certificate for TLS messaging that was configured for HTTPS and web administration console access.

Overwriting values
Setting a new value with a prop.set command overwrites any existing value.
  1. Enter the following command to enable all Code42 apps in your Code42 environment to perform strict validation of certificates:

setting.set system c42.sabre.client.certificate.strictValidation true

  1. Use the prop.show command to verify the new settings for each property:

prop.show c42.sabre.server.certificate.useHttpsCertificate

setting.show system c42.sabre.client.certificate.strictValidation

  1.  ​​​​Restart the server and restart the Code42 apps.​

Whitelist certificates (optional)

You can enter the following command to whitelist specific certificates to allow Code42 apps to trust the Code42 servers using the certificates. This is an optional property. You can use this if Code42 apps do not trust a Code42 server for some reason and it is not feasible to correct the Code42 server certificate.

prop.set c42.sabre.server.certificate.trustedFingerprints <certificates> save all

Replace <certificates> with a comma-delimited list of certificate SHA-1 hex strings that are the hash of the X.509 certificates. You can find this value by looking at the certificate details. Following is an example of the command:

prop.set c42.pki.cert.trustedFingerprints 9D:95:6F:34:DB:A1:2D:87:A5:EA:F0:68:41:06:3E:E1:B5:A2:EB:AB,9B:95:6F:34:DB:A1:2D:87:A5:EA:F0:68:41:06:3E:E1:B5:A2:EB:AB

The certificate strings in the preceding command are for example purposes only and should not be construed as a working set of certificates in any environment.

Strict certificate validation

When a TLS client initiates a connection, the server responds with a certificate. When strict certificate validation is enabled, the TLS protocol authenticates the participants in the connection if the following are all true:

  • The current date on the client system is within the values in the certificate in terms of "Valid-From" and "Valid-To" dates.
  • The certificate is correctly digitally signed by the issuing authority:
    • Each intermediate authority is signed reaching back to a shared trusted root.
    • No certificate was tampered with along the chain.
  • The thumbprint algorithm is not a deprecated algorithm (that is, not an old MD5 certificate).
  • The signature algorithm is not a deprecated algorithm.
  • The hostname is valid:
    • The common name or one of the subject alternative names in the valid certificate matches the original string used to address the server endpoint. This method includes the use of wildcards.

External resources