为 IBM Data Server Driver for ODBC and CLI 配置 SSL

TLS 和 SSL 简介

应用程序和网站保护其所传输数据的最常见方法是传输层安全协议 (TLS)。TLS 以前称为安全套接字层 (SSL) 协议。SSL 是 Netscape 于 1994 年开发的，然后由互联网工程任务组 (IETF) 作为 RFC 2246 而采用。

SSL V3.0 是最后一个 SSL 版本，该协议所有新的开发工作都是在 TLS 下继续开展的。考虑到 IETF 采用 TLS 时各个协议之间的类似性，TLS V1.0 有时也被称为 SSL V3.1。截至编写本文时最新的协议版本为 TLS V1.2。尽管 TLS 无法与 SSL 互操作，但在服务器或网站与不支持 TLS 协议的伙伴进行通信时，它能够让您使用 SSL。但是，由于 SSL 中已知的不足，已不再推荐使用该协议。

在本文中，我们将交替使用术语 SSL 和 TLS，除非另行说明，但最好使用最新的协议版本，以实现最佳的连接安全性。

TLS 和 SSL 依靠公钥基础架构 (PKI) 来识别和认证通信伙伴。PKI 基于 X.509 数字证书，它使用一个受信任的第三方（一个证书授权中心，CA）为连接的一端或两端的身份提供保证。

保持某些数据是私有的很重要，包括：

• 信用卡信息
• 私密信件
• 个人详细信息
• 敏感的公司信息
• 银行帐户信息

TLS/SSL 使用多种密码学方法来保护网络中传输的数据，让客户确信其数据是安全的。加密是一种重要的密码学方法，加密系统一般属于两个类别之一：

• 对称密钥加密
• 公钥或非对称加密

对称密钥加密

对称密钥加密需要使用已加密数据的发送方和接收方都知道的一个秘密。这个密钥用于加密和解密该数据。高级加密标准 (AES) 就是一种常用的对称算法。可在软件或硬件中非常高效地实现对称加密，所以它是加密大量数据的不错选择。在对称加密系统中，难题是如何在通信系统之间安全地共享秘密密钥。如果发送方或接收方以外的任何人知道了该密钥，会话的安全性就会被破坏。一次对话通常需要共享至少两个秘密密钥（每个方向一个）。在网络世界中，人们期望网站和应用程序与数百甚至数千个伙伴保持安全的对话，导致对称密码学本身在保护网络上的对话方面是一种不切实际的方法。

公钥（非对称）加密

公钥加密或非对称加密使用一对在数学上相关的密钥来加密和解密数据。对于使用其中一个密钥加密的数据，只能使用该密钥对中的另一个密钥来解密。Rivest-Shamir-Adleman (RSA) 或许是最著名的非对称算法。在公钥加密中，密钥对中的一个密钥是保密的（ 私钥 ），另一个密钥是公开的（ 公钥 ）。公钥的使用有助于解决我们在对称加密中看到的密钥分发问题。但是，非对称加密所需的计算能力比对称加密更高（高一个数量级），所以它不太适合加密大量的数据。

非对称密码学另一个有用的应用是 数字签名 ，其中使用发送方的私钥加密一条消息的压缩值（哈希值）。然后将此签名值与用于生成哈希值的原始明文消息一起发送。接收方使用发送方的公钥解密该签名，以显示该哈希值，然后对收到的明文消息运行同样的哈希算法来获取他自己的压缩值。使用发送方的公钥解密出这个哈希值后，将它与已发送的哈希值对比。如果两个哈希值匹配，则表明：

• 收到的消息未被修改，因为接收方的哈希值与发送的值相同。
• 验证了消息的来源，因为该数字签名是用发送方的公钥解密的。

数字签名是由一个证书授权中心 (CA) 以数字方式签名的文件，证书授权中心是 SSL 会话中通信双方都信任的一个第三方。证书中包含了证书所有者的信息，包括所有者的电子邮件、姓名、证书用途、有效期、包含网站或电子邮件地址的区分名 (DN)），CA 分配的一个序列号，以及对此信息进行签名的 CA 的证书 ID。它还包含证书所有者的公钥。CA 的签名是证书内容的哈希值，使用 CA 的私钥加密该证书内容，这不仅证明该证书是真实的，还证明它的内容没有被无意地修改。

通常，一个浏览器或应用程序已加载了知名 CA 的根证书或根 CA 证书。CA 维护着所有已签名证书的列表和已撤销证书的列表。证书只有经过签名后才是安全的。证书经过签名后，就不能修改。所有根 CA 证书都是自签名证书。收到一个数字证书后，可以使用 CA 公钥来检查 CA 的数字签名。验证该签名可以证明数字签名的完整性和起源。如果 CA 值得信任，那么也可保证这个公钥值属于证书的所有者。

TLS/SSL 服务

• 对等认证 是通过通信伙伴的一方或双方的数字证书，并使用签署该证书的 CA 的公钥验证这些证书的真实性来实现的。然后通信伙伴使用他们自己的公钥或私钥，通过加密和解密消息的内容来完成认证。为此，他们协商一组密码学算法（密码套件）和一些二进制值，这些值最终将用作对称加密密钥，保护通过安全 SSL 会话发送的应用程序数据。对等认证、密码套件和会话密钥协商在 TLS/SSL 协议的第一个阶段完成，这个阶段称为 SSL 握手。
• 数据隐私 是通过在 SSL 握手期间确定的对称加密算法和密钥来实现的。
• 消息认证和完整性 ：TLS/SSL 使用其他密码学方法（常常基于哈希算法，比如安全哈希算法[SHA]）来保证通过一个安全连接收到的每条消息都来源于正确的通信伙伴（消息认证）。TLS/SSL 还保证这些消息在它们从发出到收到的过程中没有被更改（消息完整性）。像数据隐私一样，通过在 SSL 握手期间确定的算法和密钥来应用消息认证和完整性保护功能。

如何将 TLS/SSL 与 HTTPS 结合使用

浏览器请求一个安全页面（一个以 https:// 开头的 URL），发起一次 TLS/SSL 握手。在握手期间执行了以下操作：

1. Web 服务器发送它的数字证书，其中包含它的公钥。
2. 浏览器检查该证书是否由受信任的 CA 颁发，该证书是否仍有效，以及该证书是否与联系的站点相关。根据 SSL 配置，浏览器可能将它自己的证书发送回服务器，以便服务器认证该浏览器。
3. 浏览器和服务器交换消息来协商密码套件（密码学算法集和密钥长度）以及最终将用作对称会话密钥的二进制数据（称为建钥材料）。在交换期间，浏览器使用服务器的公钥加密消息，该消息中包含了选定的密码套件和建钥材料。
4. Web 服务器使用它的私钥解密密码套件和建钥材料，得到对称会话密钥，然后使用这些算法和密钥完成握手。

TLS/SSL 握手完成后，通信系统使用双方协商好的密码学算法和会话密钥来实现数据隐私、消息认证和消息完整性。

回页首

DB2 Connect 中的 SSL 支持

DB2 Connect 支持 SSL。命令行接口 (CLI)、命令行处理器 (CLP) 和 .Net Data Provider 客户端应用程序和使用 IBM Data Server Driver for JDBC and SQLJ 的应用程序（类型 4 连接）都支持 SSL。

关于 SSL 和 DB2 Connect 需要记住几点：

• 要加密在客户端与 DB2 数据库之间传输的数据，可使用 DATA_ENCRYPT 认证类型或 DB2 数据库系统的安全套接字层 (SSL) 支持。
• 客户端和 HADR 主要服务器之间支持 SSL。使用 SSL 连接到 HADR 主要服务器的客户端能够使用 SSL 重新路由到 HADR 备用数据库。但是，HADR 主要和备用服务器之间不支持 SSL。

密钥库是什么？

密钥库 (keystore) 是一个受保护的数据库，其中存储了所有者的 SSL 私钥和数字证书。客户端和服务器都必须拥有密钥库来存储 SSL 通信中使用的数字证书。在大多数系统上，此数据库是文件系统中的一个文件。在 z/OS 上，一个符合 SAF 规范要求的密钥环（比如 RACF 提供的密钥环）常常用作密钥库。我们将在本文的所有例子中使用此方法（尽管我们明确地参考 RACF，但任何符合 SAF 规范要求的安全管理器都可使用）。

密钥库中的每个证书都有一个唯一的标签。

如果未指定标签名称，则使用密钥库中的默认证书来进行 SSL 通信。密钥库中只有一个证书是默认证书。

密钥库位于文件系统中时：

• 在检索 SSL 通信的私钥和数字证书时，可使用密码保护它。
• 密钥库密码以加密形式存储在一个存放 (.sth) 文件中。该存放文件无需显式密码即可打开密钥库。
• 服务器上的密钥库必须使用密码，因为此密码会保护服务器的私钥。
• 在许多情况下，客户端没有自己的私钥和证书。相反，客户端上的密钥库存储客户端正在连接的所有服务器的根 CA 证书。在这些情况下，密钥库的密码是可选的。

对 RACF 密钥环的访问使用 RACF 权限来控制，不使用密码或存放文件。

回页首

SSL 服务器认证的配置步骤

SSL 服务器认证允许用户确认服务器的身份，但不允许服务器确认客户端的身份。在许多情况下，服务器认证提供的认证足够了，是最常用的配置。

启用了 SSL 的客户端软件可使用标准的公钥密码学技术来检查服务器的证书和公钥 ID 是否有效，是否由客户端的受信任 CA 列表中所列出的证书授权中心颁发。在客户端需要保证它连接到正确的服务器时，这个确认步骤很重要。例如，在客户端通过网络发送信用卡号并希望保证连接到实际商家的网站时。

SSL 服务器认证的配置示例

让我们看一个例子。我们使用客户端上的 GSKit 8.0.14.43 和服务器上的 RACF 及 DB2 for z/OS 10.01.0005 来验证这些步骤。

创建一个 CA 证书并将它导出为服务器上一个名为 USRT001.SVL224.CACERT 的文件。与这个 CA 证书相关联的私钥将用于对服务器的个人证书进行签名。该证书文件将发送到客户端。然后可将 CA 证书添加到客户端密钥库数据库，以便客户端可在 SSL 握手期间验证服务器的证书。要创建 CA 证书并将它导出到服务器上的一个文件，可执行以下操作步骤。

在服务器上执行以下操作步骤：

第 1 步.生成一个证书授权中心 (CA) 密钥对和证书。这是一个自签名 CA 证书，所以它是自己的根 CA。

RACDCERT CERTAUTH GENCERT SUBJECTSDN(OU('SVL224ServerC')O('IBM') L('SVL') SP('CA') C('US'))  NOTAFTER(DATE(2030-12-31)) SIZE(2048) WITHLABEL('SVL224ServerCAC') KEYUSAGE(CERTSIGN)

输出：执行时没有错误。

第 2 步.为 DB2 服务器生成一个密钥对和个人证书。

RACDCERT ID(SYSDSP) GENCERT SUBJECTSDN(CN('inec029.vmec.svl.ibm.com')OU('UTEC224') O('SVL224') C('US'))  NOTAFTER(DATE(2030-12-31)) SIZE(2048) WITHLABEL('SVL224ServerCet')  SIGNWITH(CERTAUTH LABEL('SVL224ServerCAC'))

输出：执行时没有错误。

第 3 步. 创建密钥环并添加服务器的 CA 证书。

RACDCERT ID(SYSDSP) ADDRING(DB2KEYRING_SAMPLE) RACDCERT ID(SYSDSP) CONNECT(CERTAUTH LABEL('SVL224ServerCAC') RING(DB2KEYRING_SAMPLE)) TRUST RACDCERT ID(SYSDSP) CONNECT(ID(SYSDSP) LABEL('SVL224ServerCet') RING(DB2KEYRING_SAMPLE) DEFAULT)

输出：执行时没有错误。

第 4 步.显示标签 SVL224ServerCAC 的内容，确认一切正常。

RACDCERT CERTAUTH LIST(LABEL('SVL224ServerCAC'))

第 5 步. 下面这个命令创建需添加到客户端密钥库数据库中的 USRT001.SVL224 CACERT 文件

RACDCERT CERTAUTH EXPORT(LABEL('SVL224ServerCAC')) DSN('USRT001.SVL224.CACERT')

在客户端上执行以下操作步骤：

第 6 步. 创建密钥库数据库

gsk8capicmd_64 -keydb -create -db inec029.kdb -pw password -stash -fips

从服务器获得服务器证书。

FTP labec821.vmec.svl.ibm.com FTP> ascii FTP> mget USRT001.SVL224.CACERT FTP> quit

第 7 步. 将此服务器证书添加到客户端 kdb 中。

gsk8capicmd_64 -cert -add -db inec029.kdb -pw password -file "USRT001.SVL224.CACERT"  -label "SVL224ServerCAC" -format ascii

现在按如下方式建立一个 SSL 连接，应该能成功建立该连接。

$db2cli >opt echo on >opt callerror on opt callerror on >sqlallocenv 1 sqlallocenv 1 SQLAllocEnv: rc = 0 (SQL_SUCCESS) CLI henv = 1, Test Driver henv = 1 >sqlallocconnect 1 1 sqlallocconnect 1 1 SQLAllocConnect: rc = 0 (SQL_SUCCESS) CLI hdbc = 1, Test Driver hdbc = 1 >SQLDriverConnect 1 0 "DATABASE=STLEC1;PROTOCOL=TCPIP;PORT=448;HOSTNAME=labec821.vmec.svl.ibm.com;UID=SYSADM; PWD=c0deshop;security=ssl;SSL_CLIENT_KEYSTOREDB=inec029.kdb;SSL_CLIENT_KEYSTASH=inec029.sth" -3 255 SQL_DRIVER_NOPROMPT SQLDriverConnect 1 0 "DATABASE=STLEC1;PROTOCOL=TCPIP;PORT=448;HOSTNAME=labec821.vmec.svl.ibm.com;UID=SYSADM; PWD=c0deshop;security=ssl;SSL_CLIENT_KEYSTOREDB=inec029.kdb;SSL_CLIENT_KEYSTASH=inec029.sth" -3 255 SQL_DRIVER_NOPROMPT SQLDriverConnect: rc = 0 (SQL_SUCCESS) SQLDriverConnect: ConnStrOut: UID=SYSADM;PWD=c0deshop;DATABASE=STLEC1;PROTOCOL=TCPIP;PORT=448;HOSTNAME=labec821.vmec.svl.ibm.com; SECURITY=SSL;SSL_CLIENT_KEYSTOREDB=inec029.kdb;SSL_CLIENT_KEYSTASH=inec029.sth;
 cbConnStrOut: 178 >quit

回页首

SSL 客户端认证的配置步骤

SSL 客户端认证是 SSL 服务器认证的一种扩展。SSL 客户端认证允许在客户端确认服务器身份后，由服务器确认客户端的身份。

SSL 客户端认证使用的技术与服务器认证的技术相同。借助这些技术，启用了 SSL 的服务器软件可以检查客户端的证书和公钥是否有效，是否由服务器的受信任 CA 列表中所列出的证书授权中心颁发。

这种确认在需要保持机密性的事务中很重要。例如，如果服务器是一家向客户发送机密财务信息且希望检查接收方身份的银行。SSL 客户端认证有时称为相互认证，因为它是客户端与服务器之间的一种双向认证。

下面这个例子给出了直接在客户端和服务器平台上创建证书的命令。创建和获取客户端以及服务器证书的方法根据客户的 PKI 需求和基础架构的不同而不同。另外，该示例使用一个自签名客户端证书，所以这个例子只能用于演示。在客户场景中，可使用由一个单独的 CA 所生成或签名的证书。

图 1. 直接在客户端和服务器上创建证书

以下步骤在客户端上使用 GSKit 8.0.14.43 版并在服务器上使用 RACF 及 DB2 for z/OS 10.01.0005 进行了验证。

要在服务器上创建一个将添加到客户端数据库中、名为 USRT001.SVL224.CACERT 的证书，可执行以下操作步骤。

在服务器上执行以下操作步骤：

第 1 步. 生成一个证书授权中心 (CA) 证书

RACDCERT CERTAUTH GENCERT SUBJECTSDN(OU('SVL224ServerC') O('IBM') L('SVL') SP('CA')C('US'))  NOTAFTER(DATE(2030-12-31)) SIZE(2048) WITHLABEL('SVL224ServerCAC') KEYUSAGE(CERTSIGN)

输出：执行时没有错误。

第 2 步. 为 DB2 服务器生成一个密钥对和个人证书

RACDCERT ID(SYSDSP) GENCERT SUBJECTSDN(CN('inec029.vmec.svl.ibm.com') OU('UTEC224') O('SVL224') C('US'))  NOTAFTER(DATE(2030-12-31)) SIZE(2048) WITHLABEL('SVL224ServerCet')  SIGNWITH(CERTAUTH LABEL('SVL224ServerCAC'))

输出：执行时没有错误。

第 3 步. 创建密钥环并添加服务器的 CA 证书。

RACDCERT ID(SYSDSP) ADDRING(DB2KEYRING_SAMPLE) RACDCERT ID(SYSDSP) CONNECT(CERTAUTH LABEL('SVL224ServerCAC') RING(DB2KEYRING_SAMPLE)) TRUST RACDCERT ID(SYSDSP) CONNECT(ID(SYSDSP) LABEL('SVL224ServerCet') RING(DB2KEYRING_SAMPLE) DEFAULT)

输出：执行时没有错误。

第 4 步.显示标签 SVL224ServerCAC 的内容，确认一切正常。

RACDCERT CERTAUTH LIST(LABEL('SVL224ServerCAC'))

第 5 步. 要创建需添加到客户端密钥库数据库的 USRT001.SVL224.CACERT 文件，可执行以下命令：

RACDCERT CERTAUTH EXPORT(LABEL('SVL224ServerCAC')) DSN('USRT001.SVL224.CACERT')

第 6 步. 显示标签 SVL224ServerCet 的内容

RACDCERT ID(SYSDSP) LIST(LABEL('SVL224ServerCet'))

输出（您的证书 ID、序列号和日期/时间戳将有所不同）

生成一个自签名客户端证书并将它导出到一个名为 EC022.CLIENT1.SSCERTA 的文件中。这个文件将被发送到服务器并添加到服务器的密钥环中。

在客户端上执行以下操作步骤。

第 7 步. 创建客户端的密钥库数据库

gsk8capicmd_64 -keydb -create -db inec029.kdb -pw password -stash -fips

第 8 步. 创建客户端的证书

gsk8capicmd_64 -cert -create -db inec029.kdb -pw password -label clntssl -dn "CN=hotelfvt07.torolab.ibm.com,OU=fvt,O=ibm,C=ca" -default_cert yes -expire 1000  -fips -size 2048 -sigalg SHA256WithRSA

第 9 步. 将该证书提取到一个名为 EC022.CLIENT1.SSCERTA 的文件中。

gsk8capicmd_64 -cert -extract -db inec029.kdb -pw password -label clntssl -target EC022.CLIENT1.SSCERTA -format ascii -fips

通过 FTP 以 ASCII 模式将客户端证书上传到服务器。为此可执行以下命令：FTP labec821.vmec.svl.ibm.com > ascii > put EC022.CLIENT1.SSCERTA

第 10 步. 将服务器的 CA 证书添加到客户端密钥库数据库。

gsk8capicmd_64 -cert -add -db inec029.kdb -pw      password -file "SVL224.CACERT" -label "SVL224ServerCAC" -format ascii

在服务器上执行以下操作步骤。

第 11 步. 在服务器上，将自签名客户端证书添加到 RACF 数据库中。

RACDCERT CERTAUTH ADD('SYSADM.EC022.CLIENT1.SSCERTA') WITHLABEL('CLIENTSSC') TRUST

输出：The certificate that you are adding is self-signed. The certificate is added with TRUST status. ***（您正在添加的证书是自签名证书。该证书已添加并具有 TRUST 状态。***）

第 12 步. 显示标签 CLIENTSSC 的内容，确保一切正常

RACDCERT CERTAUTH LIST(LABEL('CLIENTSSC'))

第 13 步. 将自签名客户端证书连接到服务器的密钥环。

RACDCERT CONNECT(CERTAUTH LABEL('CLIENTSSC') RING(DB2KEYRING_SAMPLE) USAGE(CERTAUTH)) ID(SYSDSP)

没有输出意味着已成功连接。

第 14 步. 显示该密钥环，确保一切正常

RACDCERT LISTRING(DB2KEYRING_SAMPLE)ID(SYSDSP)

第 15 步. 使用以下命令创建一个证书名过滤器 (CNF)，并通过 refresh 命令激活该证书名。在 SSL 握手期间，将使用此过滤器确定哪个 z/OS 用户 ID 与客户端证书相关联。

RACDCERT MAP ID(USRT001) SDNFILTER('CN=hotelfvt07.torolab.ibm.com.OU=fvt.O=ibm.C=ca') WITHLABEL('IBMers') TRUST SETROPTS RACLIST(DIGTNMAP) REFRESH

在客户端中完成第 16 步。

第 16 步. 在客户端机器中测试 SSL 连接。连接和数据获取应成功完成。

$db2cli opt callerror on opt echo on SQLAllocEnv 1 SQLAllocconnect 1 1 sqldriverconnect 1 0 "database=STLEC1;hostname=labec821.vmec.svl.ibm.com;port=448;SSLCLIENTLABEL=clntssl; authentication=certificate; SSLClientKeystoredb=inec029.kdb;SSLClientKeystoreDBPassword=password;" -3 500 sql_driver_noprompt  sqlallocstmt 1 1 sqlexecdirect 1 "select count(*) from sysibm.systables" -3 fetchall 1  >quit

输出：客户端连接并提供了查询的结果。

有关该配置的更多信息，请参阅 IBM 红皮书 DB2 for z/OS：配置 TLS/SSL 来实现安全的客户端/服务器通信 。

配置错误场景和解决方案

场景 1. 如果未正确创建证书名过滤器（在第 15 步中创建的），就会出现一个错误。

sqldriverconnect 1 0 "database=STLEC1;hostname=labec821.vmec.svl.ibm.com;port=448; SSLCLIENTLABEL=clntssl;authentication=certificate; SSLClientKeystoredb=inec029.kdb;SSLClientKeystoreDBPassword=password;" -3 500 sql_driver_noprompt SQLDriverConnect: rc = -1 (SQL_ERROR) SQLError: rc = 0 (SQL_SUCCESS) SQLError: SQLState : 08001 fNativeError : -30081 szErrorMsg : [IBM][CLI Driver] SQL30081N A communication error has been detected. Communication protocol being used: "TCP/IP".  Communication API being used: "SOCKETS".  Location where the error was detected: "9.30.219.110". Communication function detecting the error: "recv".  Protocol specific error code(s):"10054", "*", "*". SQLSTATE=08001 cbErrorMsg : 335 SQLError: rc = 100 (SQL_NO_DATA_FOUND)

服务器上的错误消息如下所示。RC 值为 5002。

0010 JOBNAME: VA1ADIST USERID: SYSDSP RULE: VA1ASecureServer RC: 5002 0010 Initial Handshake 7EAA4E18 7EB1A218 TLSV1.1 02 0010 DSNL511I @ DSNLIENO TCP/IP CONVERSATION FAILED 982 0010 TO LOCATION::FFFF:9.77.67.176

有关 SSL 函数返回代码的更多细节，请参阅 IBM 知识中心中的这篇文档。

场景 2. 如果从客户端向服务器发送证书文件时未使用 ASCII 模式，尝试将该证书添加到服务器时会出现以下错误。

RACDCERT CERTAUTH ADD('SYSADM.EC022.CLIENT1.SSCERTA') WITHLABEL('CLIENTSSC') TRUST  “The input data set does not contain a valid certificate."

场景 3. 在服务器上，收到该文件时未使用 ASCII 模式时，gsk8capicmd_64 命令本身会给出错误 CTGSK3046W。

220 Connection will close if idle for more than 5 minutes. User (labec821.vmec.svl.ibm.com:(none)): usrt001 331 Send password please. Password: 230 USRT001 is logged on. Working directory is "USRT001.". FTP> bin 200 Representation type is Image FTP> mget SVL224.CACERT 200 Representation type is Image mget SVL224.CACERT? yes 200 Port request OK. 125 Sending data set USRT001.SVL224.CACERT 250 Transfer completed successfully. FTP: 944 bytes received in 0.00Seconds 944.00Kbytes/sec. FTP> bye 221 Quit command received. Goodbye.   C:/Program Files/ibm/gsk8/bin>gsk8capicmd_64 -cert -add -db  inec029.kdb -pw password -file "SVL224.CACERT" -label "SVL224ServerCAC" -format  ascii   CTGSK3046W The key file "SVL224.CACERT" could not be imported.

用户响应：在服务器上，只能在 ASCII 模式下收到该文件。

SSL 客户端认证的用例

许多 DB2 for z/OS 用户目前正转换为 SSL 客户端认证，以消除在服务器上存储和管理数据库密码的需要。通过使用 AT-TLS 和 DB2 for z/OS 的高级客户端认证特性，客户端的 SSL 证书与一个关联的 z/OS 用户 ID 之间的映射可消除提供用户 ID 和密码的需要。

在一个客户端认证用例中，客户想使用该证书认证与 DB2 的连接，但需要一个不同的数据库授权 ID 来获得访问数据所需的数据库特权。所以客户能够部署客户端证书，但使用该证书只能连接到 DB2，而没有访问数据的特权。

基于证书的认证让您无需提供密码来向 DB2 进行认证。但这也意味着需要小心地控制证书和相关联的私钥。在非常注重安全性的实现中，用户有一个包含其证书的智能卡。应用程序要求用户将其智能卡插入到一个读卡器中并输入一个 PIN 来解锁该智能卡。这种方式可安全地为应用程序提供证书和私钥，从而在 SSL 握手中使用它们。

可以将密钥库数据库视为智能卡，将密钥库数据库的密码视为 PIN。这个密码是保护密钥库数据库的合适机制。存放文件的唯一用途是允许一个服务器在没有用户干预的情况下启动，但它不适合用户认证。需要有一个选项允许用户指定密码来解锁密钥库数据库，因为这是用户认证的一般用途。

基于证书的认证要求用户提供其密钥库数据库的路径和名称以及认证密码，以解锁该密钥库数据库。共享的密钥库数据库和共享的密码或存放文件不是出色的用户认证安全设计。

将用户 ID 与 DB2 for z/OS 中的证书相关联

RACF 提供了一些方式来将用户 ID 与证书关联。两种最常用的方法是证书与用户 ID 的一对一关联和证书名过滤。

• 证书与用户 ID 的一对一关联 ：生成一个证书或将以前生成的证书存储在 RACF 中时，将该证书添加到 RACF 数据库时会向一个用户 ID 注册。此方法在每个证书和一个特定的用户 ID 之间建立一种直接的一对一关联或映射。已注册的证书存储在证书概要文件中。这些概要文件包含证书的准确副本，对于系统上的用户 ID，还包含私钥（如果存在）。以这种方式存储的证书可用于将一个证书与一个用户 ID 相关联，或者可将证书收集到一个集合或密钥环中，供其他应用程序用作一个安全网络协议的一部分。
• 证书名过滤 ：证书名过滤器 (CNF) 允许您根据与证书中的主体或颁发方区分名的各部分相关的规则，将许多证书与一个用户 ID 相关联。不同于一对一关联，使用 CNF 允许您在一个客户端的身份和一个 z/OS 用户 ID 之间建立映射，而无需将客户端的证书存储在 RACF 数据库中。这在使用 CA 签署客户端证书时很重要。

支持 SSL 客户端认证的 V9.7 FP6 CLI 增强

早期的 CLI 支持通过两个 SSL 参数来指定密钥库数据库和存放文件的位置，这个两个参数分别是 SSLClientKeystoredb 和 SSLClientKeystash。作为 V9.7 FP6 CLI 增强的一部分，现在公开了一个参数来指定在密钥库数据库中唯一标识证书的 SSL 标签。这很有必要，因为这样就可以使用密钥库数据库中默认证书以外的其他证书。要指定认证中需要使用的标签（映射到一个特定的证书），可使用数据服务器驱动程序 (db2dsdriver.cfg) 配置参数 'SSLClientLabel'（等效于 db2cli.ini 中的 SSLClientLabel 关键字）。

要允许用户使用 SSL 证书作为机制来认证客户端并与客户端支持的其他认证方法区分开，可在 db2dsdriver.cfg 参数 'Authentication' 中使用值 ‘CERTIFICATE’。

如果 'Authentication' 选项有新值 'CERTIFICATE'，则新标签参数 'SSLClientLabel' 必须存在。否则将返回一个错误（即没有尝试使用密钥库数据库的默认标签）。

无论是否设置了 db2dsdriver.cfg 属性 'SecurityTransportMode'（等效于 db2cli.ini 中的 'Security' 关键字），都支持包含新值 'CERTIFICATE' 的 'Authentication' 选项。所以，如果将 'SecurityTransportMode' 设置为 'SSL' 且 'Authentication' 设置为 'CERTIFICATE'，那么您可以实现数据加密以及加密的认证。类似地，如果 'SecurityTransportMode' 未被设置为 'SSL' 且 'Authentication' 设置为 'CERTIFICATE'，那么将进行基于证书的客户端认证而不加密数据流。

您可通过启用工作负载平衡 (WLB) 或自动客户端重新路由 (ACR) 来支持认证类型 CERTIFICATE。如果备用分组为该证书使用的配置与主要分组的配置相同，备用分组也将支持该类型。

通过现有客户端的 SSLClientKeystash 关键字指定 SSL 密钥库数据库密码，会强制用户将存放文件保留在文件系统上。对许多客户而言，这是一个安全问题，因为能够访问这个存放文件可使几乎任何用户都能使用其他人的 SSL 证书连接到该数据库。为了避免出现此问题，您可提供一种替代机制来指定密钥库数据库密码，而不将某个文件存储在文件系统中。要想更好地控制证书，可使用一个新的 db2dsdriver.cfg 参数 'SSLClientKeystoreDBPassword'（等效于 db2cli.ini 中的 'SSLClientKeystoreDBPassword' 关键字和一个连接字符串）。参数 'SSLClientKeystoredb' 提供了密钥库数据库的路径和名称。'SSLClientKeystoreDBPassword' 参数与 ‘SSLClientKeystash’ 参数相互排斥。在 db2dsdriver.cfg 或 db2cli.ini 文件中指定此值会导致一个安全漏洞。

为基于认证的证书指定一个用户 ID

如果 authentication 参数设置为 CERTIFICATE，您可选择在初始连接期间通过 db2dsdriver.cfg 参数 'UserID' 或通过 db2cli.ini 参数 'UID' 或通过连接字符串关键字来指定用户 ID 信息。

如果未指定 "userID"，那么将使用与 SSL 证书关联的用户 ID 作为剩余连接的常规用户 ID。

图 2. 未指定用户 ID 时的场景

如果在这个场景中指定了用户 ID 信息 (X)，而且如果这个用户 ID (X) 和与 CERTIFICATE 关联的用户 ID (Y) 之间存在信任，那么一个已连接的服务器将尝试建立一个隐式的受信任连接。如果该连接需要认证，服务器将拒绝连接请求（来自服务器的 SQL20361N 和原因代码 '1' 将返回给应用程序）。建立隐式受信任上下文后，将为剩余的连接激活指定的用户 ID (X)。

图 3. 提供了用户 ID 时的场景

要建立受信任的上下文，CLI 中不应出现任何其他配置。例如，现有的 SQL_ATTR_USE_TRUSTED_CONTEXT 属性（用于显式受信任的上下文）在此上下文中毫不相关。

为基于认证的证书指定一个密码

因为认证基于一个证书，所以在 db2dsdriver.cfg 中指定 "password"（或在 db2cli.ini 文件或连接字符串中指定 PWD）是一种无效的组合，并会向应用程序返回一个 SQL 错误。

在认证方式为 CERTIFICATE 时的 [显式] 受信任上下文行为

• 一旦建立了使用 authentication=‘CERTIFICATE’ 的连接，现有的（显式）受信任上下文行为会保持不变（通过使用 SQL_ATTR_TRUSTED_CONTEXT、SQL_ATTR_TRUSTED_CONTEXT_USERID，或它们的等效 db2dsdriver.cfg 和连接字符串关键字）。
• 但是，如果指定了 SQL_ATTR_TRUSTED_CONTEXT_PASSWORD，就会返回 -30082N 和原因代码 41，同时该连接将被丢弃。

下面是一个示例 db2dsdriver.cfg 文件。

<configuration> <dsncollection>     <dsn alias="DSN1" name="ACO1" host="host1.ibm.com" port="5912">         <parameter name="SSLClientKeystash" value="/home/test1/keystore/clientstore.sth"/>         </dsn>         <dsn alias="DSN2" name="ACO2" host="host2.ibm.com" port="5912/">         <dsn alias="DSN3" name="ACO3" host="host3.ibm.com" port="5912/"> </dsncollection>  <database> <database name="ACO1" host="host1.ibm.com" port="5912">         <parameter name="Authentication" value="CERTIFICATE"/>         <parameter name="UserID" value="userid"/>         <parameter name="SSLClientLabel" value="labelname1"/> </database>      <database> <database name="ACO2" host="host2.ibm.com" port="5912">         <parameter name="Authentication" value="CERTIFICATE"/>         <parameter name="UserID" value="userid"/>         <parameter name="SSLClientKeystoreDBPassword" value="password2"/>         <parameter name="SSLClientLabel" value="labelname2"/> </database>  <database> <database name="ACO3" host="host3.ibm.com" port="5912">         <parameter name="Authentication" value="CERTIFICATE"/>         <parameter name="UserID" value="userid"/>         <parameter name="SSLClientLabel" value="labelname1"/> </database> </databases>  <parameters>     <parameter name="SSLClientKeystoredb" value="/home/test1/keystore/clientstore.kdb"> </parameters> </configuration>

在上面的 db2dsdriver.cfg 文件中，存在以下事实：

• 对于 DSN1，使用 SSLClientKeystash 来获取密钥数据库文件的已加密密码。
• 对于 DSN2，仅使用 SSLClientKeystoreDBPassword 来提供密钥库数据库的密码（出于安全原因，不推荐在 db2dsdriver.cfg 中提供密码）。这个例子仅用于说明用途。
• 对于 DSN3，可通过连接字符串传递 SSLClientKeystoreDBPassword ，如下所示。推荐通过这种方法在运行时提供 SSL 客户端的密码。SQLDriverConnect (......"DSN=DSN3;SSLClientKeystoreDBPassword=password;.......")
• 'Authentication' 属性的大写字母值 'CERTIFICATE' 用于演示用途。该值不区分大小写。

限制

• 所提议的认证机制适用于客户端与 z/OS 服务器之间的直接连接。客户端与 z/OS 服务器之间的网关不支持这种机制。在客户端与 z/OS 服务器之间存在 DB2 Connect Server，而且 Authentication 字段设置为 "Certificate" 的场景中，会向应用程序返回 -30082 和原因代码 15。目前不支持 DB2 Connect Server。
• 不支持数据库目录。应用程序必须使用连接字符串 dsdriver.cfg 或 cli.ini 来指定这种认证机制。
• 这种支持仅添加到 CLI / ODBC 中。不支持其他 API，比如嵌入式 SQL 和 CLP。

其他主要说明：

• SSL 或 TCPIP 上支持基于证书的认证。
• DB2 客户端始终在 FIPS 模式下初始化 GSKit。在 SSL 上，我们在 FIPS 模式下操作。在 TCPIP 上，我们不在 FIPS 模式下操作。
• 所称的 "SSL" 是请求了 SSL 连接的场景。客户端与服务器之间的数据流将被加密。所称的 "TCP/IP" 是请求了常规的非 SSL 连接的场景。不会对数据流进行任何加密。在这两种情况下，需要基于证书的认证时，服务器会使用 TLS 认证客户端证书。直观地讲，没有数据加密且基于证书的认证（我们称之为 "TCP/IP"），其执行性能要更好。
• 如果关键字 "Security" 未设置为 "SSL"，则意味着提供了基于证书的认证而未加密数据流。如果 "Security" 设置为 "SSL"，则数据也会被加密。
• DB2 for Linux, UNIX, and Windows (LUW) 不会从 GSKit 获取证书。DB2 for LUW 向 GSKit 提供证书的标签。GSKit 不会立即验证密钥数据库中是否存在该标签。在 SSL 客户端认证握手期间，GSKit 使用该标签在密钥数据库中查找该证书。

使用自动客户端重新路由 (ACR) 时的 SSL 客户端认证行为

一个服务器或客户端（首先是主要服务器）宕机时，连接将故障转移到备用服务器列表上的下一个成员。出现此情况时，会发生与主要连接类似的常规 authentication=CERTIFICATE 握手。如果初始连接期间已在客户端与服务器之间建立了必要的信任关系，那么这可能是一种额外的开销（尤其是在单集群环境中）。

回页首

为连接关键字提供错误值时的错误场景和解决方案

sqldriverconnect 1 0 "database=STLEC1;hostname=labec821.vmec.svl.ibm.com;port=448; SSLCLIENTLABEL=clntssl1;authentication=certificate;SSLClientKeystoredb=inec029.kdb; SSLClientKeystoreDBPassword=password;" -3 500 sql_driver_noprompt SQLDriverConnect: rc = -1 (SQL_ERROR) SQLError: rc = 0 (SQL_SUCCESS) SQLError: SQLState : 08001 fNativeError : -30081 szErrorMsg : [IBM][CLI Driver] SQL30081N  A communication error has been detected. Communication protocol being used: "SSL".  Communication API being used: "SOCKETS".  Location where the error was detected: "".  Communication function detecting the error: "sqlccSSLSocketSetup".  Protocol specific error code(s): "406", "*", "*". SQLSTATE=08001

sqldriverconnect 1 0 "database=STLEC1;hostname=labec821.vmec.svl.ibm.com;port=448; SSLCLIENTLABEL=clntss;authentication=certificate;SSLClientKeystoredb= inec029.kdb;SSLClientKeystoreDBPassword=password;" -3 500 sql_driver_noprompt SQLDriverConnect: rc = -1 (SQL_ERROR) SQLError: rc = 0 (SQL_SUCCESS) SQLError: SQLState : 08001 fNativeError : -30081 szErrorMsg : [IBM][CLI Driver] SQL30081N  A communication error has been detected.  Communication protocol being used:"SSL."  Communication API being used: "SOCKETS."  Location where the error was detected: "".  Communication function detecting the error:"sqlccSSLSocketSetup."  Protocol specific error code(s): "420", "*", "*". SQLSTATE=08001

场景 3. SSLClientKeystoreDBPassword 值是错误的。

sqldriverconnect 1 0 "database=STLEC1;hostname=labec821.vmec.svl.ibm.com;port=448; SSLCLIENTLABEL=clntssl;authentication=certificate; SSLClientKeystoredb=inec029.kdb;SSLClientKeystoreDBPassword=WWpasswod;" -3 500 sql_driver_noprompt  SQLDriverConnect: rc = -1 (SQL_ERROR) SQLError: rc = 0 (SQL_SUCCESS)  SQLError: SQLState : 42724 fNativeError : -1109 szErrorMsg : [IBM][CLI Driver] SQL1109N  The specified DLL "GSKit Error: 408" could not be loaded. SQLSTATE=42724 cbErrorMsg : 102

场景 4. SSLClientKeystoredb 值没有错。

sqldriverconnect 1 0 "database=STLEC1;hostname=labec821.vmec.svl.ibm.com;port=448; SSLCLIENTLABEL=clntssl;authentication=certificate; SSLClientKeystoredb=inec029.kb;SSLClientKeystoreDBPassword=password;" -3 500 sql_driver_noprompt SQLDriverConnect: rc = -1 (SQL_ERROR) SQLError: rc = 0 (SQL_SUCCESS) SQLError: SQLState : 42724 fNativeError : -1109 szErrorMsg : [IBM][CLI Driver] SQL1109N  The specified DLL "GSKit Error: 202" could not be loaded. SQLSTATE=42724  cbErrorMsg : 102

场景 5. 端口值是错误的。

sqldriverconnect 1 0 "database=STLEC1;hostname=labec821.vmec.svl.ibm.com;port=447; SSLCLIENTLABEL=clntssl;authentication=certificate; SSLClientKeystoredb=inec029.kdb;SSLClientKeystoreDBPassword=password;" -3 500 sql_driver_noprompt SQLDriverConnect: rc = -1 (SQL_ERROR) SQLError: rc = 0 (SQL_SUCCESS) SQLError: SQLState : 08001 fNativeError : -30081 szErrorMsg : [IBM][CLI Driver] SQL30081N  A communication error has been detected.  Communication protocol being used: "SSL."  Communication API being used: "SOCKETS." Location where the error was detected: "".  Communication function detecting the error: "sqlccSSLSocketSetup."  Protocol specific error code(s): "410", "*", "*". SQLSTATE=08001  cbErrorMsg : 333

场景 6. 为 authentication 关键字提供了一个无效值。

sqldriverconnect 1 0 "database=STLEC1;hostname=labec821.vmec.svl.ibm.com;port=448; SSLCLIENTLABEL=clntssl;authentication=certificate; SSLClientKeystoredb=inec029.kdb;SSLClientKeystoreDBPassword=password;" -3 500 sql_driver_noprompt SQLDriverConnect: rc = -1 (SQL_ERROR) SQLError: rc = 0 (SQL_SUCCESS) SQLError: SQLState : HY000 fNativeError : -99999 szErrorMsg : [IBM][CLI Driver] CLI0222E  Authentication failed because the SSLClientLabel parameter was specified but the DB2 client or data server driver was not configured to use certificate-based authentication.   SQLSTATE=HY000 cbErrorMsg : 216 SQLError: rc = 100 (SQL_NO_DATA_FOUND)

场景 7. 为 database 关键字提供了一个错误值。

sqldriverconnect 1 0 "database=STLE1;hostname=labec821.vmec.svl.ibm.com;port=448; SSLCLIENTLABEL=clntssl;authentication=certificate; SSLClientKeystoredb=inec029.kdb;SSLClientKeystoreDBPassword=password;" -3 500 sql_driver_noprompt SQLDriverConnect: rc = -1 (SQL_ERROR) SQLError: rc = 0 (SQL_SUCCESS) SQLError: SQLState : 08004 fNativeError : -30061  szErrorMsg : [IBM][CLI Driver] SQL30061N  The database alias or database name "STLE1 " was not found at the remote node. SQLSTATE=08004

10.5 FP5 中的 SSL 连接过程

从 10.5 FP5 开始，SSL 连接过程被简化了。

在前面的步骤中您已看到，要在 DB2 客户端和服务器端配置 SSL 支持，您需要从 IBM 网站下载 GSKit 包，安装它，然后使用 IBM Global Security Kit (GSKit) 所提供的 GSKCapiCmd 工具。我们为 DB2 云服务产品使用客户端驱动程序时，下载和安装 GSKit 是一个很麻烦的过程。并且很难使用 GSKCapiCmd 工具/可执行程序来管理密钥数据库和创建 SSL 连接。

出于此原因，人们简化了基于实例的客户端的 SSL 连接过程，以便应用程序可设置 SECURITY=SSL，并且与服务器的 SSL 连接应该能正常工作。另外，CLI 驱动程序开始通过一个连接字符串来接受 SSL 连接的自签名证书文件。

默认情况下，DB2 服务器安装程序附带了一个完整的 GSKit 包。但客户端安装程序（包括基于实例的和非基于实例的客户端）仅附带了 GSKit crypto- 库。该库用于客户端加密。要想消除为 SSL 连接安装单独 GSKit 包的这种依赖性，对于每个应用程序进程所需的客户端包，该包所需的 GSKit 库都已包含在该包中。

所以，借助新解决方案，要使用 CLI 通过 SSL 连接到一个数据库，您不需要下载和安装单独的 GSKit 包来配置 SSL。应用程序不需要使用 GSKCapiCmd 工具来创建密钥数据库或存放文件。应用程序也不需要传递 SSLClientKeystoredb、SSLClientKeystoreDBPassword 或 SSLClientKeyStash 关键字的值。建立 SSL 连接所需的步骤将以编程的方式来处理。但是，如果您想使用现有的机制，通过使用配置关键字来建立 SSL 连接，那么仍可创建自己的密钥数据库。

对于每个进程，在分配第一个环境句柄期间，CLI 将使用应用程序进程 ID 在内部生成一个唯一的默认密钥数据库名和相应的密钥数据库密码，并将它们存储在全局变量中。在请求与数据库建立连接时，如果设置了 “SECURITY=SSL” 且用户没有为 SSLClientKeystoredb 关键字提供值，则会使用默认密钥数据库作为 SSLClientKeystoredb 关键字的值。并且使用默认密钥数据库密码作为 SSLClientKeystoreDBPassword 关键字的值。

如果 DB2 服务器正在使用一个自签名证书，那么应用程序需要将 “Security=SSL;SSLServerCertificate=(certificate_file_path)” 传递给 CLI。SSLServerCertificate 是一个新的连接字符串关键字。CLI 首先将这个 SSLServerCertificate 文件添加到密钥数据库中，然后继续建立 SSL 连接。新关键字 SSLServerCertificate 可用于传递服务器的自签名证书或服务器的 CA 证书。所以可使用此方法建立 SSL 连接，方法是利用受信任的 CA（预先填充的 GSKit CA 证书列表中没有其 CA 证书）所签署的服务器证书。

SSLServerCertificate 可用于现有的密钥数据库，无论是用户使用 GSKCapiCmd 工具创建的数据库，还是 CLI 驱动程序在为该应用程序进程建立第一个 SSL 连接期间所创建的默认密钥数据库。要将证书添加到密钥数据库中，您必须传递证书的一个唯一 LABEL。在将这个 SSLServerCertificate 添加到密钥数据库时，客户端驱动程序将使用证书文件路径（作为 SSLServerCertificate 关键字的值传递）作为 LABEL。这一步可确保客户端系统中一个特定位置的证书只会在密钥数据库中存储一次。

驱动程序代码所形成的默认密钥数据库文件名具有以下格式：client_(PID).kdb

使用 GSKit Key Management API 将已创建的密钥数据库文件存储在磁盘上：

• 对于基于实例的客户端：在 (instance_path)/cfg/ 目录下。
• 对于无实例的客户端：在 (install_path)/cfg 目录下。

一个进程的所有线程将为 SSL 连接使用相同的 SSLClientKeystoredb 和 SSLClientKeystoreDBPassword。所创建的默认密钥数据库文件将在应用程序进程的生存期中一直存在，并在该进程正常退出时被删除。如果应用程序进程异常终止，则不会清理这些密钥数据库文件，它们将保留在磁盘上。如果没有活动的应用程序进程了，您可手动删除这些文件。

IBM DashDB 中的 SSL 连接进程

IBM 通过 IBM Cloud 服务产品提供 DashDB 和 SQLDB 服务。通过该 IBM Cloud 服务产品创建的所有 DashDB 和 SQLDB 实例将使用同一个证书：由 DigiCert Inc 验证的、用于 TCP/IP with SSL 连接的 DigiCert Global Root CA Certificate。目前，所有 DashDB 和 SQLDB 用户都需要通过 Web 控制台登录并下载该 CA 证书，然后在应用程序中使用该证书来建立 SSL 连接。您需要通过 SSLServerCertificate 关键字在连接字符串中提供相同的证书。

IBM DashDB 和 SQLDB 服务使用由 DigiCert Inc 认证的 DigiCert Global Root CA Certificate DigiCertGlobalRootCA.arm 来建立 SSL 连接。为了简化为 IBM DashDB 和 SQLDB 使用 SSL 连接的方法，DB2 CLI 驱动程序在所有客户端包中捆绑了这个 CA 证书。应用程序没有通过一个用于 SSL 连接的 SSLClientKeystoredb 参数指定用户创建的密钥库数据库时，DB2 CLI 驱动程序会将这个证书添加到所创建的默认密钥数据库中。使用此证书，TCP/IP with SSL 连接将成功连接到 IBM DashDB 和 SQLDB 服务，因为这是它们使用的默认证书。

如果用户通过 SSLClientKeystoredb 关键字指定密钥库数据库，则不会将 DigiCert 添加到密钥库数据库中，所以不会使用 DigiCert。此时只会使用用户指定的密钥库数据库中存在的证书来尝试进行连接。

DB2 CLI 使用相同的名称将 DigiCert Global Root CA 证书 ( DigiCertGlobalRootCA.arm) 打包到以下位置。

• 对于基于实例的客户端：在 (instance_path)/cfg/ 目录下。
• 对于无实例的客户端：在 ()install_path)/cfg 目录下。

捆绑此证书后，所有 CLI 应用程序都可在连接字符串中指定 Security=SSL 或在 db2dsdriver.cfg 中指定 SecurityTransportMode=SSL，通过 TCP/IP with SSL 连接到数据库服务器。应用程序不需要通过 SSLServerCertificate 关键字来指定证书。

致谢

感谢 Bimal K Jha 和 Sujan S. Ghosh 帮助我们完成本文。