Db2 Connect Version 12 is now available – important changes you should know

December 3, 2024

Posted By: Christoph Theisen in Technical Content,

Recently, on November 14^th, IBM released the new version 12 of Db2 LUW and with that, as for every LUW version, a new version of Db2 Connect and the IBM Db2 Clients and Data Server Drivers became available as well.

Version 12 is not only a major version from a Db2 LUW perspective, it also has important changes for users of the IBM Db2 Clients and Data Server Drivers and for users entitled for Db2 Connect.

License Files for JDBC are changing

Users of the Db2 Clients and Data Server Drivers who want to connect to Db2 for z/OS or Db2 on IBM i (former iSeries) need a Db2 Connect license. Depending on the licensing model, the license can be installed centrally on the Db2 server side, on the Db2 client side, on a Db2 Connect Server (a.k.a Gateway) or multiple places in parallel.

Users who are not entitled for any of the “Db2 Connect Unlimited” editions can only choose between client-side licensing and Db2 Connect Servers.

This model is basically unchanged in Db2 Connect Version 12. However, there is a change for JDBC and SQLJ users.

Starting with Db2 Connect Version 12, there must be a corresponding Version 12 license Db2 Connect License available to JDBC and SQLJ applications. No matter, whether this license is installed on a Db2 server side (for Db2 Connect Unlimited Editions) or on the client side. This already applies to ODBC/CLI applications for many years and is now adopted to JDBC and SQLJ. In the future, users may need to update the license files for JDBC/SQLJ as well as ODBC/CLI applications whenever a new major version of Db2 Connect becomes available.

Before Db2 Connect Version 12, a license file named db2jcc_license_cisuz.jar had to be in the CLASSPATH of the JDBC application if no server-side license is present. This concept existed for years, and you could literally leave a db2jcc_license_cisuz.jar from very old Db2 Connect versions in the CLASSPATH although your actual JDBC driver (db2jcc4.jar) is from a newer version. Beginning with Db2 Connect Version 12, the license activation kit does not contain the db2jcc_license_cisuz.jar anymore. Instead, it ships with a JDBC license file which corresponds to the type of license a user is entitled for. For example, the license activation kit for Db2 Connect Enterprise Edition ships with a license file named “db2jcc_license_consvEE.jar”. In addition, the JDBC driver shipped with Db2 12 (LUW, Connect, Data Server Drivers, Clients) requires any of these newer license files in the CLASSPATH or a Db2 Connect Version 12 server-side license.

So, if you are planning a deployment of the new Db2 12 JDBC driver (architecture level 4.34.xx) to your Java client applications make sure you are deploying one of the new license files at the same time. As an alternative, activate the Db2 Connect Version 12 license on the server side if you are entitled for Db2 Connect Unlimited Edition. Otherwise, your JDBC applications fail when trying to connect to Db2 for z/OS or Db2 on IBM i servers.

From a technical perspective, you can also create a copy of your new license file under the name “db2jcc_license_cisuz.jar” or create a symbolic link from the new license file to “db2jcc_license_cisuz.jar” without modifications to your CLASSPATH settings.

Note: this change is for JDBC/SQLJ only. For the ODBC/CLI part, the Db2 Connect license activation kit comes with a license file which is specific to that Db2 Connect license model anyway.

For users of one of the Db2 Connect Unlimited Editions, it is recommended, as with every major version of Db2 Connect, to activate the license on the server side. This procedure is unchanged with Version 12 of Db2 Connect and makes sure that every client (Version 12 and older, JDBC/SQLJ or ODBC/CLI) can connect to this server with a valid license.

TLS Hostname Validation

This change affects users of TLS/SSL encryption. Starting with Version 12 of Db2 LUW and the Db2 Clients and Data Server Drivers, the JDBC property “sslClientHostnameValidation” and the corresponding ODBC/CLI configuration parameter “SSLClientHostnameValidation” change their default setting from “OFF” to “BASIC”.

With “BASIC”, the data server drivers require that the Db2 server certificate presented in the TLS handshake contains a so-called “subject alternate name” (SAN) which contains the IP address and/or DNS host name of the Db2 server the client application connects to. With the previous default setting “OFF”, SANs could be empty or contain non-matching IP addresses or DNS host names.

Call to action:

When migrating to Db2 12 on the Db2 Client and Data Server Driver side, check the SANs on your Db2 server certificates and make sure they contain all possible IP addresses and DNS host names your clients can use in their connection strings or properties.

Users of Db2 for z/OS Data Sharing connecting through a Sysplex Distributor should take care that the IP address and DNS host name of the Sysplex Distributor is available on the server certificate. For more information, see here:

https://www.ibm.com/docs/en/db2/12.1?topic=instances-connections-other-topologies

When you are not sure whether the Db2 server certificates can be configured accordingly, you can disable hostname validation by explicitly setting this property to “OFF”.

Automatic Client Certificate Selection

This enhancement affects users of TLS/SSL encryption with client certificate authentication against a Db2 for z/OS server. In earlier versions of the ODBC/CLI driver, a configuration property “SSLClientLabel” was mandatory on the client side to specify the label of the client certificate in the keystore or (for Windows platforms) the MS Windows Certificate Store.

With Version 12 of the Db2 Data Server Driver, the “SSLClientLabel” can be omitted if there is only one client certificate present in the client’s keystore or the MS Windows Certificate Store.

Note that this change is relevant for ODBC/CLI clients only. There is no equivalent to “SSLClientLabel” for JDBC/SQLJ clients.

JDBC changes for encryptionAlgorithm

The JDBC driver 4.33.31, shipped with Version 11.5.9 of Db2 LUW and the Db2 Data Server Drivers, introduced a default change for the properties “securityMechanism” and “encryptionAlgorithm” which could lead to failing JDBC applications when the Integrated Cryptographic Service Facility (ICSF) was not available on a z/OS system. Affected users could bypass this failure by explicitly setting the security mechanism to “CLEAR_TEXT_PASSWORD_SECURITY” or enforcing DES encryption (instead of 256-bit AES) along with security mechanism “ENCRYPTED_USER_AND_PASSWORD_SECURITY”.

With the JDBC driver shipped with Db2 Version 12 (architecture level 4.34.xx), this bypass is no more necessary. When ICSF or the cryptoprocessor are not enabled on a z/OS system on which a Db2 for z/OS data server runs, the driver returns an error with Reason: Local security service non-retryable error. The driver retries the connection by opening a new socket using CLEAR_TEXT_PASSWORD_SECURITY (3).

However, it is still recommended to change to TLS/SSL encryption in general and have ICSF available on a z/OS system.

For more information about the change introduced with Version 11.5.9 of Db2, see this blog: https://community.ibm.com/community/user/datamanagement/blogs/paul-mcwilliams1/2023/11/16/ibm-data-server-driver-jdbc-v433-more-secure?CommunityKey=621c2a2a-01f9-4b57-992f-36ed7432e3bb

For general information about security in the JDBC driver, see this link:

https://www.ibm.com/docs/en/db2/12.1?topic=java-security-under-data-server-driver-jdbc-sqlj

Support for ARM chip set machines

Version 12 of the Db2 Data Server Driver Package now ships ARM driver binaries for Mac M1/M2/M3 machines. This implements a customer requirement with almost 300 votes in the IBM Ideas portal (https://ibm-data-and-ai.ideas.ibm.com/ideas/DB2CON-I-92).