Manage digital certificates

 

+

Search Tips   |   Advanced Search

 

 

Overview

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.

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.

 

Use the supplied key management utility

There are two options for creating a new certificate.

Keystore files are referred to in security.xml. Complete all server-side configuration through the administration console.

For Java clients, refer to Configuring Secure Sockets Layer for Java client authentication.


Use the keytool command line Java utility

With keytool, one 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 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.

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

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

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

    4. On UNIX-based platforms, remove the end of line characters (^M) from the certificate signing request.
          cat amoryReq.csr |tr -d "\r"
      

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

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

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

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

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

    10. Click Export and name the file, rocajprivate.p12.

      Export the second personal certificate and name it amorvprivate.p12.

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

    12. To install either of the personal certificates into Netscape Communicator, click...

        Communicator | Tools | Security Info | Certificates | Yours

      Use the Import a Certificate option.

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

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

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

    16. Go to the following URL...

        https://servername/snoop

      The Web browser prompts you to select a personal certificate when accessing a resource protected by the SSLClientAuth directive.

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

  4. Refer to Creating 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, one can configure WAS to use the certificates. The product uses the certificates to establish a secure connection with a client through SSL.

  5. 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 IBM HTTP Server for Secure Sockets Layer mutual authentication.

     

    What to do next

    Setting up SSL communication between the Web browser and WebSphere Application Server. Using digital signatures, one can communicate securely from the Web browser through the Web server to WebSphere Application Server. 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


    Starting the key management utility (iKeyman)
    Creating a keystore file
    Creating truststore files
    Map certificates to users

     

    See Also


    Secure Sockets Layer

     

    Related Tasks


    Configuring IBM HTTP Server for Secure Sockets Layer mutual authentication
    Configuring the Web server plug-in for Secure Sockets Layer
    Creating a Secure Sockets Layer repertoire configuration entry

     



     

     

    WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
    IBM is a trademark of the IBM Corporation in the United States, other countries, or both.