Skip to main content

Who is this article for?

Incydr
Code42 for Enterprise
CrashPlan for Enterprise
CrashPlan for Small Business

Incydr, no.

CrashPlan for Enterprise, yes.

Code42 for Enterprise, yes.

CrashPlan for Small Business, no.

This article applies to on-premises authority servers.

HOME
GETTING STARTED
RELEASE NOTES
FAQS
SYSTEM STATUS
Code42 Support

Replace your single sign-on certificate

Who is this article for?

Incydr
Code42 for Enterprise
CrashPlan for Enterprise
CrashPlan for Small Business

Incydr, no.

CrashPlan for Enterprise, yes.

Code42 for Enterprise, yes.

CrashPlan for Small Business, no.

This article applies to on-premises authority servers.

Overview

By default, your Code42 environment uses a self-signed X.509 public key certificate for communication with a single-sign on (SSO) identity provider (IdP). However, some customers may need to replace the self-signed certificate due to a security policy, a certificate issue, or the requirements of an identity provider. This article describes how to replace the default SSO certificate with either a new self-signed certificate or a certificate signed by a certificate authority (CA).

This SSO certificate is generated, stored, and used separately from the Code42 server's SSL certificate. For information on replacing your Code42 server's main SSL certificate, rather than the certificate used for SSO, see Install a CA-signed SSL certificate with the Java keytool.

Considerations

  • This process requires the use of the Code42 API to generate a new self-signed certificate or to upload a CA-signed certificate.
  • Because Code42 is not a certificate authority, we cannot provide CA-signed certificates.

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 Code42 consoles.

Before you begin

  • If you need to install a CA-signed certificate, you must already have a copy of the certificate as provided by your certificate authority.
  • You must use an account with the SYSADMIN user role to replace the SSO certificate.

Step 1: Provide a new certificate

On your authority server, you must either generate a new self-signed certificate or upload a CA-signed certificate.

Option 1: Generate a new certificate with the Code42 API

You can create a new self-signed certificate using the Code42 API's KeystoreFile resource.

The example below uses the curl utility to call the KeystoreFile resource with the necessary method and query parameters, and displays the data returned by the API call in JSON format. Replace the example domain name https://authority-server.example.com:4285 with the domain name or IP address of your actual authority server, and the sample username and password with your actual username and password:

$ curl -sku 'username:password' -X POST https://master-server.example.com:4285/api/KeystoreFile?doGenerate=true&updateSettings=false

The command returns the following data in JSON format:

$ {"data":{"success":true,"keystoreId":"5"},"metadata":{"timestamp":"2014-12-05T14:29:42.055-06:00","params":{"doGenerate":"true"}}}

Record the keystoreId value for the next step. In this example, that value is "5."

Option 2: Upload a CA-signed certificate

If you need to use a CA-signed certificate, then you can upload the certificate in JKS format.

The example below uses the curl utility to call the KeystoreFile resource with the necessary method and query parameters, and displays the data returned by the API call in JSON format. Replace the example domain name https://authority-server.example.com:4285 with the domain name or IP address of your actual master server, and the sample username and password with your actual username and password. In this example, the CA-signed certificate is named keystore.jks, and is located in the directory from which the curl command is run:

curl -sku 'username:password' -X POST -F "afile=@keystore.jks" -F "apassword=password" https://master-server.example.com:4285/api/KeystoreFile?updateSettings=false 

The command returns the following data in JSON format:

{"data":{"success":true,"keystoreId":"7"},"metadata":{"timestamp":"2014-12-05T14:48:21.448-06:00","params":{"afile":"keystore.jks","apassword":"[B@65c31da6","updateSettings":"false"}}}

Record the keystoreId value for the next step. In this example, that value is "7."

Step 2: Switch to new certificate

Instruct the authority server to use the new certificate for SSO by using the Code42 API's SsoAuthSpMetadata resource and the keystoreId value from the previous step.

The example below uses the curl utility to call the SsoAuthSpMetadata resource with the necessary method and query parameters. Replace the example domain name https://authority-server.example.com:4285 with the domain name or IP address of your actual authority server, and the sample username and password with your actual username and password.

curl -sku 'username:password' -X PUT -H "Content-Type:application/json" -d '{"ssoKeystoreId":"4"}' https://master-server.example.com:4285/api/SsoAuthSpMetadata

If there is no response, then the command worked.

Step 3: Confirm success

Optionally, you can confirm the success of the command in the authority server's logs. Search com_backup42_app.log for the text SSO service keystore updated to use keystoreId using either your Code42 console's log viewer or a utility on your Code42 server such as grep.

Example log entry:

[12.05.14 15:21:52.591 INFO    jetty-web-7582       com.backup42.history.CpcHistoryLogger   ] HISTORY:: Subject[1/username, orgId:1] SSO service keystore updated to use keystoreId=5
  • Was this article helpful?