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.
- 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.
- 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.
- 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).
${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.
- 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"
- 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.
- 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"
- 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.
- 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.
- 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.
- 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).
- Open the testkeyring.jks keystore file and select
the first certificate from the Personal Certificates menu.
- Click Export and name the file, rocajprivate.p12.
Export the second personal certificate and name it amorvprivate.p12.
- Verify that the same root certificate of the authenticating
CA is installed as a trusted authority in the browser.
- To install either of the personal certificates into
Netscape Communicator, click Communicator > Tools > Security Info
> Certificates > Yours. Use the Import a Certificate option.
- 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.
- Click Verify to check integrity and validity
of the certificate. If you did not install the root CA certificate,
your certificate fails the verification.
- Verify that you modified your Web server to support
client side certificate requests.
- 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.
- 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.
- Create a new SSL definition entry for WebSphere Application
Server using the administrative console.
Refer to Defining Secure Sockets Layer connections
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
Setting up SSL communication between the Web browser and
WebSphere Application Server. Using digital signatures, you 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:
- Click Save in the administrative console to save any modifications
to the configuration.
- Synchronize the configuration with all node agents (Network Deployment
only).
- Once synchronized, stop all servers and restart them.