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