TLS Client Authentication with Db2 – Part 1: Introduction

Encryption of “Data on the Wire” with TLS (Tranport Layer Security), formerly known as SSL, is more and more mandatory, also in the Db2 for LUW and Db2 for z/OS ecosystem.

This series of blogs describes the principles of TLS and their relevance for the Db2 for LUW and Db2 for z/OS community. Special focus is on TLS client authentication with certificate, which extends the widely used pattern of TLS server authentication with certificate.

Important: TLS client authentication with certificate is supported for Db2 for z/OS database servers only. However, Db2 LUW administrators may be involved in that topic because special setup on the Db2 client side is required to support this kind of TLS configuration.

One base principle of TLS is “trust”. At least, client applications in a TLS encrypted conversation want to be sure that they connect to the “correct” server application and that clients can trust this server’s identity. In order to prove its identity the server presents a so-called server certificate when a TLS connection is established. This certificate is usually signed by a third party, a certificate authority (CA) or an intermediate CA. When a client also trusts this CA or intermediate CA, a server certificate is accepted by a client at the beginning of a TLS conversation and the encrypted connection can be established.

TLS handshake process for server authentication with certificate

The entire process of establishing a TLS connection is called “TLS handshake”. At the beginning of a TLS handshake, a client sends an unencrypted “Client Hello” request to the server’s TLS port and also passes a list of supported TLS versions and cipher suites at the client side.

The server responds with a “Server Hello” message, a TLS version and cipher suite which should be used for the ongoing connection and, most importantly, its server certificate. Again, this part of the conversation is still unencrypted.

Now the client decides whether it can trust this server and the server certificate. The client might have added this server, identified by the certificate, to its list of trusted entities or – most commonly – check whether the CA that is involved in the signing chain of the server certificate is on this list of trusted entities. This list of trusted entities is also called a "truststore”.

In case the server certificate is accepted, the client generates a shared encryption key, encrypts it with the server’s public key (stored in the certificate) and sends it back to the server. The server decrypts this shared key with its own private key and acknowledges the successful TLS handshake with a “Server finished” message to the client. Only the server, presenting its certificate to the client, is capable to decrypt the message because this server – and no one else – has access to the private key.

From now on, the connection between the client and server application is encrypted. In case of a Db2 client connecting to a Db2 server (no matter whether LUW or z/OS), after the secure connection from the database server to the client is established, the client sends a user id and password to the server for authentication. This is done by the server ESM (external security manager) such as RACF, ACF2, TopSecret.

This type of TLS authentication is also called “Server certificate authentication” or “Server authentication with certificate”. Clients verify the server’s identity during the handshake but on the other hand there is no verification process on the server side. Basically, a server would accept TLS handshake requests from any client without checking the client’s identity. However, even after successful TLS handshake, Db2 servers would still require a valid user id and password from the client and administrators of Db2 client applications still need to maintain this.

TLS handshake process for client authentication with certificate

The handshake process described above can be extended to client authentication with certificate. In this case, the server expects that the client initiating a TLS request also is a trusted entity. So, in this case, the client presents a certificate as a proof of its own identity to the server in the handshake process and the server can now verify the client’s identity. The server either trusts the client because the client’s certificate has been added to the server’s truststore or checks whether the CA that signed the client’s certificate is an entity the server trusts.

Managing certificates

As you can see, certificates play a central role in the handshake process, no matter whether it is server or client authentication with certificates. Certificates are used as a proof of identity of a communication partner in a TLS conversation. A certificate typically contains:

• Identity information in a “Subject Distinguished Name” (SDN) – who is the owner of this certificate?
• Issuer information in a “Issuer Distinguished Name” (IDN) – who signed that certificate?
• Alternate names, such as email address of the certificate owner, IP addresses, DNS names
• Expiration date and timestamp
• Public Key of the certificate owner
• Certificate label or alias name (“user friendly name”)
• Other information such as signature algorithm, serial number, certificate extensions, etc.

The public key can be read and consumed by every partner in a TLS handshake. It is complemented by a private key. The private key is used to decrypt messages which were encrypted with the public key. Only the certificate owner should have access to the private key. Therefore, a private key should be stored securely and safely in so-called keystores.

Relevance for Db2 administrators

Db2 for z/OS and LUW database servers as well as IBM provided Db2 clients and data server drivers support TLS out of the box. Adding TLS to an existing Db2 infrastructure is a straightforward process although multiple roles are involved.

• Security administrators usually provide private keys, certificates and keystores (z/OS: Keyrings)
• Network specialists reserve TLS ports and make them available in the firewalls
• For the z/OS platform network systems programmers configure AT (Application Transparent)-TLS rules in the z/OS TCPIP setup
• Db2 administrators configure the Db2 servers for TLS

The Db2 server side setup in Db2 LUW looks different from Db2 z/OS, due to the specifics of the underlying platform although the basic concept is the same.

For Db2 LUW, Db2 administrators need to make the keystore which contains the private key available to the Db2 server instance and activate the TLS port in the instance’s TCPIP configuration.

On z/OS, Db2 administrators typically work together with security administrators to get a RACF (or an equivalent security product’s) keyring configured which contains the server’s private key. Also, the network administrators configure so-called AT-TLS rules which define the policies for the TLS communications.

Whenever server applications and clients are set up to support server or client authentication with certificates or both, administrators need to consider to:

• Generate a private/public key pair and a certificate request for server applications
• Let a CA sign the certificate request
• Store the private key with its certificate chain in a secure, password protected keystore
• Configure the server application to pick this keystore for incoming TLS requests
• Configure the server application to enable TLS server and optionally client authentication with certificate and, if required, configure a dedicated TCPIP port for TLS requests

The client application needs to be configured for TLS as well, which means at least:

• Making the CA certificate that is in the server’s certification chain available for the client application
• Enabling TLS authentication in the application and, if necessary, specifying a new TCPIP port for the server connection

In case of client authentication with certificates, the same steps for generating a certificate which are required at the server side are required at the client side as well. In addition the client application needs access to the private key which is stored securely in the client’s file system.

Db2 client authentication with certificates also requires a couple of configuration settings which depend on the type of application (JDBC, ODBC, CLI, ...) and whether a Db2 instance-based client or a more lightweight data server driver is in place.

Important:

Db2 client authentication with certificate is only available for connections to Db2 for z/OS servers. Db2 LUW does not (currently) support this technique.

When a Db2 for z/OS server is configured for client authentication with certificates, there is a mapping from the client certificate to a RACF (or equivalent) user id in place. In this case, the security product reads the SDN (subject distinguished name) and/or IDN (issuer distinguished name) from the certificate and maps it to a locally defined user. This also means, no user id and password are sent over the encrypted connection for authentication at the server side. In fact, Db2 drivers do not allow that a user id and password is set when a connection is configured for client authentication with certificates.

Summary

You should have a basic understanding how the handshake process, an essential part of a TLS encrypted conversation, works and should be aware of the importance of certificates, private and public keys as well as keystores and truststores.

The next article describes the steps for setting up Db2 for z/OS servers as well as Db2 ODBC/CLI and JDBC clients for client authentication with certificates. In a subsequent article we will discuss special topics such as enabling Db2 REST services and other Java-based clients for client authentication with certificates.