Creating a self-signed certificate with GSKit

You create a self-signed certificate by specifying a label, the path to the key database, a distinguished name for the certificate, and other values when you run the GSKit command gsk8capicmd_64.

Procedure

  1. Open GSKit and run the following command:
    gsk8capicmd_64 -cert -create -db server.p12 -stashed -label myselfsigned -dn "CN=myserver.mycompany.com" -size 2048 -sigalg SHA256_WITH_RSA
    where
    • -db is the fully qualified path to the key database. On Windows platforms, you can include the -db mscng option to create the self-signed certificate in the MSCS.
      Note: If using the MSCS, omit the -stashed option from the command.
    • -label is the label attached to the self-signed 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 self-signed certificate. This algorithm is used to create the signature associated with the new self-signed certificate. The generated key type is chosen to match this signing algorithm.
  2. Optional: Enable hostname validation for your Db2® 11.5.6 and later clients.
    If you are enabling hostname validation for Db2 clients of version 11.5.6 and later, you need to include one or more hostnames in your self-signed certificates 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_ippaddr. The following example shows the syntax for adding multiple IP addresses for hostname validation:
    -san_ippaddr "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"

What to do next

When you have finished creating your self-signed certificate, you are ready to distribute it to your Db2 client machines.