Configure Secure Connections for Client Browsers

The Cloud Service Management Console is configured to require https (http over a secure connection) for client browsers. For a secure connection to be established, a certificate must first be installed on the CSA (CSA) server.

A self-signed certificate is created and configured when CSA is installed and is configured with the fully-qualified domain name that was entered during the installation. This self-signed certificate is used when an https browser requests are issued for the Cloud Service Management Console and expires 120 days after CSA is installed.

When client browsers connect to the Cloud Service Management Console in this default configuration, the client browser will usually issue warnings that the certificate was not issued by a trusted authority. The end user can choose to continue to the web site or close the browser.

Although the self-signed certificate can be used in production, it is recommended that you replace this certificate. You can configure a trusted third-party Certificate Authority-signed or subordinate Certificate Authority-signed certificate (see Configure CSA to Use a Trusted Certificate Authority-Signed or Subordinate Certificate Authority-Signed Certificate) or configure an internal Certificate Authority-signed certificate (see Configure CSA to Use an Internal Certificate Authority-Signed Certificate). If the self-signed certificate expires before you are ready to move to production, you can replace the expired self-signed certificate by configuring a new self-signed certificate (see Configure CSA to Use a Self-Signed Certificate).

The following sections describe some common scenarios of configuring secure connections for CSA and the Marketplace Portal:

• Configure CSA to Use a Trusted Certificate Authority-Signed or Subordinate Certificate Authority-Signed Certificate
• Configure CSA to Use a Certificate Authority-Signed Certificate and a Certificate Authority-Provided Keystore
• Configure CSA to Use an Internal Certificate Authority-Signed Certificate
• Configure CSA to Use a Self-Signed Certificate

If one of these scenarios does not match your situation, follow these general guidelines:

1. Obtain a root certificate and signed certificate and/or keystore. The root certificate is used to authenticate the signed certificate. The keystore stores the signed certificate. If you are generating a self-signed certificate, the self-signed certificate is used as the root certificate. If you need to create a certificate signing request to obtain this information, look for the steps to "Create a Keystore and Self-Signed Certificate" and "Create a Certificate Signing Request" for more detailed information.
2. Import the root certificate into the JRE's truststore. Look for the step to "Import the Certificate Authority's Root Certificate" for detailed instructions about how to import the root certificate into the JRE's keystore.

3. Complete one of the following steps, based on if you have a signed certificate only, a keystore only, or if you have both a signed certificate and keystore.

   • If you have a signed certificate only, do the following:

     1. Create and import the certificate into a JKS keystore. Look for the step to "Import the Internal Certificate Authority-Signed Certificate" for more detailed information about how to create and import the certificate into a JKS keystore.

        If the signed certificate contains a chain of certificates, you must copy the root certificate and each intermediate certificate in the chain to a separate certificate file and import each certificate file into the keystore in the following order (each certificate must have a unique alias):

        • root certificate
        • intermediate or subordinate certificate(s) in hierarchical order
        • primary or end-user certificate

        Use the signed certificate as the primary certificate. You will use the alias of the primary certificate when you configure the Web server. Work with your security expert to determine if the signed certificate contains a chain of certificates and to copy each certificate to a separate file.

     2. Configure the Marketplace Portal. This step includes converting the JKS keystore into a PKCS#12 keystore used by the Marketplace Portal. Look for the step to "Configure the Marketplace Portal" for more detailed information.

   • If you have a keystore only, do the following:

     1. Determine the type of keystore you have. You must have two keystore types: JKS and PKCS#12 (CSA and the Marketplace Portal use two different types of keystores). Convert the existing keystore into the type that you need. Look for the step to "Convert the Certificate Authority-Provided Keystore" for more detailed information about how to generate both of the required keystores.
     2. Export the certificate from the keystore. You will need to provide the name and location of the certificate file when configuring the Marketplace Portal. Look for the step to "Export the Self-Signed Certificate" for more detailed information about how to export a certificate from a keystore.
     3. Configure the Marketplace Portal. You can skip the steps to convert the keystore to PKCS#12 format as you have already completed these steps. Look for the step to "Configure the Marketplace Portal" for more detailed information.

   • If you have both the signed certificate and keystore, do the following:

     1. Determine the type of keystore you have. You must have two keystore types: JKS and PKCS#12 (CSA and the Marketplace Portal use two different types of keystores). Convert the existing keystore into the type that you need. Look for the step to "Convert the Certificate Authority-Provided Keystore" for more detailed information about how to generate both of the required keystores.
     2. Configure the Marketplace Portal. You can skip the steps to convert the keystore to PKCS#12 format as you have already completed these steps. Look for the step to "Configure the Marketplace Portal" for more detailed information.
4. Configure the Web server. This step configures CSA to use the JKS keystore. Look for the step to "Configure the Web Server" for more detailed information.
5. Configure client browsers. This step is optional and tests whether or not the browser on a client system is configured to trust certificates signed by your Certificate Authority. Look for the step to "Configure Client Browsers" for more detailed information.
6. Test secure connections to the Cloud Service Management Console. Test the connection to the Cloud Service Management Console. Look for the step to "Test Secure Connections" for more detailed information.