Managing certificates with IBM GSKit

Using a third-party Certificate Authority

Install the CA root certificate

Instead of setting up its own certificate authority, a company may use a third-party certificate authority to sign its server certificates. The client and server must have access to the third-party CA's root certificate to verify the server certificates that are signed by the third-party CA.

GSKit ships with a collection of third-party root certificates from well-known CA companies, such as Thawte, Verisign, and Entrust. If the server is going to use one of these well-known companies to sign its certificates, this step can be skipped. But if the server is going to use certificates from a third-party CA whose root certificate is not shipped with GSKit, the third-party CA's root certificate must be imported to both the server and the clients' key database files as follows:

1. Obtain the CA root certificate. The process for this varies depending on the third-party CA's procedures. Third-party CAs often make their root certificates available for download.
2. Add the third-party's root CA certificate to both server and client key databases and mark it as trusted as follows:

   gsk8capicmd -cert -add -db server.kdb -stashed -label "Some CA root" -file ca.der -format binary -trust enable
gsk8capicmd -cert -add -db client.kdb -stashed -label "Some CA root" -file ca.der -format binary -trust enable

   This example uses a third-party CA root certificate that is in a binary format. If the certificate is in an ASCII format, use the -format ascii option. The -db parameter specifies the name of the key database to import the third-party CA root certificate into. The -label parameter specifies the label to use for the third-party CA root certificate inside the key database file. The -file parameter specifies the file that contains the third-party CA root certificate.

Back to top

Requesting a certificate using a signing request

In this scenario, GSKit creates a certificate request, the third-party CA signs the certificate in the request, and GSKit imports the signed certificate into the server key database.

1. Generate a server certificate request using the server's key database file:

   gsk8capicmd -certreq -create -db server.kdb -stashed -label "Some CA signed certificate" -dn "CN=host.mycompany.com,O=company,C=country" -file cert_request.arm

   The -db parameter specifies the name of the server's key database file. The -label parameter specifies a label to refer to the newly created certificate in the key database file. The -dn parameter specifies the distinguished name to be used on the server's certificate. The -file parameter specifies the file to contain the exported certificate signing request. The CN parameter specifies the DNS name of your server. This is necessary for an SSL client to validate the certificate.
   You can also request SAN extension by using -san_dnsname or -san_ipaddr options (not supported in version 7). For example:

   gsk8capicmd -certreq -create -db server.kdb -stashed -label "Some CA signed certificate" -dn "CN=host.mycompany.com,OU=unit,O=company" -san_dnsname "host1.mycompany.com,host2.mycompany.com" -san_ipaddr "10.10.10.1,10.10.10.2" -file cert_request.arm

2. Send the certificate request (that is, the cert_request.arm file) to the CA. The process for submitting a certificate signing request varies among CA companies. Often the signing request can be submitted using a web form.
3. The CA then returns the signed certificate. In this scenario, the assumption is that the signed certificate is in a file that is called cert_signed.arm and is in an ASCII format.
4. Receive the signed certificate into the server's key database file and set it as the default for communicating with clients:

   gsk8capicmd -cert -receive -db server.kdb -stashed -file cert_signed.arm -default_cert yes

   The -db parameter specifies the name of the server's key database file. The -file parameter specifies the name of the file that contains the signed certificate.

Back to top

Requesting a certificate without a signing request

Some Certificate Authorities do not accept signing request files. Instead, they generate the signing request internally on behalf of the requesting server and then sign it as one transaction. The CA then returns to the server two files, one containing the private key for the server to use and one containing the signed server certificate. In this example, the assumption of the two files is as follows:

• host.mycompany.com.crt: This is the file that contains the signed server certificate.
• host.mycompany.com.key: This is the file that contains the server's private key

To use these files, they must be converted to an industry standard format called PKCS12 before they can be imported into a key database.

1. Use OpenSSL to convert the two files into a PKCS12 file as follows:

   openssl pkcs12 -export -in host.mycompany.com.crt -inkey host.mycompany.com.key -out host.mycompany.com.p12 -name "CA signed"

   The OpenSSL command prompts you to enter a password. This password is only used temporarily so it can be any arbitrary password. In this example, the password is set to abc. The -in parameter specifies the file that contains the signed server certificate. The -inkey parameter specifies the file that contains the server's private key.

2. Import the certificate from the PKCS12 file to the server's key database file as follows:

   gsk8capicmd -cert -import -db host.mycompany.com.p12 -pw abc -target server.kdb

   The -db parameter specifies the name of the PKCS12 file. The -pw parameter specifies the password that protects the PKCS12 file. The -target parameter specifies the name of the server's key database file. You are prompted for the password that protects the target database file.

3. Make the imported certificate the default certificate to use for communications as follows:

   gsk8capicmd -cert -setdefault -db server.kdb -stashed -label "CA signed"

   The -db parameter specifies the name of the server's key database file. The -label parameter specifies a label of the imported certificate.

6 of 10 | Previous | Next

Comments

Back to top

Table of contents

• Before you start
• Overview
• Setup
• Managing self-signed certificates
• Creating a Certificate Authority (CA)
• Using a third-party Certificate Authority
• GSKit security considerations
• Tips and tricks
• Resources
• About the author

---

6 of 10 | Previous | Next

Next steps from IBM

WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.

---

• Try: Download a free trial version of IBM WebSphere Portal Express V6.1, which offers collaboration, document management, and secure Web content management.
• Article: This article provides an overview of the WebSphere Portal security architecture, including internet security, and secure connections between clients.
• Tutorial: This tutorial take you through the steps to develop and test your first portlet WebSphere Portal Test Environment.
• Demo: These demos show Web 2.0 features available today within WebSphere Portal, as well as several features planned for the future.
• Buy: IBM WebSphere Portal Express

Dig deeper into Security on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.