在WebSphere MQ 网络上规划 SSL

T.Rob Wyatt, 高级管理顾问, IBM

在每个专栏中，“任务：消息”讨论的主题旨在鼓励您重新检查您对 IBM® WebSphere® MQ 及其在您的环境中的作用的看法，以及为什么您应该定期注意它。

让您的解决方案精益求精

这个月，我在这里就您的 New Year 解决方案向你们提供一些帮助——当然，假定您的解决方案是在消息传递网络上启用 SSL。

随着启用 SSL 的商店数量的增加，我也有机会接触许多实现了 SSL 的 WebSphere MQ 管理员，而且我注意到了以下两种倾向：

• 第一种倾向是，虽然要检查 SSL 配置以确保它们允许预期的连接，但是没有足够的检查来确保这些连接仅是可以接受的连接。结果，许多这样的配置会不知不觉地允许远远超过预期数量的连接，甚至会达到允许匿名连接的程度。
• 我注意到的第二种倾向是，许多 SSL 配置允许不适当的管理访问权，这通常是因为不知道如何将 SSL 身份验证应用于 WebSphere MQ API 调用。

本文将重点解决这两个问题，因此，如果您刚开始实现 SSL，本文也许可以帮助您避免这些缺陷。如果您已经部署了 SSL，您可能会发现这里的一些建议可帮助您进行严密的部署。

为什么使用 SSL？

安全套接字层（通常被称为 SSL）可提供以下三种服务：

• 使用加密提供机密性。如果有窃听者捕获到了流经网络的消息，则加密可以确保无法（或者其代价高得不可接受）将该数据转换为可用的纯文本。在 WebSphere MQ 中有许多不同的加密类型，它们使用各种算法和密钥长度。甚至还可能在无任何加密的通道中启用 SSL。
• 通过将消息进行哈希处理提供完整性。哈希非常类似于指纹，通过构建哈希算法，即使是源中的最小更改也会产生完全不同和不可预知的哈希值。当消息到达其目的地时，哈希可以在一定程度上保证该消息不被篡改。完整性功能不是可选功能。当针对 WebSphere MQ 通道启用 SSL 时，该通道上的所有消息都会被哈希处理和验证。
• SSL 中使用的证书包含标识信息，并被压缩在一个加密的信封中以防篡改。该证书的标识信息是 SSL 身份验证的基础。在 WebSphere MQ 通道启动之前 SSL 协议使用自己的消息交换方式，正是在此 SSL 握手期间进行服务器（也可以是客户端）身份验证。在此情况下，“客户端”用于启动连接。它可以是连接到 WebSphere MQ 客户端通道的应用程序或用户，也可以是其他队列管理器。类似地，在此上下文中是“服务器”用于接收该连接请求。

但是，基于 SSL 证书进行身份验证究竟意味着什么？理解该问题答案的关键是使用 SSL 构建有意义安全性的关键。

已通过身份验证：SSL 定义

队列管理器有一个在进行 SSL 交换期间使用的证书数据库。该数据库有一部分称为密钥存储区，它包含用于对要发送的数据进行签名的所有证书。该队列管理器与必须在密钥存储区中提供的单一证书关联。密钥数据库中的另一部分是信任存储区，它包含由该队列管理器信任的数据的所有公钥。当创建该数据库时，该信任存储区由商业证书颁发机构提供的一套缺省密钥填充。目前，这些证书颁发机构包括 Entrust、Verisign、Thawte 和 RSA。

当提供证书时，用来进行身份验证的条件非常简单：该证书是否已由信任存储区中的证书颁发机构签过名？如果已签名，则接受该证书，且该部分的 SSL 交换即告完成。

假定证书示例是由商业证书颁发机构颁发的。证书的完整性是使用哈希算法校验的。接下来，检查签名 CA 的证书是否存在于本地信任存储区中。如果是，则候选证书将被接受。注意，不必提前保存候选证书的副本。只有给所提供证书签名的机构是受信任机构时才需要。

就其本身而言，在 WebSphere MQ 上下文中并不是十分有用。由缺省的商业 CA 之一签名的任何证书都会被接受，从所有实际用途来看，这意味着任何人都可以进行连接。幸运的是，WebSphere MQ 提供了一些附加工具，它们缩小了可以连接的范围。

过滤不需要的连接

证书包含几种类型的标识信息，其中一项就是专有名称，即 DN。该名称的专有性在于任何来自同一 CA 的两个证书都没有相同的标识。来自给定证书颁发机构的每个证书都是唯一的。此外，著名的证书颁发机构需要先验证请求者的身份，然后才会颁发证书。CA 部分的这些前期工作提供了信任绑定到该证书的标识的基础。该证书中的标识还被设计为计算机可读形式。WebSphere MQ 将利用三种特征——唯一性、可依赖性和计算机可分析性——来提供过滤机制。

DN 包含几个字段，其中包括通用名 (CN)、组织 (O)、组织单位 (OU) 和国家/地区 (C)。（还有更多，但是，为便于阅读，所举示例中仅应用这些字段。）CN 字段通常包括服务器或队列管理器名称。O 字段包括向其颁发证书的公司。一个或多个 OU 字段包括公司中的限定符，如分支或业务部门。有效 DN 将如下所示：

DN="CN=VENUS,OU=ISSW,O=IBM,C=US"

通道的 SSLPEER 属性使管理员能够指定与 DN 内的各种字段匹配的值，以便构建规则。可以指定各个值、通配符，甚至是整个 DN。根据所选择的值，过滤的结果可以从极为任意的 DN 到能够指定单个可接受的 DN。例如，设置 SSLPEER('C=US') 将允许在美国颁发的任何证书进行连接。较为有用的指定可能是 SSLPEER('O=IBM')，这将过滤出组织字段不包括字符串“IBM”的任何请求。注意，尽管 O=IBM 比 C=US 提供更好的过滤，但这两种方法均太宽泛，不能视为非常有用的过滤。在实际的实现中，始终要选择可满足业务需求的最具限制性的过滤，从完全限定的 DN 开始，然后再从此返回。

在使用 RCVR、RQSTR 或 SVR 通道时，匹配单个证书非常有用，因为这些通道通常只与一个合作伙伴节点连接。匹配多个证书的通用过滤器对于 SVRCONN 和 CLUSRCVR 通道来说非常有用，它们通常需要接受来自各个客户端节点的连接。

在为证书 DN 设计命名转换时进行提前规划非常必要。乍看上去，匹配公司名称似乎就足够了，但是，随着时间的推移会出现更多的要求。例如，作为组织单位的一部分，包括诸如 DEV、TEST、QA、PROD 之类的值非常有用。如果有多个集群，将集群名作为一个 OU 字段非常有用。为了匹配多个证书，这些 OU 字段必须跨证书保持一致并按同一顺序显示。应按越来越具体的顺序排列 OU 字段，这是因为 SSLPEER 需要从左到右指定 OU 节点。例如，假定 DN 包含 U=IBM,OU=ISSW,OU=PROD，则 U=ISSW,OU=PROD 的 SSLPEER 字符串将无效，但是 U=*,OU=ISSW,OU=PROD 仍有效。

证书一旦颁发，证书 DN 将无法更改。如果发生错误，代价会非常高，因此，要了解 SSLPEER 的工作原理，先使用自签名证书测试您的过滤，然后再从商业 CA 那里购买永久证书。SSLPEER 字段允许在 z/OS 平台上使用 256 个字符，在分布式平台上使用 1024 个字符。另一方面，DN 可以为任意长度。如果该 DN 长度超过了 SSLPEER 字段的容量，则需要使用通配符来匹配，这将为接受非预期连接打开方便之门。

如果该 SSLPEER 属性未提供足够的粒度，可以使用安全出口根据任意一套规则评估 DN 和过滤器。流行的 BlockIP2 通道出口使管理员能够提供一个由完全限定的名称或使用通配符的专有名称组成的列表，以供检查。

再次访问证书交换

使用 SSLPEER 或出口，SSL 握手将更加有用。但仍需要基本检查，这意味着证书签名者必须存在于信任存储区中。此外，现在还有第二项检查，目的是让证书标识匹配某个字符串，管理员已将该字符串设计为过滤出除已知合法用户之外的所有用户。需要基于 DN 中的值（如通用名、公司名和集群名）将 SSLPEER 值设计为匹配单个唯一 DN 或者进行一般匹配。当匹配多个证书时，需要选择最窄的规范。

这里必须指出的是，自签名证书与 CA 签名证书的工作方式完全相同。当提供自签名证书时，将进行检查以确保对其签名的项存在于信任存储区中。如果是自签名证书，则该证书本身的公钥必须存在于信任存储区中。如果存在，将接受该证书，并传递给 WebSphere MQ 供 SSLPEER 或出口进行处理。实际上，该公钥相当于颁发该证书的证书颁发机构。

客户端身份验证

到目前为止，我们讨论的范围仅限于提供证书时会发生什么情况。有意忽略了谁提供证书这一问题，目的是为了将重点放在有关交换的详细信息上。当协商 SSL 连接请求时，至少发生一次（也有可能是两次）证书交换。连接的服务器端始终提供一个证书。而客户端有时可能是匿名的，具体取决于服务器的配置。如果该服务器不强制客户端提供证书，则不会发生第二次证书交换。

例如，在登录银行的网站时这是可以接受的。在此情况下，服务器端身份验证让您能够知道已确实连接到了您的银行，而不是某个貌似的钓鱼网站。但是您不需要购买个人证书即可登录到您的银行网站，而且任何浏览器均可登录。连接的客户端可以是匿名的，因为将要求您在登录页输入另一套凭据。但使用 MQ 通道没有辅助登录层。由客户端提供的证书是对其进行身份验证的唯一机会，而且依赖于管理员是否能确保进行验证。

通过将通道的 SSLCAUTH 属性设置为 REQUIRED，管理员可以强迫客户端提供一个证书（请记住，本例中的“客户端”可以是另一个队列管理器）。与以往一样，服务器先提供其证书。如果客户端接受该服务器的证书，且 SSLCAUTH 将被设置为“REQUIRED”，则客户端将其证书提供给该服务器。

身份验证流程与凭据交换的工作原理完全相同，与要验证服务器还是要验证客户端无关。现在已提供证书，其签名者与信任存储区中的证书匹配，如果找到了匹配项，则该 DN 可以与 SSLPEER 属性中的值匹配或由通道安全出口处理。

配置缺陷

现在我们已经知道所有构件是如何组合在一起的，下面让我们以使用自签名证书的基本用例为起点，看一下如何拆分它们。

由于自签名证书是免费的，因此在某种程度上几乎始终会使用。但是，它们的其他优势是自签名证书不需要信任已经签署了数千甚至数百万其他证书的签名者。自签名证书的信任存储区项与一个且仅与一个证书匹配。

实现带有自签名证书的 SSL 需要管理员执行以下操作：

• 为客户端创建密钥数据库并生成相应的证书。
• 为服务器创建密钥数据库并生成相应的证书。
• 从每个证书中提取公钥。
• 将客户端的公钥导入到服务器的密钥数据库中。
• 将服务器的公钥导入到客户端的密钥数据库中。
• 启用 SSLCIPH 并在客户端和服务器之间的通道上设置 SSLCAUTH(REQUIRED)。

假定所有这些操作均已正确完成，客户端和服务器现在将会连接。但这是否就足够了？客户端已确实向服务器进行了身份验证，反之亦然。配置应允许预期允许的请求者。遗憾的是，仍有可能接纳持有由任何缺省的受信任证书颁发机构颁发的证书的任何人。这个问题的解决方案非常简单和有效：从密钥数据库中删除缺省的证书颁发机构。如果该密钥数据库仅包含自签名证书，就不可能匹配多个非预期证书。信任存储区的作用相当于一个枚举允许连接的所有标识的列表。只需处理匹配证书就足以对该连接进行身份验证。

现在，假设有一个使用 CA 签名的证书的用例。信任一个证书颁发机构并不等于信任该 CA 颁发的所有证书。最好从以下角度考虑：信任绑定到该证书的标识有效，然后设置相应标准以定义允许哪些标识连接。

使用 CA 颁发的证书实现 SSL 的安装任务包括：

• 为客户端创建密钥数据库并生成证书签名请求 (CSR)。
• 为服务器创建密钥数据库并生成一个 CSR。
• 将 CSR 提交给 CA 进行身份验证并获取签名的结果。
• 如果客户端或服务器的信任存储区中尚没有 CA 根证书，则导入该证书。
• 接收进入客户端密钥数据库的客户端证书。
• 接收进入服务器密钥数据库的服务器证书。
• 启用 SSLCIPH 并在客户端和服务器之间的通道上设置 SSLCAUTH(REQUIRED)。
• 将服务器上的 SSLPEER 设置为匹配该客户端证书的字符串。
• 从信任存储区中删除其他所有 CA 签名者。

注意，该服务器不需要让客户端的密钥在其信任存储区中（反之亦然），因为该 CA 是受信任的。使用 SSLPEER 决定是接受还是拒绝给定的证书。如果 SSLPEER 指定整个专有名称，以便仅能够与一个证书匹配，是否就可以了？也许吧。要考虑到，这一专有名称可以从任何受信任的 CA 请求。例如，假定您从两个受信任的缺省 CA 请求一个带有 DN="CN=VENUS,O=IBM,OU=ISSW,C=US" 的证书。只能保证此专有名称对每个 CA 是唯一的，因此，一个 CA 没有理由知道或关心同一 DN 是否由其他机构颁发。如果让五个缺省 CA 全部保留在您的信任存储区中，但是仅使用由其中一个 CA 颁发的证书，则其余的四个将为其他人提供请求带有匹配 DN 证书的机会，然后该证书可用来成功连接。

如果这不会造成大范围的暴露，请考虑当供应商要求您信任其内部 CA 而不是使用商业 CA 时会如何利用它。对于面向外部的通道和其他面向内部的通道，您的 DMZ 队列管理器将信任该供应商的 CA。该供应商的证书类似于 DN="CN=GATEWAY,O=Vendor,OU=PROD,C=US"，您的内部证书类似于 DN="CN=QMGR,O=MyCorp,OU=Retail,C=US"。您可以将通道配置为 SSLPEER，以便面向内部的通道与内部证书匹配，面向外部的通道与供应商证书匹配。不谨慎的供应商可能会颁发带有与您的内部证书匹配的 DN 的证书，并连接到您的面向内部的通道，这是因为 SSLPEER 只看 DN 而不管是谁颁发的。由于您的队列管理器信任该提供商的 CA，就所涉及的队列管理器来说，具有相同 DN 的伪造证书和合法证书完全相同。尽管使用完全指定 SSLPEER 值的两个 CA 之间意外发生此类 DN 冲突的情况不太可能出现，但向 SSLPEER 规范添加通配符仍会提高其几率。添加几个通配符会增加这种冲突的可能性。

防止此冲突发生不像处理自签名证书那么简单。如果信任的存储包含不止一个实体，例如两个 CA 或一个 CA 和一些自签名证书，就有可能发生 DN 冲突。从信任存储区中删除所有未使用的 CA 可减少冲突。此外，还可以利用其他 WebSphere MQ 加强技术限制连接，尤其是限制 B2B 接口的连接。

撤销访问权

在队列管理器的生命周期中，访问迟早是要被撤销的。需要考虑以下两种情况：撤销授予在其他情况下合法身份的权限和撤销被破坏的证书。记住此区别并确保将您的实现设计为专门处理这两种情况。

在将访问权授予个别标识时，撤销权限最容易。如果访问权基于指定完全限定的 DN 的 SSLPEER，则停止并删除该通道将撤销对该 DN 的访问权。如果访问完全基于自签名证书，则从信任存储区中删除证书的公钥将撤销其访问权。

撤销权限的更有趣的用例是 SVRCONN 或 CLUSRCVR 通道，当至少有一个 CA 受信任时，该通道必须匹配许多证书。集群和交互式用户身份最不稳定，最有可能需要撤销其在某个点的访问权。但是，SSLPEER 属性无法提供足够的粒度来指定允许此组的 DN，然后在此组中拒绝某些 DN。在有通配符 SSLPEER 的情况下，达到此级别粒度和使用 CA 颁发的证书的唯一方法是，使用能够将某些专有名称记录到黑名单的安全出口。

您已经了解到，撤销权限可以在一个资源上阻止证书，同时在另一个资源上允许该证书。您还必须充分考虑到证书本身已经遭到破坏这一情况。出现这种情况时，证书很可能会由同一 DN 重新颁发。要求是统一撤销对该特定证书的访问权，但不必对与其关联的 DN 这样做。通过 SSLPEER 或出口无法解决此问题，因为它们仅在 DN 上运行。在此情况下，撤销必须基于该证书的加密指纹，而提供此功能的机制就是证书撤销列表 (CRL)。

WebSphere MQ 文档解释了如何设置 CRL，还提供了 SupportPac (MQ01) 和一些示例，因此，这里不再详细介绍。概括地说，CA 提供了一个撤销证书的源。系统定期捕获这些证书（产品手册建议每 12 个小时捕获一次）并导入到一个本地数据库中。在 SSL 协商期间，将根据本地 CRL 检查进行身份验证的证书。如果找到匹配项，则连接将被拒绝。

CRL 中的证书匹配基于该证书的唯一序列号，而不是基于 DN，记住这一点非常重要。例如，如果撤销一个专有名称为 DN="CN=GATEWAY,O=Vendor,OU=PROD,C=US" 的证书，不会撤销具有相同 DN 的证书，无论它们是自签名证书还是由此 CA 或其他任何 CA 颁发的证书。该 DN 在每个上下文中仍然可行，其中包括撤销它的 CA；只有 DN 和指纹（此证书）是无效的。

在一个通道需要允许多个证书的情况下，信任存储区、SSLPEER 值和 CRL 之间的交互变得非常重要。最好的情况是信任存储区包含全部自签名证书，或者除包含受信任 CA 的单一入口之外没有其他任何项。使用自签名证书，信任将细化到具体的证书，并且能够以每个证书为单位执行撤销。使用除包含单个受信任存储 CA 之外没有其他任何内容的信任存储区，CRL 提供一个等效的每 DN 撤销功能，撤销证书将有效撤销访问权。我这样限定此说法，是因为该 CA 总是可以使用同一 DN 重新颁发该证书。CRL 本身只能保证阻止 DN，但是需要出口来保证。另外，按照惯例仅在证书遭到破坏时才撤销它，并不仅用作撤销权限的手段。

继续讨论在单一通道上匹配多个证书，信任存储区中有多个 CA 的情况会更糟。任何给定 DN 的潜在 SSLPEER 匹配项至少要与信任存储区中 CA 的数量一样多，如果将证书重新颁发计入在内数量会更大。CRL 根据该集合中的单个证书运行。虽然仍需要强制使用 CRL 来处理被破坏的证书，但是在用于从匹配池中删除 DN 时会受到很大限制。在此情况下，出口是保证阻止 DN 的唯一选项。

匹配多个证书时的其他问题

使用证书颁发机构的一个值得注意的副作用是，它外化了连接到队列管理器所需的配置。例如，假定管理员根据 O=MyCompany、OU=WidgetsDivision、OU=PROD 和 C=US 设置 SSLPEER 来过滤连接。这时，是否能够成功连接这一问题将取决于是否拥有可以匹配该 SSLPEER 过滤的证书。而事实上，证书可能会散放在某人的工作站或移动电脑上，并且提供的物理访问控制非常小，这进一步复杂化了该问题。如果单个证书被破坏，则 MQ 管理员就无法采取任何措施在队列管理器中阻止它，且不影响所有其他合法用户。唯一一种有效的方法证书撤销列表也位于队列管理器之外。

使用出口可以解决此问题。例如，可以提供一个包含可接受 DN 的“良好”列表。撤销一个入口就像从该列表中删除该项一样简单。类似地，入口可以结合 SSLPEER 使用。将在 SSLPEER 中定义一组允许的证书，且出口可以包含最重要的被记入黑名单的 DN。这样，MQ 管理员可以立即直接控制谁能够连接到该队列管理器，谁不能连接到该队列管理器。此级别的控制是否必要取决于应用程序。在太多的情况下，往往不能作出非常周全的决定，是因为它不容易理解。

回页首

在集群通道上使用出口

当使用自签名证书时，证书与标识之间存在一一对应关系。撤销访问权限和撤销证书在功能上相当；从信任存储区中删除证书可同时完成这两项任务。如果信任存储区仅包含自签名证书，多数情况下此功能将不需要 SSLPEER 过滤或处理带有出口的 DN。另一方面，使用 CA 颁发的证书需要单独的机制来执行撤销证书和撤销权限这两项任务。证书将使用 CRL 处理，权限由基于专有名称运行的机制授予或撤销。在几种情形中（如 DN 超出了 SSLPEER 长度或需要通配符匹配），通道出口是唯一的解决方案。

在选择它作为您的解决方案之前，要知道在 WebSphere MQ 集群通道上使用出口时，可能需要一个安全出口和一个通道自动定义 (CHAD) 出口。这是因为，建立通道时，接受方上的通道定义将传播到发送方。如果双方通道在同一平台上，且出口具有相同的名称并且在同一位置，则一切工作正常且不需要 CHAD 出口。不过，此类同构集群只是一种例外情况，而不是标准形式。CHAD 出口用来定制集群通道定义，为本地平台利用适当的语法指定安全出口。在大多数使用混合平台的集群中，较好的选择是使用自签名证书，编写 CHAD 出口，或者不提供按专有名称撤销访问权的功能。

回页首

有关 FIPS 的说明

联邦信息处理标准 (FIPS) 的其中一条指定了在美国政府安装中可使用的特定密码套件。许多非政府商店也将 FIPS 用作其自己安全配置的底线。为了帮助配置 FIPS 遵从性网络，该队列管理器有一个可以设置为 YES 或 NO 的 SSLFIPS 属性。当设置为 YES 时，将限制 SSL 通道仅使用 FIPS 批准的加密算法。管理员有时认识不到的是，此设置在非 SSL 通道上不会起任何作用。它们将像设置了 SSLFIPS(NO) 那样继续运行。

其目的是启用混合环境，其中一些通道使用 FIPS 批准的 SSL，另一些可能会使用出口。还有一些情况，现有的网络被迁移到了 SSL，并在一段时间内同时包含 SSL 和非 SSL 通道。在此情况下，设置 SSLFIPS(YES) 可确保这些通道直接迁移至遵守 FIPS 的通道，即使旧的通道在没有 SSL 的情况下继续运行。

回页首

加密增强

正如前面所提到的那样，消息和证书使用加密哈希来验证完整性。当前使用的两种哈希类型是 MD5 和 SHA1。尽管 WebSphere MQ 中的工具支持这两种类型，仍应该只使用 SHA 哈希。安全调查人员最近证明，利用 MD5 算法允许他们伪造可用的证书。为防止此类攻击，基于 MD5 哈希的根证书和签名者证书不应受信任。如果信任存储区中有此类证书，应将其删除。此外，建议的做法是选择 SHA1 来生成自签名证书、证书签名请求，且作为该通道密码套件的哈希组件。

密钥大小是决定加密可靠性的另一个因素。密钥越大，可能值的数量就越大，使用蛮力技术破解它就越难。确保选择的密钥长度为 1024 位或更多。

回页首

与非 SSL 配置参数交互

在该通道上启用 SSL 本身不会合理地保护队列管理器。为了使 SSL 保护有意义，必须实现几种其他配置。这方面我有一个非常好的示例，我将在演示 WebSphere MQ 加强时介绍它。

这是一个有关财务清算系统的故事，该系统使用 WebSphere MQ 连接到数十个大型金融机构。每个机构都有自己的专用通道并且每个通道都有完全指定的 SSLPEER 值。结果是，能够安全地连接到每个客户端机构，并可确保不同的客户端都不会劫持彼此的通道。一天，一个客户端报告了一个通道问题。当供应商赶去调查时，他们非常惊讶地发现，有一名不认识的管理员登录到了 WebSphere MQ Explorer。客户端机构的管理员等得不耐烦了，决定看看 WebSphere MQ Explorer 是否可以连接到供应商的队列管理器，以便查看个究竟。确实不可思议可以登录，且具有管理权限。

这里得到的教训是，仅在队列管理器的某些通道上启用 SSL 还远远不够。为了进行有效控制，队列管理器上的每个入站通道都需要启用或者禁用 SSL。这包括 RCVR、RQSTR、CLUSRCVR、SVR 和 SVRCONN 之类的所有通道，尤其是那些名为 SYSTEM.DEF.* 或 SYSTEM.AUTO.* 的通道，因为它们完全可用并具有众所周知的名称。

在 MCAUSER 属性中，不用于支持管理队列管理器的任何通道都具有低权限用户 ID，这一点也很重要。这包括上面提到的所有通道类型（SVR 通道除外）。如果允许远程管理，该管理应使用配置为仅接受 MQ 管理组成员证书的专用通道。所有其他访问，无论是来自交互式用户还是其他队列管理器，都应该使用受低权限 MCAUSER 保护的通道。这样做的原因是，经过 SSL 交换验证的标识不会传播给该 MQ API。除非被 MCAUSER 覆盖，否则通过 SVRCONN 通道到达的连接可以断言任何用户 ID，其中包括管理 ID。SSL 不限制断言 ID 的能力。其他入站通道类型 RCVR、RQSTR 和 CLUSRCVR 始终使用管理权限运行，但被 MCAUSER 覆盖的情况除外。MCAUSER 可以在通道定义中设置，也可以由出口动态设置。如果使用了出口，则通道定义应包含 MCAUSER('nobody')，因此在出口出现故障时，该通道将进入不可操作状态。

回页首

适用性

尽管此处的讨论主要着眼于一般的 SSL 规则，但本文仍特定于 WebSphere MQ，因此不适用于其他环境。例如，我在讨论证书 DN 时假定仅有一个该证书。这与撰写本文时 WebSphere MQ 手册中如何处理该主题是一致的。事实上，标准 X.509 证书包含更多的标识信息，其中包括颁发证书的证书颁发机构的 DN。本文中提到的 DN 更适合称为 subjectDN。有些产品会向管理员公开更多的证书标识。例如，熟悉 IBM WebSphere Application Server 的读者可能想知道，为什么不直接在 SSLPEER 过滤或出口的匹配条件中包括 issuerDN。总之，issuerDN 和 subjectDN 的组合在所有可能的 DN 池中应该是完全唯一的，并且可以解决此处介绍的许多 DN 匹配问题。答案就是 WebSphere MQ 仅将 subjectDN 公开给管理员或出口。issuerDN（甚至证书指纹）既不会在管理命令中暴露，也不会在低级别出口接口中暴露。这将导致在 WebSphere MQ 中对 CA 的处理稍微不同于在其他产品中的处理，并要求使用 CA 颁发的证书时信任存储区除包括该 CA 之外不包含任何内容。对于一对自定义通道安全出口而言，可以查询证书数据库以获取和交换更多的证书标识信息，但这不在本文的讨论之列。

回页首

总结

本文解决了两个反复出现的 SSL 问题。第一个问题是混杂连接，此情形是通道接受除预定连接之外的大量连接。第二个问题是无意允许管理权限的 SSL 身份验证的连接。

还提供了一些具体建议，以帮助解决下列问题：

• 从信任存储区中删除所有未使用的证书颁发机构。
• 如果信任存储区中包括一个证书颁发机构，则使用 SSLPEER 或出口（或同时使用二者）过滤出不需要的连接。
• 将受信任的 CA 的数量限制为（理想）不超过一个。
• 使用 SSLCAUTH(REQUIRED) 确保该客户端经过身份验证。
• 通过为包含有用的组织单位字段的证书专有名称设计命名规则，估计是否需要精细的 SSLPEER 过滤。
• 在设置命名规则之前，先使用自签名证书练习 DN 过滤。
• 如果需要将多个 DN 与完全限定的名称匹配，则使用自签名证书或出口。
• 如果 DN 超过了 SSLPEER 长度或者在 SSLPEER 使用通配符匹配时，需要使用出口。
• 在混合平台的集群中，需要通道自动定义出口在集群通道上实现安全出口。
• 提前制定策略，以便根据专有名称和具体证书撤销访问。
• 在使用 CA 颁发的证书时强制使用证书撤销列表。
• 如果 FIPS 遵从性是一个问题，则设置 SSLFIPS(YES)，但要知道这不会禁用非 SSL 通道。
• 通过设置 MCAUSER('nobody') 禁用所有未使用的通道，如名为 SYSTEM.DEF.* 和 SYSTEM.AUTO.* 的通道。
• 确保不允许管理访问的所有入站通道都在 MCAUSER 属性中包括一个值。

有大量文档介绍了如何设置 SSL，还有大量的帮助工具。其中有许多都在“参考资料”部分中，可帮助您入门。尽管我在此处提供了一个清单，我还是鼓励您构建一对测试队列管理器并练习 SSL 通道，直到您充分体验到 SSLPEER 的功能并知道如何撤销访问，以及如何授予访问权。下载 BlockIP2 并进行练习。最后，熟悉证书撤销列表和更新它们的流程。然后，在您准备开始 SSL 实现或纠正项目时，您将了解到构建完整的实现计划并能够避免某些常见缺陷时所需的知识。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-610850/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14789789/viewspace-610850/