z/OS Cryptographic Services System SSL Programming
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Using gskkyman to be your own certificate authority (CA)

z/OS Cryptographic Services System SSL Programming
SC14-7495-00

The gskkyman utility provides the capability for you to act as your own Certificate Authority (CA). If your own CA, you are authorized to sign certificate requests for yourself or others. This is convenient if you need certificates within your private web network and not for outside Internet commerce.

To be your own CA in a web network, you must create a CA database and self-signed CA certificate using gskkyman. A server or client that wants you to sign a certificate must supply you with their certificate request. After signing the certificate, the server or client must receive the CA certificate and the newly signed certificate. The CA-signed certificate must then be received into either the client or server key database.

This table describes the steps that are needed to become your own CA to allow secure communication between a client and a server. This example reflects the steps that are followed when the CA is on a different system or is a different user than the issuer of the certificate request.

Certificate Authority (System A) Server or Client (System B)
Step 1 - Create a key database
Create a key database using the gskkyman utility:
  • From the Database Menu, select option 1 - Create new database
See Creating, opening, and deleting a key database file for details.
Create a key database using the gskkyman utility:
  • From the Database Menu, select option 1 - Create new database
See Creating, opening, and deleting a key database file for details.
Step 2 - Create a Root Certificate Authority certificate
Create a Certificate Authority certificate:
  • From the Key Management Menu, select option 6 - Create a self-signed certificate
  • From the Certificate Usage menu, select option 1 - CA certificate
See Creating a self-signed server or client certificate for details.
No action required.
Step 3 - Create a certificate request
No action required. Create a certificate request:
  • From the Key Management Menu, select option 4 - Create new certificate request
See Creating a certificate request for details.
Step 4 - Send the certificate request to the CA
No action required. Send the certificate request to the CA:

See Sending the certificate request.

Step 5 - Sign the certificate request

Before signing a certificate for a client or server, you must make sure that the requester has a legitimate claim to request the certificate. After verifying the claim, you can create a signed certificate.

To sign the certificate request, the gskkyman utility must be issued using command-line options (see gskkyman command line mode syntax for a description of the options). The gskkyman utility must be issued with these parameters:
gskkyman -g -x num-of-valid-days 
-cr certificate-request-file-name 
-ct signed-certificate-file-name 
-k CA-key-database-file-name
-l label  

Example: This command allows you to sign a request certificate and allow the certificate to be valid for 360 days.

gskkyman -g -x 360 -cr server_request.arm 
-ct server_signed_cert.arm -k CA.kdb 
-l labelname
After you entered the command, you are prompted to enter the database password.
Note:
  1. The signed certificate is an end user certificate unless the -ca option is specified.
  2. The file name that is specified on the -ct option is created for you by the utility, and is the actual signed certificate file.
  3. The valid certificate lifetime range is between 1 and 9999 days. The certificate end date is set to the end date for the CA certificate if the requested certificate lifetime exceeds the CA certificate lifetime.
No action required.
Step 6 - Send the signed CA certificate and the newly signed certificate to the requester
Export the signed CA certificate (created in Step 2) to a Base64 file (DER or PKCS #7) See Copying a certificate without its private key. Send (for example, without its private key FTP) the Base64 file and the newly signed certificate (created in Step 4) to the requester. No action required.
Step 7 - Import the CA certificate
No action required. Import the CA certificate. See Importing a certificate from a file as a trusted CA certificate.
Step 8 - Receive the signed certificate
No action required. Receive the signed certificate. See Receiving the signed certificate or renewal certificate.
Note: Depending upon the SSL application, you might have to either send the CA certificate to the client, or the server application might present the certificate to the client for them during SSL session setup.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014