Manage digital certificates

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 Socket Layer and Configuring a SSL repertoire configuration entry.

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. Different approaches for generating certificates include...

  1. Use the supplied key management utility. Refer to Starting the key management utility (iKeyman). There are two options for creating a new certificate.

    1. 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 preconfigured 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 a CA-signed personal certificate, Creating a certificate signing request (CSR), Receiving a CA-signed personal certificate, and Extracting a public certificate for use in a truststore.

    2. 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 Create a keystore file, Create a truststore file, Adding keystore files, Adding truststore files, Create a self-signed personal Certificate, and Importing a signer certificate

    3. 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 SSL for Java Client Authentication.

  2. 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)... 

      #keytool -genkey -keyalg RSA -dname "cn=rocaj, ou=users, ou=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 due to the width of the page.

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

      #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 due to the width of the page.

      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.

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

        #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 due to the width of the page.

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

        #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 due to the width of the page.

    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... 

      #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). 

        #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). 

        #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>/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.

  3. Refer to Create a Secure Sockets Layer repertoire configuration entry to create a new SSL definition entry for WAS using the administrative console. Once 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 WAS to use the certificates. The product uses the certificates to establish a secure connection with a client through SSL.

  4. 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 WAS owns a certificate and the Web server owns another certificate. Refer to Configuring an IBM HTTP Server for SSL mutual authentication.

 

Usage Scenario

Once you finish configuring security, perform the following steps to save, synchronize, and restart the servers...

  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.

 

See Also

SSL
Configuring SSL
Configuring IBM HTTP Server for secure sockets layer mutual authentication
Configuring the IBM HTTP Server for distributed platforms and the Web server plug-in for SSL
Creating a SSL repertoire configuration entry