Who is this article for?
CrashPlan for Small Business, no.
Code42 for Enterprise, yes.
Link: Product plans and features.
This article applies to version 6.
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.
Server security requires a CA-signed certificate and the TLS protocol
Reliable security of any production web server requires an SSL certificate signed by a trusted certificate authority (CA) and enforced use of the TLS protocol (that is, HTTPS, not HTTP).
Your on-premises Code42 authority server is no exception. A Code42 server that is configured to use a signed certificate, strict TLS validation, and strict security headers protects server communications with browsers, your Code42 apps, and other servers.
- By default, your authority server uses a self-signed certificate and TLS. That provides for encrypting client-server traffic.
- Adding a CA-signed certificate provides further security by confirming your server's identity to clients. It prevents attackers from acquiring client data through counterfeit servers and encryption keys.
- Never reconfigure a production server to use HTTP, rather than TLS and HTTPS.
- Configuring Code42 servers and apps to use strict TLS validation further ensures the security of client-server connections.
- Configuring Code42 servers to use an HTTPS Strict Transport Security (HSTS) response header further prevents unencrypted browser access to administration consoles.
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.
- 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.
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
- Ensure that all Code42 servers in your Code42 environment can communicate using TLS.
- Ensure that you have installed SSL certificates for HTTPS administration console access.
Enable TLS strict certificate validation
- Double-click the logo in the upper-left corner of the administration console.
The command-line interface appears in the administration console.
- At the top of the command-line interface, enter the following
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.
Setting a new value with a
prop.setcommand overwrites any existing value.
- 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
- Use the prop.show command to verify the new settings for each property:
setting.show system c42.sabre.client.certificate.strictValidation
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
<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.