Creating a certificate signing request (CSR) with IBM Global Security Kit (GSKit)

You create a certificate signing request (CSR) by specifying a label, the path to the key database, a distinguished name for the certificate, and other values when you run the IBM Global Security Kit (GSKit) command gsk8capicmd_64. When the CSR is created you then forward it to a certificate authority (CA) for signing.

Procedure

Open IBM Global Security Kit (GSKit) and create your CSR: 
gsk8capicmd_64 -certreq -create -db server.p12 -stashed -label myselfsigned -dn "CN=myserver.mycompany.com" -size 2048 -sigalg SHA256_WITH_RSA -target myselfsigned.csr
where
  • -db is the fully qualified path to the key database. On Windows platforms, you can include the -db mscng option to create the CSR in the MSCS.
    Note: If using the MSCS, omit the -stashed option from the command.
  • -label is the label attached to the certificate upon creation.
  • -dn <string> is the distinguished name that uniquely identifies the certificate. The input must be a quoted string of the following format. Only the Common Name (CN) attribute is mandatory.
    • CN = Common Name
    • O = Organization
    • OU = Organizational Unit
    • L = Location
    • ST = State or Province
    • C = Country
    • DC = Domain Component
    • EMAIL = Email Address
  • -size is the key size (in bits) of the new key pair to be created. For RSA certificates, the minimum key size is 2048 bits.
  • -sigalg <signature_algorithm> is the signing algorithm to be used during the creation of the certificate. This algorithm is used to create the signature associated with the new certificate. The generated key type is chosen to match this signing algorithm.
  • -target is the file name assigned to the generated CSR. It is best practice to use the certificate label.
When the CSR is created, send the file to your CA for signing.
Important:
Db2® clients are configured to validate the server’s hostname using hostname validation. You need to include one or more hostnames in your CSR for each Db2 instance to which your clients are configured to connect. These can be single servers or clustered servers in various Db2 configurations, such as Db2 pureScale®, HADR, data partitioning feature (DPF), and other topologies. Hostnames are represented in different ways, depending on the Db2 instance where the certificate resides:
  • A single server is represented using the common name (CN) field which is specified as part of the -dn option.
  • One or more servers are represented in a subject alternate name (san_) field, using fully qualified hostnames, IP addresses, or wildcard (*) hostnames.
The following example shows the syntax for adding a hostname for a single server, using the common name field: 
-dn "CN=xyz.db2.example.com,…"
where xyz.db2.example.com is a fully qualified hostname.
Wildcard hostnames in the CN field are supported when performing hostname validation, so long as no SAN values exist in the certificate. The following example shows the syntax for adding a hostname for a single server in the subject alternate name field: 
-san_dnsname "xyz.db2.example.com"
Multiple SAN values are separated by commas: 
-san_dnsname "xyz.db2.example.com,abc.db2.example2.com"
If a subject alternate name (SAN) entry is present in the certificate, then the common name is ignored. You can represent one or more servers in a certificate using IP addresses. Multiple IP addresses are separated by commas in the SAN field, -san_ipaddr. The following example shows the syntax for adding multiple IP addresses for hostname validation: 
-san_ipaddr "127.0.0.1, 127.0.0.2"
You can include both DNS names and IP addresses in the SAN for hostname validation. The following example shows the syntax: 
-san_dnsname "xyz.db2.example.com", -san_ipaddr "127.0.0.1"
Wildcard hostnames can be used to represent multiple hosts belonging to the same domain. You can add multiple wildcard hostnames, separated by commas, to the same self-signed certificate to represent groups of hosts in separate domains. Wildcard (*) hostnames in common name fields are supported when performing hostname validation. The following example shows the syntax for a wildcard hostname that represents all hosts in the db2.example.com domain: 
-san_dnsname "*.db2.example.com"
The following example shows the syntax for adding wildcard hostnames for hosts belonging to separate domains: 
-san_dnsname "*.db2.example.com,a*.db2.example2.com"
Fully qualified hostnames and wildcard hostnames in the same SAN are separated by commas. The following example shows the syntax for including fully qualified hostnames and wildcard hostnames in the same SAN: 
-san_dnsname "xyz.db2.example.com,*.db2.example2.com"

for more information about representing servers in certificates, see Configuring Db2 Instances for hostname validation.

What to do next

After you have sent your CSR to your CA to be signed, you need to add root and intermediate certificates to your keystore. These certificates are provided to you by the CA as part of the CSR process.