Managing digital certificates

Use this topic to manage digital certificates using either the key management utility (iKeyman) or the keytool utility.

About this task

Secure Sockets Layer (SSL) connections rely on the existence of digital certificates. A digital certificate reveals information about its owner, including their identity. During the initialization of an SSL connection, the server must present its certificate to the client for the client to determine the server identity. The client can also present the server with its own certificate for the server to determine the client identity. SSL is therefore, a means of propagating identity between components. Refer to Configuring Secure Sockets Layer (SSL) and Defining Secure Sockets Layer connections .

A client can trust the contents of a certificate if that certificate is digitally signed by a trusted third party. A Certificate Authority (CA) acts as a trusted third party and signs certificates on the basis of its knowledge of the certificate requestor. Complete the following steps to manage digital certificates using either the key management utility (iKeyman) or the keytool utility:

Procedure

• Use the supplied key management utility.

  Refer to Starting the key management utility (iKeyman) .

  There are two options for creating a new certificate.

  • Request that a CA generates the certificates on your behalf. The CA creates a new certificate, digitally signs it, and delivers it to the requester. Popular Web browsers are pre-configured to trust certificates that are signed by certain CAs. No further client configuration is necessary for a client to connect to the server through an SSL connection. Therefore, CA signed certificates are useful where configuration for each and every client that accesses the server is impractical. Refer to Requesting certificate authority-signed personal certificates , Creating certificate signing requests , Receiving certificate authority-signed personal certificates , and Extracting public certificates for truststore files .

  • Generate a self-signed certificate. This option might be the quickest and require the fewest details to create the certificate. However, the certificate is not signed by a CA. Any client that connects to this server over an SSL connection needs configuration to trust the signer of this certificate. Therefore, self-signed certificates are only useful when you can configure each of the clients to trust the certificate. It is possible in some cases to present a self-signed certificate to an untrusting client. In some Web browsers, when the certificate is received and does not match any of those listed in the client trust file, a prompt appears asking if the certificate should be trusted for the connection and added to the trust file. Refer to Creating a keystore file , Creating truststore files , Adding keystore files , Adding truststore files , Creating self-signed personal certificates , and Importing signer certificates .

  You must configure server-side options. The WebSphere Application Server stores the keystore information in the repository and the keystore files are referred to in the security.xml file. Therefore, complete all server-side configuration through the administration console. For Java clients, refer to Configuring Secure Sockets Layer for Java client authentication .

• Use the command line Java utility called keytool. With keytool, you can create a private and public self-signed certificate key pair. For this example, the first user is cn=rocaj.

  1. Specify RSA for the private key to ensure that the MD5 with RSA signature algorithm is used. Not all Web browsers support the DSA cryptograph algorithm, which is the default when RSA is not specified. Set a password of at least six characters to protect the private key. Finally, specify the keystore file and keystore password (the option is storepass):

     ${WAS_HOME}/java/jre/bin/keytool -genkey -keyalg RSA -dname 
     "cn=rocaj, ou=users, u=uk, DC=internetchaos, DC=com" -alias rocaj 
     -keypass websphere -keystore testkeyring.jks -storepass websphere

     The previous three lines of code belong on one line, but were split onto three lines for illustrative purposes.

  2. Create the second private and public self-signed certificate key pair in the same manner for the user cn=amorv.

     ${WAS_HOME}/java/jre/bin/keytool -genkey -keyalg RSA -dname 
     "cn=amorv, ou=users, ou=uk, DC=internetchaos, DC=com" -alias amorv 
     -keypass websphere -keystore testkeyring.jks -storepass websphere

     The previous three lines of code belong on one line, but were split onto three lines for illustrative purposes.

     Now the keystore testkeyring.jks contains two self-signed certificates with the owner being the same as the issuer for each certificate.

  3. Verify the integrity and authenticity of the certificates by getting each certificate signed by the certificate authority.

     1. Generate the Certificate Signing Request, CSR-1 (for the first user cn=rocaj).

        ${WAS_HOME}/java/jre/bin/keytool -v certreq -alias rocaj 
        -file rocajReq.csr -keypass websphere -keystore testkeyring.jks 
        -storepass websphere

        The previous two lines of code belong on one line, but were split onto two lines for illustrative purposes.

     2. On UNIX-based platforms, remove the end of line characters (^M) from the certificate signing request. To remove the end of line characters, type the following command:

        cat rocajReq.csr |tr -d "\r"

     3. Generate the CSR-2 (for the second user cn=amorv).

        ${WAS_HOME}/java/jre/bin/keytool -v -certreq -alias amorv  
        -file amorvReq.csr -keypass websphere -keystore testkeyring.jks 
        -storepass websphere

        The previous two lines of code belong on one line, but were split onto two lines for illustrative purposes.

     4. On UNIX-based platforms, remove the end of line characters (^M) from the certificate signing request. To remove the end of line characters, type the following command:

        cat amoryReq.csr |tr -d "\r"

  4. Use the free Test SSL certificate program offered by Thawte Consulting to sign the Certificate Signing Requests (CSRs) for this example. In each case, select the Custom Cert option and set the certificate format to use the default for your kind of certificate. The example also selects the Generate an X.509v3 Certificate option and saves the two resulting files as rocajRes.arm and amorvRes.arm, respectively.

  5. Import the CA trusted root certificate into the keystore. Copy and paste the Thawte test root certificate in BASE64-encoded ASCII data format to a file called ThawteTestCA.arm. Add the test root CA certificate into the keystore file with the following command:

     ${WAS_HOME}/java/jre/bin/keytool -import -alias "Thawte Test CA Root" 
     -file ThawteTestCA.arm -keystore testkeyring.jks -storepass websphere

     The previous two lines of code belong on one line, but were split onto two lines due to the width of the page.

  6. Import the two certificate responses from the CA into the keystore file using the same alias name that was first given to the self-signed certificates. In this example, these alias names are rocaj and amorv respectively. Using an alternative alias name generates a new signer certificate and not a personal certificate chain.

     • Import the certificate response -1 (for the first user cn=rocaj).

       ${WAS_HOME}/java/jre/bin/keytool -import -trustcacerts -alias rocaj 
       -file rocajRec.arm -keystore testkeyring.jks  -storepass websphere. 
       Certificate reply was installed in keystore

       The previous three lines of code belong on one line, but were split onto three lines due to the width of the page.

     • Import the certificate response -2 (for the second user cn=amorv).

       ${WAS_HOME}/java/jre/bin/keytool -import -trustcacerts -alias amorv 
       -file amorvRec.arm -keystore testkeyring.jks -storepass websphere. 
       Certificate reply was installed in keystore

       The previous three lines of code belong on one line, but were split onto three lines due to the width of the page.

  7. Launch the JSSE ikeyman utility, which supports the PKCS12 format and the private key exporting associated with any certificate (the public key is also exported).

  8. Open the testkeyring.jks keystore file and select the first certificate from the Personal Certificates menu.

  9. Click Export and name the file, rocajprivate.p12. Export the second personal certificate and name it amorvprivate.p12.

  10. Verify that the same root certificate of the authenticating CA is installed as a trusted authority in the browser.

  11. To install either of the personal certificates into Netscape Communicator, click Communicator > Tools > Security Info > Certificates > Yours. Use the Import a Certificate option.

  12. Enter a password or PIN for the communicator certificate database, when you attempt to import the certificate. Enter the password used when first initializing your certificate database. Enter the password protecting the PKCS#12 certificate file, as set when you exported the personal private and public certificate key pair in iKeyman.

  13. Click Verify to check integrity and validity of the certificate. If you did not install the root CA certificate, your certificate fails the verification.

  14. Verify that you modified your Web server to support client side certificate requests.

  15. Go to the following URL: https://server_name/snoop; the Web browser prompts you to select a personal certificate when accessing a resource protected by the SSLClientAuth directive.

  16. Select the HTTPS information displayed by the snoop servlet; you see the certificate SubjectDN matching the following: Subject: CN=amorv, OU=users, OU=uk, DC=internetchaos, DC=com.

• Refer to Defining Secure Sockets Layer connections to create a new SSL definition entry for WebSphere Application Server using the administrative console. After a keystore file is configured, either by creating a self-signed certificate or by creating a certificate request and importing the reply, you can configure WebSphere Application Server to use the certificates. The product uses the certificates to establish a secure connection with a client through SSL.

• Set up the appropriate components to use the newly-defined SSL configuration. To ensure a secure connection, configure some non-WebSphere components, such as a Web server. A digital certificate is created for each component. The WebSphere Application Server owns a certificate and the Web server owns another certificate.

  Refer to Configuring IBM HTTP Server for Secure Sockets Layer mutual authentication .

What to do next

1. Click Save in the administrative console to save any modifications to the configuration.

2. Synchronize the configuration with all node agents (Network Deployment only).

3. Once synchronized, stop all servers and restart them.

Sub-topics

Related concepts

Related tasks