Configuring hostname validation for TLS connections to Database Partitioning Feature (DPF) servers

The Database Partitioning Feature (DPF) is a Db2 scalability feature that enables you to divide a database into multiple partitions, with each partition having its own set of resources. These partitions can be set up on different hosts and the certificates on these hosts need to be set up in a specific way for hostname validation to be successful.

Connecting to catalog partitions

The following example shows a four partition DPF cluster:
partition 0 - h1.db2.example.com (catalog partition)
partition 1 - h2.db2.example.com
partition 2 - h3.db2.example.com
partition 3 - h4.db2.example.com
If a client only connects to the catalog partition, then h1.db2.example.com must be the hostname that is configured at the client and in the certificate for the catalog partition. Examine the following client connection string: 
Hostname=h1.db2.example.com;Security=SSL;SSLClientHostnameValidation=Basic;Database=…
Note the dNSName value in the Extensions section of the certificate returned by the DPF node::
Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=Example Enterprise CA
Subject : CN=none
Not Before : November 26, 2020 4:44:11 PM EST

Not After : November 27, 2021 4:44:11 PM EST

Extensions
    subjectAlternativeName
        dNSName: h1.db2.example.com

Signature Algorithm : SHA1WithRSASignature

Connecting to non-catalog partitions

Clients can also connect directly to non-catalog partitions in a DPF cluster. For hostname validation to be successful in this case, one or more certificates on the server must be set up in one of three ways:

Using a separate certificate for each DPF host

When creating a separate certificate for each host, the SAN or Common Name in the certificate must contain the host's fully qualified hostname.

For example, if a client connects to h2.db2.example.com in the previously mentioned cluster, the certificate returned by this host must contain h2.db2.example.com in the SAN or the Common Name for hostname validation to be successful.


Using a common certificate with multiple SANs

When using a common certificate for all hosts in the cluster, include multiple SAN entries with fully qualified hostname of each host in the cluster. This ensures that hostname validation is successful, regardless of the partition to which the client connects, since the returned common certificate contains the hostname to which the client is configured to connect.

Note the hostnames in the SAN in the Extensions section of the certificate:
Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=ExampleCA
Subject : CN=none
Not Before : November 26, 2020 4:44:11 PM EST

Not After : November 27, 2021 4:44:11 PM EST

Extensions
    subjectAlternativeName
        dNSName: h1.db2.example.com
        dNSName: h2.db2.example.com
        dNSName: h3.db2.example.com
        dNSName: h4.db2.example.com

Signature Algorithm : SHA1WithRSASignature

Using a common certificate containing a wildcard hostname

When using a common certificate for all hosts in the cluster, rather than including multiple hostnames, include a single SAN entry with a wildcard hostname that represents all of the hosts in the cluster. When validating the hostname, the client acknowledges the wildcard hostname as representing all hosts in the cluster. This ensures that, regardless of the host to which the client connects, hostname validation is successful.

Note the single SAN entry containing the wildcard symbol in the Extensions section:
Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=ExampleCA
Subject : CN=none
Not Before : November 26, 2020 4:44:11 PM EST

Not After : November 27, 2021 4:44:11 PM EST

Extensions
    subjectAlternativeName
        dNSName: h*.db2.example.com

Signature Algorithm : SHA1WithRSASignature
Note: Wildcard hostnames only represent hosts that share the same domain name, such as db2.example.com. For more information about the rules around use of wildcards, see Using wildcards in hostnames.

It is possible to include both wildcard and non-wildcard hostnames in the SANs of a certificate.

Adding and removing a host from a DPF cluster

When adding a new host to the cluster, one or more of the server certificate might have to be updated depending on how they’re set up.

If a separate certificate is used for each host in a cluster, the new host needs to have its fully qualified hostname in its certificate. Since a separate certificate is used per host, the other hosts in the cluster don’t need to be updated.

If a common certificate is used for all hosts in a cluster, the common certificate has to be recreated to contain an additional SAN entry for this new host and all of the hosts in the cluster need to be updated to use this newly created certificate if they’re not using a shared keystore.

If a common certificate containing a wildcard hostname is used for all hosts in a cluster, no updates are needed given that the wildcard hostname in the common certificate can match the new hostname. This certificate configuration might be preferable if new hosts are frequently added to the cluster since it removes the need to keep creating new certificates.

When removing a host from the cluster, no changes to the certificate used by the cluster are required for hostname validation to be successful.

Node hopping

The SET CLIENT CONNECT_MEMBER <node number> parameter and the DB2NODE environment variable allow the client to connect to a partition that is not part of the host to which it is configured to connect. There are two separate connections established in this case:
  • The connection between the client and the host to which it is configured to connect.
  • The connection between the host and the partition specified in the CONNECT_MEMBER parameter.
The second connection is referred to as a hopped connection. TLS can be enabled for both connections, but hostname validation can only be enabled for the first connection. If there are multiple logical partitions on the destination host, and the desired partition is not the partition that is listening on the network, a third connection over IPC will be established between the partition on the destination host that is listening on the network and the desired logical partition.