Overview

With BBj 13.13 through BBj 19.00, you can configure your BBj application web server to install a Certificate Authority (CA) security certificate during installation. This CA security certificate allows Java Web Start clients to run under Oracle’s security model. BBj offers two different options for configuring the certificate (see Figure 1 for an example of what this dialog box can look like): Generate a Certificate and Use an Existing Certificate.

Figure 1. Configure Web Start

The information below explains the trade-offs involved in choosing between these two options, and gives some benefits for each option.

Generate a Certificate

The option to “generate a certificate” only requires that you configure your company name, your server’s name or IP address, and the port for BBj Services on that server.

At run time, Java Web Start clients who connect for the first time must accept three warning dialog boxes (see Figures 2, 3, and 4 for examples of these dialog boxes).

Figure 2. Run the application to install the Certificate Authority installer

Figure 3. Install the Certificate Authority

Figure 4. Run the Web Start application using a generated certificate 

Clicking [Yes] on the second dialog box and marking the “Do not show this again…” checkbox on the first and third dialog boxes will prevent most clients from seeing those warning dialog boxes again.

One benefit of generating a code signing certificate is that, at run time, Java Web Start clients do not need to be connected to an Internet connection so that they can reach a trusted certificate authority organization.

One drawback of configuring your servers to generate a code signing certificate is that if you have multiple servers, each server will by default install and serve a unique certificate. Thus, even after a Web Start client has accepted a certificate from one of your servers, he will see the acceptance dialog windows again the first time he connects to any other server. This happens because the client computer has not yet trusted the second server’s certificate. This problem can be addressed by a variety of solutions, including sharing BBj’s cfg directory between the servers or copying one set of keystore files to all of your servers.

Be aware that in both of these cases, if you install using individual server machine names, all of the servers can serve the same certificate but only one server will serve the Certificate Revocation List (CRL). This happens because the web URL for the CRL is in the certificate/keystore that you copied. During any time when the CRL server is unavailable for any reason, Web Start clients would see a warning dialog indicating that the trusted certificate could not be validated, which they can acknowledge and continue to run.

Sharing a cfg Directory Across Servers

If your servers share a cfg directory, then all of the servers will serve the same certificate and the first server on which BBj was installed will serve the CRL. This happens because each subsequent installation preserves the previous installation’s cfg directory keystore.

Copying cfg Directory Files Across Servers

Once you have installed with the “generate a certificate” option on all of your servers, follow these steps if you wish to copy the generated certificate/keystore files from one server to another:

1. Identify the BBj server from which you will copy the certificate. In the <BBj installation directory>/cfg directory, identify the three certificate-related files named install.jks, install-ca.jks, and install.crl.

2. Shut down BBj Services on each of the other servers (if running).

3. Copy the install.jks, install-ca.jks, and install.crl files from the source server to the <BBj installation directory>/cfg directory on each of the other servers, overwriting the existing files.

4. Restart BBj Services on each of the other servers.
   

If you installed with individual server machine names and manually copied the keystore files, the server from which you copied the files will now serve the CRL.

Use an Existing Certificate

The option to “use an existing certificate” requires that you purchase a code signing certificate from a trusted certificate authority organization (TCAO), place the certificate in a keystore, and enter the location of the keystore along with its security keys during installation.

The code signing certificate must be purchased from a TCAO and meet the following requirements:

• The certificate must be a code signing certificate. A website certificate will not work for jar file signing.

• The certificate must support Java jar file signing. We recommend asking the TCAO that you are planning to use whether or not their code signing certificates support Java jar file signing if you are not sure.

• The certificate and the private key for it must be stored in a Java JKS keystore file. The TCAO should be able to provide instructions on how to generate the necessary keys and assemble a Java keystore file that contains both the certificate and the private key for it.
  

Once you have purchased the code signing certificate, follow the instructions from the TCAO to configure the certificate. Once this is done, place a Java keystore file containing both the purchased certificate and the private key for it on the server so that BBj Services can access it. During installation, the installer will prompt you to provide the keystore file location and the passwords for it once you select the “use an existing certificate” option. Note that the keystore file must be left on the server for as long as BBj Services is in use.

One benefit of purchasing a code signing certificate is that, at run time, Java Web Start clients who connect for the first time must accept only one warning dialog box (see Figure 5 for an example of what this dialog box can look like).

Figure 5. Run the Web Start application using a purchased certificate

Note, however, that this is only true if the Web Start client is connected to an Internet connection so that it can reach the TCAO and access the Certificate Revocation List (CRL) that is hosted there. Also note that the certificate you purchase will be valid for a certain number of years (usually three or less), after which you must purchase an additional certificate.

A second benefit of purchasing a code signing certificate is that all of your servers will serve the same certificate. Thus, once a Web Start client has accepted your certificate on any of your servers, it should not see any dialog windows the first time it connects to any of your other servers because the client computer already trusts your certificate.