# Creating a CA-Signed Certificate for the Tomcat Server

To use HTTPS to access the Web Console or Compliance Search, you must replace the self-signed certificate automatically created and installed by the Commvault software with a CA-signed certificate. To create a certificate signed by the CA (certificate authority), create a certificate and generate a Certificate Signing Request (CSR).

You must use a CA-signed certificate in the following situations:

- You are configuring SSL on the Tomcat Server for the Web Console on a CommServe computer where a Private Metrics Reporting Server is installed. If you use a self-signed certificate, data will not upload to the Private Metrics Reporting Server.

- You are configuring an ObjectStore for Salesforce. Use a CA-signed certificate for the Web Console.

- You are configuring HTTP Public Key Pinning (HPKP).

To use a CA-signed certificate, you can also use the Commvault Certificate Tool, instead of keytool.

Important

- Do not use self-signed certificates in production environments. Even though an HTTPS, SSL, or TLC connection that uses a self-signed certificate is more secure than using a plain http connection, a self-signed certificate is not secure enough for a production environment.

- Self-signed certificates cause warnings to appear in the browser indicating that it is not safe to proceed.

- The self-signed certificates have an expiration date, after which the server may become unusable until you replace the self-signed certificate with a valid CA-signed certificate.

## Before You Begin

- For the Web Console, perform this task on the Web Console computer.

- For Compliance Search, perform this task on the Compliance Search computer.

- If you need to replace an expired CA-signed certificate, back up the existing keystore and server.xml files, and then delete the existing keystore file before creating the new CA-signed certificate.

## Procedure

1. From the command prompt, go to the folder that contains the keytool.exe file:

   - For Windows systems, go to C:\Program Files\Commvault\ContentStore\jre\bin.

   - For Linux systems, go to /opt/commvault/jre/bin.

2. To create the keystore file containing the key-pair/certificate to be signed, run the following command:

   For Windows:

       keytool -genkey -alias $[tomcat] -keyalg $[RSA] -keystore "$[C:\mykeystore.jks]" -ext $[SAN=dns]:$[domainname]

   For Linux:

       keytool -genkey -alias $[tomcat] -keyalg $[RSA] -keystore "$[/opt/commvault/Apache/conf/mykeystore.jks]" -ext
       $[SAN=dns]:$[domainname]

   Optionally, you can use an IP address in the SAN using `SAN=dns:(domainname),ip:(Tomcat server IP address)` instead of `SAN=dns:(domainname)`. However, this is not recommended because if the address changes, you must obtain a new certificate and include the new IP address again.

   Note

   - This keystore file must be used throughout this procedure.

   - Depending on your browser, you might need to perform additional configurations to complete the creation of a CA-Signed Certificate. For example, for Google Chrome version 58 and later, you must specify the Subject Alternative Name (SAN), while running the keytool command.

   During the command execution, you are prompted to provide information about your organization:

3. Parameter | Description
   --- | ---
   Alias | The alias that is used by Tomcat for reference purposes while importing or installing the certificate. The alias can be any simple name used for cross reference. After certificate signing is done by the certificate authority and returned back to the customer, then you must use the same alias to import the certificate.
   Password | The keystore password. Use a strong password. Note Do not use special characters.
   First and Last name | The fully qualified domain site name, such as www.someserver.someportal.com, which has to run using HTTPS. If you want to protect several hostnames on the same domain, you must obtain a wildcard certificate and enter the site name, such as *.someportal.com. If you enter a value that does not include the starting part of the website URL for which you are requesting the certificate, then the browser might treat the website as an untrusted website. In these cases, an error message such as the following is shown: The security certificate presented by this website was issued for a different website's address. Note Always use a fully qualified hostname, for example, www.someserver.someportal.com. If you want to protect more than one host, list all the hostnames. This is useful when you have a single server that is accessed using two different names, depending on where the connection is coming from. The resulting certificate is valid for any of the hostnames.
   Organizational Unit | Optional: If applicable, you can specify the DBA (Doing Business As) name.
   Organization Name | The full legal name of your organization. The organization name must be the legal registrant of the domain name in the certificate request. If you are enrolling as an individual, enter the certificate requester’s name.
   City / Locality | The city (without abbreviation) where your organization is located.
   State / Province | The state or province (without abbreviation) where your organization is located.
   Country Code | The two letter country code (ISO, International Organization for Standardization, format) where your organization is legally registered.

4. To generate a CSR, run the following command:

       keytool -certreq -keyalg RSA -alias $[tomcat] -file $[C:\somename.csr] -keystore $[C:\mykeystore.jks] -validity $[daysValid] -ext SAN=dns:$[domainname]

   Parameter | Description
   --- | ---
   certreq | Do not remove or change this parameter.
   keyalg | Do not remove or change this parameter. Valid value is RSA.
   Alias | The same alias name used for generating the keystore.
   File | The path to the file for CSR creation.
   Keystore | The path to the keystore that was recently created. You must use the same keystore file throughout this procedure.
   validity | The number of days the keystore file is valid starting from the day the keystore file is created. Enter a value less than or equal to 397 days.

   Optionally, you can include an IP address in the SAN using `SAN=dns:(domainname),ip:(Tomcat server IP address)` instead of `SAN=dns:(domainname)`. However, this is not recommended because if the address changes, you must obtain a new certificate and include the new IP address again.

5. Upload the CSR to the CA website, indicate the type of Tomcat server, and submit for signing.

6. Download the root, intermediate, and issued server/domain certificates.

   Important

   This step might be different based on the CA. Follow the guidelines provided by your CA.

7. Import each signed certificate that is issued by the CA using the following commands:

   - Root certificate:

          keytool -import -alias $[root] -keystore $[C:mykeystore.jks] -trustcacerts -file $[C:valicert_class2_root.crt]

   - Intermediate certificate:

          keytool -import -alias $[intermed] -keystore $[C:mykeystore.jks] -trustcacerts -file $[C:gd_intermediate.crt]

   - Issued server/domain certificate:

          keytool -import -alias tomcat -keystore $[C:mykeystore.jks] -trustcacerts -file $[C:server_certificate_whatevername.crt]

     Important

     The keystore parameter must be the path to the keystore file that was used to generate the CSR. You must use the same keystore file throughout this procedure.

8. Close the command line.

## What to Do Next

Configure the SSL Connector for Tomcat.

×

Loading...