Administer > FIPS Configuration > Configure CSA > Create a New Keystore and Truststore for Secure Communication

Create a New Keystore and Truststore for Secure Communication

To comply with FIPS 140-2, the keystore and truststore (that store the keys and certificates used and other applications) must support PKCS #12: Personal Information Exchange Syntax Standard (PKCS #12). You must create a new keystore and truststore for CSA for PKCS #12.

This section describes the process you should follow to obtain, install, and configure a certificate that supports PKCS #12 for use by CSA.

Perform the following tasks :

  1. Create the CSA server keystore that supports PKCS #12
  2. Create CSA's certificate, create a truststore that supports PKCS #12, and import certificate(s)
  3. Configure the Web server
  4. Import the Operations Orchestration certificate as a trusted certificate
  5. Import the VMware vCenter certificate as a trusted certificate
  6. Import the certificates for other applications as trusted certificates
  7. Configure client browsers (optional)

Note In the following examples, %CSA_HOME% is the directory in which CSA is installed (for example, C:\Program Files\HPE\CSA), the keytool utility is included with the JRE (you may choose to use a different utility), and a JRE has been installed for CSA in <csa_jre>.

Step 1: Create a CSA server keystore that Supports PKCS #12

Create the CSA server keystore. For example, do the following:

  1. Open a command prompt and change directories to %CSA_HOME%.

  2. Run the following command:

    "<csa_jre>\bin\keytool" -genkey -alias csa_fips -validity 365
    -keyalg rsa -keysize 2048 -storetype PKCS12
    -keystore .\jboss-as\standalone\configuration\keystore_csaID.p12

    You can use different values for -alias, -validity, -keysize and -keystore. These instructions assume that you will use the -alias and -keystore values recommended here; you will have to adjust the commands accordingly if you use different values.

  3. Enter a keystore password (referred to in this document as the CSA server keystore password).

    This password is used to control access to the keystore. This password must be the same as the password you enter for the key in task 6 of this step.

  4. When you are prompted for your first and last name, enter the fully qualified domain name of the CSA server.

  5. Follow the prompts to enter the remaining organization and location values.

  6. Enter the keystore password you supplied earlier to use as the key password.

    Although keytool allows you to enter different passwords for the keystore and the key, the two passwords must be the same to work with CSA.

Step 2: Create CSA's Certificate, Create a Truststore that Supports PKCS #12, and Import Certificate(s)

This section shows examples on how to export a self-signed certificate, create a Certificate Authority-signed certificate (optional), create the CSA server truststore that supports PKCS #12, and import the certificates into the truststore and keystore.

Select the type of certificate you will be using (self-signed or Certificate Authority-signed) and complete one of the applicable sections below.

Using a Self-Signed Certificate

Export a self-signed certificate, create the CSA server truststore that supports PKCS #12, and import the self-signed certificate into the CSA server truststore. For example:

  1. Open a command prompt and change directories to %CSA_HOME%.

  2. Export a self-signed certificate by exporting CSA's certificate:

    1. Run the following command:

      "<csa_jre>\bin\keytool" -export -alias csa_fips
      -file C:\csa_fips.crt -storetype PKCS12
      -keystore .\jboss-as\standalone\configuration\keystore_csaID.p12

    2. When you are prompted for a password, enter the CSA server keystore password used in step 1 (where you created the CSA server keystore that supports PKCS #12).

  3. Create a truststore that supports PKCS #12 and import the self-signed certificate:

    1. Run the following command:

      "<csa_jre>\bin\keytool" -importcert -alias csa_fips
      -file C:\csa_fips.crt -trustcacerts
      -keystore .\jboss-as\standalone\configuration\csa_server_truststore.p12

    2. When prompted, enter a truststore password (referred to in this document as the CSA server truststore password). You will need this password when you import the Operations Orchestration and other certificates.

    3. Enter yes when prompted to trust the certificate.

Using a Certificate Authority-Signed Certificate

Create a self-signed certificate, create a Certificate Authority-signed certificate, import the Certificate Authority-signed certificate into the CSA server keystore, create the CSA server truststore that supports PKCS #12, and import the root certificate into the CSA server truststore. For example:

  1. Open a command prompt and change directories to %CSA_HOME%.

  2. To create a Certificate Authority-signed certificate, you must create a certificate signing request and submit the certificate signing request to a Certificate Authority:

    1. From the command prompt, run the following command:

      "<csa_jre>\bin\keytool" -certreq -alias csa_fips -file C:\csacsrfips.csr
      -keystore .\jboss-as\standalone\configuration\keystore_csaID.p12

    2. When you are prompted for a password, enter the CSA server keystore password used in step 1 (where you created the CSA server keystore that supports PKCS #12).

    3. Submit the Certificate Signing Request (C:\csacsrfips.csr) to the Certified Authority following the procedure used by your organization or a third-party provider. After the submission has been processed, you will receive a Certificate Authority-signed certificate (referred to as C:\ca_signed.crt in the example below) and a root certificate (referred to as C:\ca_root.crt in the example below) for the Certificate Authority.
  3. Import the Certificate Authority-signed certificate into the CSA server keystore:

    1. Open a command prompt and change directories to %CSA_HOME%.

    2. From the command prompt, run the following command:

      "<csa_jre>\bin\keytool" -importcert -alias ca_signed -file C:\ca_signed.crt
      -keystore .\jboss-as\standalone\configuration\keystore_csaID.p12

    3. When you are prompted for a password, enter the CSA server keystore password used in step 1 (where you created the CSA server keystore that supports PKCS #12).

  4. Create a truststore that supports PKCS #12 and import the root certificate:

    1. From the command prompt, run the following command:

      "<csa_jre>\bin\keytool" -importcert -alias ca_root
      -file C:\ca_root.crt -trustcacerts
      -keystore .\jboss-as\standalone\configuration\csa_server_truststore.p12

    2. When prompted, enter a truststore password (referred to in this document as the CSA server truststore password). You will need this password when you import the Operations Orchestration and other certificates.

    3. Enter yes when prompted to trust the certificate.

Step 3: Configure the Web Server

  1. Encrypt the CSA server keystore password and datasource (database) password using the JBoss vault script. Do the following:

    1. Verify that the %JAVA_HOME% environment variable has been defined and that %JAVA_HOME% has been set to the directory in which the JRE that is used by CSA is installed (for example, C:\Program Files\HPE\CSA\openjre).

      Note Do NOT enclose the value in quotation marks, even if the path name includes a space. The vault script will fail if the JAVA_HOME variable definition contains quotation marks.

      To verify that %JAVA_HOME% has been defined, from a command prompt, type:

      echo %JAVA_HOME%

    2. Create a keystore used by vault. This vault keystore is used to store the CSA keystore password.

      Note This example saves the vault keystore and encrypted vault file in the %CSA_HOME%\jboss-as\standalone\configuration\ directory (the contents of this directory are automatically backed up during an upgrade). You may choose to store the vault keystore and encrypted vault file in any location. However, you must remember to use those locations in subsequent steps in this task and, if those locations are not automatically backed up during upgrade, to manually back up the files before upgrade.

      1. Open a command prompt.

      2. Run the following command:

        "<csa_jre>\bin\keytool" -genkey -alias vault -validity 365 -keyalg rsa
        -keysize 2048 -storetype JKS -keystore .\jboss-as\standalone\configuration\csa_vault.keystore

        where <csa_jre> is the directory in which the JRE that is used by CSA is installed.

        You can use different values for -alias, -validity, -keysize and -keystore. These instructions assume that you will use the -alias and -keystore values recommended here; you will have to adjust the commands accordingly if you use different values.

      3. Enter the vault keystore password (for example, csavault).

        This password is used to control access to the vault keystore. This password must be the same as the password you enter for the key in step e of this task.

      4. Follow the prompts to enter your first and last name, organization, and location values.

      5. Enter the key password. Click Enter to use the vault keystore password you supplied earlier (for example, csavault).

        Although keytool allows you to enter different passwords for the keystore and the key, the two passwords must be the same to work with CSA.

    3. Run the vault script. The script will generate the masked password and the values to configure in the standalone.xml file in order to use the masked password.

      1. From the command prompt, type: %CSA_HOME%\jboss-as\bin\vault

      2. Select 0 to start the interactive session.

      3. Enter the following information, when prompted, to configure the vault keystore:

        Prompt Description
        Directory to store encrypted files

        Directory in which the vault encrypted file is stored (for example, %CSA_HOME%\jboss-as\standalone\configuration).

        Verify that a vault encrypted file (VAULT.dat) does not already exist in this directory. If the file exists, select a different directory.

        Keystore URL

        The name and location of the vault keystore (for example, %CSA_HOME%\jboss-as\standalone\configuration\csa_vault.keystore).

        Keystore password (twice) The password to the vault keystore (for example, csavault).
        8 character salt A random number (for example, 12345678).
        Iteration count as a number The number of times the CSA keystore password is hashed (for example, 25).
        Keystore alias The alias used to identify the CSA keystore password in the vault keystore (for example, vault).
      4. Make a copy of the vault property block that is displayed. For example, copy:

        <vault>
           <vault-option name="KEYSTORE_URL" value="%CSA_HOME%\jboss-as\standalone\configuration\csa_vault.keystore"/>
           <vault-option name="KEYSTORE_PASSWORD" value="MASK-2PtpNyQsI1E7t"/>
           <vault-option name="KEYSTORE_ALIAS" value="vault"/>
           <vault-option name="SALT" value="12345678"/>
           <vault-option name="ITERATION_COUNT" value="25"/>
           <vault-option name="ENC_FILE_DIR" value="%CSA_HOME%\jboss-as\standalone\configuration\"/>
        </vault>

        You will need to add this content to the standalone.xml file (the exact location is described in a later step).

      5. Select 0 to store a secured attribute.
      6. Enter the following information, when prompted, to generate the vault entry to use for the CSA keystore password in the standalone.xml file:

        Prompt Description
        Secured attribute value (twice) Enter the CSA keystore password (for example, <CSA server keystore password>).
        Vault Block Enter a name for the vault block (for example, csa_keystore).
        Attribute Name Enter the attribute being stored (for example, password).

        Note the VAULT entry (for example, VAULT::csa_keystore::password::1). You will need this value when you configure the standalone.xml file.

      7. Enter 2 to exit the script.

      Note The vault script converts the format of the vault keystore (for example, %CSA_HOME%\jboss-as\standalone\configuration\csa_vault.keystore) to JCEKS.

  2. Open %CSA_HOME%\jboss-as\standalone\configuration\standalone.xml in a text editor.

  3. Locate the following entry for the CSA server keystore password (this entry may have been modified):

    <ssl>
        <keystore keystore-password="..." path="%CSA_HOME%/jboss-as/standalone/configuration/.keystore"/>
    </ssl>
  4. Update the entry by:

    • Adding or changing the value of the password to the encrypted value of the CSA server keystore password you generated in task 1 of this step.

    • Changing the value of the path to the keystore you created in step 1
      (%CSA_HOME%\jboss-as\standalone\configuration\keystore_csaID.p12)
    • Adding the attribute provider and setting its value to PKCS12

    For example:

    <ssl>   
        <keystore provider="PKCS12" path="%CSA_HOME%/jboss-as/standalone/configuration/keystore_csaID.p12" keystore-password="${VAULT::csa_keystore:password::1}"/>
    </ssl>
  5. Locate the following entry for the datasource password (this entry may have been modified):

    <datasource jndi-name="java:jboss/datasources/csaDS" pool-name="mssqlDS">
       <connection-url>jdbc:jtds:sqlserver://127.0.0.1:1433/example;ssl=request</connection-url>
       <driver>mssqlDriver</driver>
       <pool>
          <min-pool-size>10;</min-pool-size>
          <max-pool-size>200;</max-pool-size>
          <prefill>true;</prefill>
       </pool>
       <security>
          <security-domain>csa-encryption-sec;</security-domain>
       </security>
    </datasource>

  6. Replace the security-domain entry with the datasource user name and password, setting the password value to the encrypted value of the datasource password you generated in task 1 of this step. For Microsoft SQL Server, also update the connection-url ssl attribute value from request to authenticate (if it has not already been updated).

    For example:

    <datasource jndi-name="java:jboss/datasources/csaDS" pool-name="mssqlDS">
       <connection-url>
          jdbc:jtds:sqlserver://127.0.0.1:1433/example;ssl=requestauthenticate
       </connection-url>
       <driver>mssqlDriver</driver>
       <pool>
          <min-pool-size>10;</min-pool-size>
          <max-pool-size>200;</max-pool-size>
          <prefill>true;</prefill>
       </pool>
       <security>
          <security-domain>csa-encryption-sec;</security-domain>
          <user-name>datasource_username</user-name>
          <password>
             ${VAULT::csa_keystore::password::1}
          </password>
       </security>
    <datasource>

  7. Locate and delete the following entry for the datasource password (this entry may have been modified):

    <security-domain name="csa-encryption-sec" cache-type="default">
       <authentication>
          <login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
             <module-option name="username" value="<old_user_name>"/>
             <module-option name="password" value="<old_encoded_password>"/>
             <module-option name="managedConnectionFactoryName" value="jboss.jca:service=LocalTxCM,name=mssqlDS"/>
          </login-module>
       </authentication>
    </security-domain>

  8. Locate the following entry for the datasource password (this entry may have been modified):

    <datasource enabled="true" jndi-name="java:jboss/datasources/idmDS"
    jta="true" pool-name="IdMDS" use-ccm="true" use-java-context="true">
       <connection-url>jdbc:jtds:sqlserver://127.0.0.1:1433/example;ssl=request</connection-url>

      <driver>pqsqlDriver</driver>
       <pool>
          <min-pool-size>10;</min-pool-size>
          <max-pool-size>200;</max-pool-size>
          <prefill>true</prefill>
          <use-strict-min>false</use-strict-min>
          <flush-strategy>FailingConnectionOnly</flush-strategy>
       </pool>
       <security>
          <security-domain>idm-encryption-sec;</security-domain>

      </security>
    </datasource>

  9. Replace the security-domain entry with the datasource user name and password. Set the password value to the encrypted value of the datasource password you generated in task 1 of this step. For Microsoft SQL Server, also update the connection-url ssl attribute value from request to authenticate (if it has not already been updated).

    For example:

    <datasource jta="true" jndi-name="java:jboss/datasources/idmDS" pool-
    name="IdMDS" enabled="true" use-java-context="true" use-ccm="true">
       <connection-url>jdbc:jtds:sqlserver://127.0.0.1:1433/example;ssl=requestauthenticate
       </connection-url>
       <driver>mssqlDriver</driver>
       <pool>
          <min-pool-size>10</min-pool-size>
          <max-pool-size>200</max-pool-size>
          <prefill>true</prefill>
          <use-strict-min>false</use-strict-min>
          <flush-strategy>FailingConnectionOnly</flush-strategy>
       </pool>
      <security>
          <security-domain>idm-encryption-sec</security-domain>
          <user-name>datasource_username</user-name>
          <password>${VAULT::csa_keystore::password::1}</password>
       </security>
    </datasource>
  10. Locate and delete the following entry for the datasource password (this entry may have been modified):

    <security-domain cache-type="default" name="idm-encryption-sec">
    <authentication>
    <login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
    <module-option name="username" value="<old_user_name>"/>
    <module-option name="password" value="<old_encoded_password>"/>
    <module-option name="managedConnectionFactoryName" value="jboss.jca:service=LocalTxCM,name=IdMDS"/>
    </login-module>
    </authentication>
    </security-domain>
  11. In standalone.xml add new properties to system-properties section. Copy this:

    <property name="javax.net.ssl.trustStore" value="%CSA_HOME%/jboss-as/standalone/configuration/csa_server_truststore.p12"/>
    <property name="javax.net.ssl.trustStorePassword" value="${VAULT::csa_keystore::password::1}"/> <!-- vault encrypted password for csa_server_truststore.p12 -->
    <property name="javax.net.ssl.trustStoreType" value="PKCS12"/>
    <property name="jsse.enableCBCProtection" value="false"/>
    <property name="com.sun.net.ssl.enableECC" value="false"/>
  12. Add the vault property block to <server xmlns="urn:jboss:domain:1.3"> after the <systemproperties> block. For example, using the example values, enter the following:

    <server xmlns="urn:jboss:domain:1.3">
    .
    .
    .
    <system-properties>
    .
    .
    .
    </system-properties>
    <vault>
       <vault-option name="KEYSTORE_URL" value="%CSA_HOME%\jboss-
    as\standalone\configuration\csa_vault.keystore"/>
       <vault-option name="KEYSTORE_PASSWORD" value="MASK-2PtpNyQsI1E7t"/>
       <vault-option name="KEYSTORE_ALIAS" value="vault"/>
       <vault-option name="SALT" value="12345678"/>
       <vault-option name="ITERATION_COUNT" value="25"/>
       <vault-option name="ENC_FILE_DIR" value="%CSA_HOME%\jboss-
    as\standalone\configuration\"/>
    </vault>

Step 4: Import the Operations Orchestration Certificate as a Trusted Certificate

Because the integration of CSA and Operations Orchestration requires a secure connection, you must import the Operations Orchestration certificate.

For each system running CSA, import the root certificate of each Operations Orchestration's Certificate Authority (you must first export Operations Orchestration's certificate from Operations Orchestration's truststore and then import it into the CSA server truststore).

The following is an example of how to export the Operations Orchestration certificate and import it into the CSA server truststore.

  1. On the system running Operations Orchestration, open a command prompt and change the directory to %ICONCLUDE_HOME%.
  2. Run the following command:

    Operations Orchestration 10.x, Windows
    .\java\bin\keytool -exportcert -alias tomcat -file C:\oo.crt
    -keystore .\Central\var\security\key.store -storepass changeit

    Operations Orchestration 9.x, Windows
    .\jre1.6\bin\keytool -exportcert -alias pas -file C:\oo.crt
    -keystore .\Central\conf\rc_keystore -storepass bran507025

    where C:\oo.crt is an example of a filename and location used to store the exported root certificate (you can choose a different filename and location).

  3. If Operations Orchestration is not running on the same system as CSA, copy oo.crt from the Operations Orchestration system to the system running CSA (in this example, the file is copied to C:\).
  4. On the system running CSA, change the directory to %CSA_HOME% and run the following command:

    "<csa_jre>\bin\keytool" -importcert -alias pas -file C:\oo.crt
    -keystore .\jboss-as\standalone\configuration\csa_server_truststore.p12
    -storepass <CSA server truststore password>

  5. When prompted to trust the certificate, enter yes.

Step 5: Import the Provider's Certificate as a Trusted Certificate

If you configure the access point to Matrix OE, Server Automation, VMware vCenter, or any provider in the Cloud Service Management Console to use a secure connection, you must import the provider's certificate into the truststore.

For each system running CSA, import the root certificate of the provider's Certificate Authority into the truststore (you must first export the provider's certificate from the provider's truststore and then import it into the CSA server truststore).

The following is an example of how to import the VMware vCenter certificate into the CSA server truststore:

  1. Obtain the root certificate of VMware vCenter's Certificate Authority and copy it to the system running CSA (in this example, the file is copied to C:\vcenter.crt).
  2. On the system running CSA, change the directory to %CSA_HOME% and run the following command:

    "<csa_jre>\bin\keytool" -importcert -alias vcenter -file C:\vcenter.crt
    -keystore .\jboss-as\standalone\configuration\csa_server_truststore.p12
    -storepass <CSA server truststore password>

  3. When prompted to trust the certificate, enter yes.

Step 6: Import the Certificates for other Applications as Trusted Certificates

If other applications, such as the database, LDAP, SMTP, Operations Orchestration Load Balancer, or Continuous Delivery Automation require a secure connection, you must import the other applications' certificates into the CSA server truststore.

The following is an example of how to import another application's certificate into the CSA server truststore.

  1. Export the certificate for the application and copy the certificate file to the system running CSA.
  2. Import this certificate into the CSA server truststore.

    For example, run the following command on the system running CSA:

    "<csa_jre>\bin\keytool" -importcert -alias <alias>
    -file <filename.crt> -trustcacerts -keystore
    "%CSA_HOME%\jboss-as\standalone\configuration\csa_server_truststore.p12"
    -storepass <CSA server truststore password>

Step 7: Configure Client Browsers (Optional)

If CSA's certificate is not signed by a Certificate Authority, when accessing the Cloud Service Management Console, warning messages are displayed in the browser (these messages do not affect normal operations of CSA). To avoid these warning messages, import the csa_fips.crt file or add an exception.

  • Microsoft Internet Explorer and Chrome: From Windows Explorer, double-click on the
    csa_fips.crt file to begin the import process. Install the certificate in the Trusted Root Certification Authorities store. For information on how to import the certificate, refer to the browser's online documentation.
  • Firefox: Add an exception by opening the browser and navigating to https://<csahostname>:8444/csa where <csahostname> is the fully-qualified domain name of the system on which CSA is running. When the This Connection is Untrusted page opens, select I Understand the Risks, click the Add Exception button, verify the Server Location, and click Confirm Security Exception. For information on how to import the certificate, see the browser's online documentation.