级别： 中级 Peter Birk, 高级软件工程师, IBM
Keys Botzum, 高级技术人员 , IBM
2007 年 2 月 26 日 IBM® WebSphere® Application Server V6.1 中的 SSL、证书和密钥管理基础设施已发生了激动人心的更改。本文简略讨论这些更改将如何改进安全性、提供管理灵活性和简易性，并维护一个与新配置紧密集成的一致的 SSL 运行时。
摘自 IBM WebSphere 开发者技术期刊。
引言
在以前的 IBM WebSphere Application Server 发行版中，SSL 管理基于一个 SSL 配置集合，整个单元中的端点通过别名引用这些配置。每个别名都加了反映其创建位置的节点名称前缀。给定端点的 SSL 运行时读取它所引用的 SSL 配置，并通过该信息创建 SSL 套接字。每个安装都在 DummyServerKeyFile.jks 和 DummyClientKeyFile.jks 密钥存储区中附带了一组缺省的自签名证书。虽然这非常简单，但它不安全，不应该在生产中这样使用。证书的管理需要使用一个名为 IKeyMan 的外部密钥管理工具。整个系统中的每个 server.xml 中都存在对 SSL 配置的引用，因此在拓扑更改时重新组织 SSL 配置的能力可能非常有限。应用程序不具备访问这些 SSL 配置的能力。
在 WebSphere Application Server V6.1 中，SSL 管理添加了全新级别的简易性、安全性和灵活性。
在概要创建期间为每个概要创建唯一的自签名证书。当将某个概要联合到某个单元中时，会自动建立与该单元的信任关系。这些自签名证书由完全集成的证书管理基础设施进行管理，后者取代了外部 IKeyMan 工具。这些证书的过期按预定义的计划受到监视，并具有写到系统日志的通知和电子邮件发送功能。缺省情况下，这些证书会在过期前被自动替换，并且在证书替换前会有警告。 向 SSL 运行时添加了额外的 JSSE 密钥和信任管理功能，以实现更加自定义的密钥选择和信任决策。SSL 配置的管理紧密集成到该运行时中，使得缺省的套接字工厂不再需要 JSSE 系统属性。尽管仍然可以按别名引用 SSL 配置，但是通过继承来放宽或收紧供特定端点、集群、节点、节点组或整个单元使用的 SSL 配置关联，还可以按范围来管理 SSL 配置。实际上，可以在新的集中管理面板中更容易地建立 SSL 信任区域。
要描述的内容还有很多，请继续往下阅读详细信息。
本文讨论的内容包括：需要注意的问题、各个功能的已知限制和问题。在适当的时候将提供示例，并在必要时使用屏幕快照来说明所讨论的问题。本文由以下几个部分组成，每个部分分别集中于注意事项的不同方面：
SSL 配置 ——与所有 WebSphere 用户相关，并解释了用于在 WebSphere Application Server 中配置和使用 SSL 的工具。理解此信息对于所有 WebSphere 管理员来说都是非常关键的。 证书管理——描述部分更高级的 WebSphere Application Server 功能，并描述与证书管理有关的更复杂问题。大多数管理员都不需要处理这些问题，但是由于它们非常重要，所以本文包括了它们。 编程方式的 SSL 使用注意事项——简要强调一些与从应用程序代码中使用 SSL 有关的更改和功能。 初始概要创建时的密钥和证书生成——描述最初如何为概要创建证书。 节点联合和迁移——讨论如何将节点添加到现有的单元和迁移问题。 管理加密密钥的生命周期——讨论 WebSphere Application Server 中管理加密密钥随时间而更改的功能。
本文假设读者具备有关 SSL工作方面的基本知识。参考 WebSphere Application Server V6.1 信息中心的文章以了解有关这些新功能的基本信息是有益的。此外，本文结尾处的术语部分定义了文中使用的一些术语。
SSL 配置
若要了解管理控制台中新的 SSL 管理功能的总体概述，请参见图 1，其中显示了主 SSL 面板，您可以通过在控制台上选择 SSL certificate and key management 链接来访问该面板。务必要注意的是，Related Items 下面的配置链接仅显示了单元范围（对于 WebSphere Application Server Network Deployment）或节点范围（对于 WebSphere Application Server base）的配置对象，分别意味着它们对该单元或节点中的每个进程可见。范围界定的工作方式如下：当您将某个配置对象界定到该单元范围时，该单元之下的所有内容都能查看和使用该配置对象；然而，单元范围的视图无法看到界定在该单元之下的范围中的对象（这是有意为了实现运行时隔离）。因此，这些链接仅提供了配置子集。若要查看界定在更低范围中的对象，您需要选择 Manage end point security configurations 链接，此链接显示一个支持配置对象范围界定的拓扑视图。本文稍后将对此进行更详细的讨论。
图 1. SSL 证书和密钥管理主面板
什么是 SSL 配置？
SSL 配置用于封装 JSSE（WebSphere Application Server 所使用的 SSL 实现）所需的一切内容，以安全地与另一个启用了 SSL 的端点建立连接。同一个 SSL 配置可用于出站（客户端）或入站（服务器）连接。图 2 显示了 SSL 配置面板。以前的 WebSphere Application Server 发行版中所不具有的一个高级功能是插入自定义信任和密钥管理器的能力。稍后会更详细地讨论此功能。
图 2. SSL 配置面板
在深入到有关 SSL 配置的更多详细信息之前，我们将简要总结一些将在全文中使用的比较重要的 SSL 概念和术语：
密钥存储区包含个人证书，对于引用该密钥存储区的 SSL 端点，这些证书可用作它们的标识。如果存在多个证书，则 SSL 配置上的证书别名将指定其中一个个人证书。在建立 SSL 连接时（无论是在客户端还是在服务器端），可以交换证书。将使用的证书是由 SSL 配置所引用并存储在密钥存储区中的个人证书。 个人证书表示端点的标识，并包含用于对数据进行签名/加密的公钥和私钥。 信任存储区包含签名者证书，端点在发出连接（来自某个出站端点）或接受连接（针对某个入站端点）时将信任该证书。 签名者证书表示与某个个人证书关联的证书和公钥。签名者证书的用途是验证个人证书。通过接受签名者证书进入某个端点的信任存储区，就表明您允许该私钥的所有者与此端点建立连接；也就是说，该签名者证书明确信任与关联个人证书所有者建立的连接。个人证书所有者通常将签名者证书设置为完全公开的，但是接收实体要负责在将该证书添加到信任存储区之前确定它是否为受信任的签名者。
WebSphere Application Server Network Deployment（以下简称为 Network Deployment）单元的现成 SSL 设置有一个单元范围的（意味着对该单元中的所有进程可见）SSL 配置，名为 CellDefaultSSLSettings。此配置包含该单元中每个节点的节点范围的（意味着对该特定节点上的所有端点可见）SSL 配置，名为 NodeDefaultSSLSettings。SSL 配置包含许多资源（我们很快就会讨论它们），但是 SSL 配置的两个最重要部分是密钥存储区和信任存储区，其中分别包含个人证书和签名证书。为确保所有节点都能相互通信并与部署管理器通信，存在一个缺省的单元级别信任存储区，所有的缺省节点级别 SSL 配置都指向该存储区，并且其中还包括所有节点级别个人证书以及部署管理器的签名者。一般情况下，每个节点都有存储在某个节点级别密钥存储区中的各自的个人证书。部署管理器也有它自己的个人证书，并存储在它自己的密钥存储区中。稍后我们将讨论如何将新节点联合到单元中。
图 3 显示了从节点角度看到的密钥存储区配置：
- 这里显示的密钥存储区集合是可由该节点中的端点使用的密钥存储区（用作密钥或信任存储区）。其他节点可能具有不同的密钥存储区选择。
- 拓扑视图使您可以查看各个范围的配置，以了解那些范围的选择功能。
- 创建部署管理器概要时将提供 CellDefaultKeyStore 和 CellDefaultTrustStore。
- 在联合节点时将添加 NodeDefaultKeyStore 和 NodeDefaultTrustStore 密钥存储区配置。
图 3. 节点范围的密钥存储区配置面板
图 4 显示了为每个唯一的概要创建的缺省个人自签名证书。正如前面所提到的，在联合到单元中以后，可以在 CellDefaultTrustStore 中找到此证书的签名者。对于某个签名者丢失的情况，CellDefaultTrustStore 可能是您应该向其添加该签名者的信任存储区，因为在缺省情况下，大多数 SSL 配置都使用此信任存储区。SSL 连接所产生的错误消息通常指向一信任存储区，在由于丢失签名者导致握手失败时该信任存储区恰好需要该丢失签名者。
图 4. 每个概要的缺省个人证书
保护设置的质量
除了个人和签名者证书配置外，还需要考虑 SSL 配置的其他方面。
SSL 握手协议确定用于执行握手的语法。通常，协议版本越高，握手就越安全。TLSv1 是最安全的握手机制，因此应该尽可能使用它。然而，TLSv1 无法与 SSLv3 互操作，后者是更常用的协议，这是非常遗憾的。为解决这个常见问题，IBMJSSE2 提供程序包括了另一种名为 SSL_TLS 的协议。该协议首先使用 TLSv1 来执行握手；如果这无法工作，则转而使用 SSLv3，以此类推。由于此协议能够与连接另一端的大多数协议很好地交互，因此这是 WebSphere Application Server V6.1 SSL 配置的缺省 SSL 握手协议。出于安全考虑，WebSphere Application Server 缺省情况下不使用 SSLv2，除非明确配置它使用该协议。 密码套件组是特定于 WebSphere 的配置属性，它基于强、中、弱等不同强度来对密码分组。缺省强度为“强”，这通常选择 128 位密码套件。“中”组选择 40 位密码套件，而“弱”组通常仅执行数字签名（无数据加密）。图 5 显示了保护功能的质量。务必要认识到，这些密码组是可用密码套件的适当子集。因此，将连接一端设置为“强”而将另一端设置为“中”，则会由于找不到共同的密码套件而导致握手失败。如果希望使用特定的密码组合，可以使用自定义设置并专门应用您希望的密码。否则，建议对所有端点使用“强”设置。 客户端身份验证确定 SSL 客户端端点是否需要向服务器发送证书。为了使这能够工作，服务器的信任存储区中必须有能够验证客户端证书的签名证书。在某些情况下，连接两端都使用证书来进行身份验证会更安全；然而，这会带来管理负担，这就是缺省情况下关闭客户端身份验证的原因。当使用由证书颁发机构（Certificate Authority，CA）生成的证书或由公共签名者证书签名的证书时，强烈建议启用 SSL 客户端身份验证，因为这种情况下已经基于 CA 根证书建立了信任关系。然而，如果使用自签名证书，则向信任存储区添加大量签名者会降低证书验证期间的握手速度，从而导致可伸缩性问题。
图 5. 用于 SSL 配置的 Quality of Protection 面板
集中管理的 SSL 配置选择功能
集中管理 SSL 配置是一个新功能，它使得基于拓扑来控制 SSL 配置的运行时使用成为可能。此运行时关联是从拓扑面板进行设置的，该面板显示了整个单元中的所有管理范围。这些定义控制着用于任何入站或出站端点的有效 SSL 配置。有效 SSL 配置取决于为特定端点定义的最低范围，并基于继承规则优先级沿该层次结构一直往上。由于以下原因，集中管理 SSL 配置是适宜的：
- 更易于考虑环境中所有端点的恰当信任要求。
- 更易于确保指定相同的握手协议和密码要求。
- 支持让更内行的安全管理员负责所有 SSL 更改。
- 由于集中管理的功能中定义的继承规则，从而能够更灵活地维护更少的 SSL 配置。
- 更容易基于拓扑更改来作出 SSL 更改。
- 集中管理可用于快速建立信任区域。
图 6 表明了集中管理的拓扑视图中所显示的缺省 SSL 配置情况。从此视图中，您可以看到指定的所有改写设置，这些改写设置用于定义继承规则。若要查看基于这些改写设置的有效 SSL 配置，您可以单击任何进程或端点的链接，并查看该实体的有效 SSL 配置。然而，为了使集中管理的配置生效，任何端点配置中一定不能存在任何直接的别名引用。例如，如果 SSLChannel 具有对 SSL 配置的直接引用，则会改写集中管理的关联。通过在每个端点配置中作出相应的标记，可以控制是否对某个端点进行集中管理，如图 6 所示。
图 6. 集中管理的拓扑视图概述
图 7 显示了如何确定所选范围的当前继承 SSL 配置，以及如何通过直接在所访问范围中指定不同配置来改写继承的 SSL 配置。同样，要注意右侧的 Related Items 链接；当访问这些链接并创建任何新的配置对象时，您将在当前所访问的管理范围中创建它们。这意味着这些配置项仅在该范围及其所包括的范围中可见和可选择。如果返回到单元范围的链接，您将不会看到这些新的配置项，因为它们在更低的范围中。若要查看适用于某个特定继承层次结构的所有配置项，可以从某个端点面板中查看 Related Items，如图 7 所示。
图 7. 在端点 WC_defaulthost_secure 中改写继承的 SSL 配置
动态出站 SSL 配置选择功能
在某些情况下，给定端点的静态 SSL 配置不足以满足特定连接的要求。例如，您可能有一个 IIOP 静态 SSL 配置，用于所有的内部 WebSphere Application Server 通信，但是您的环境中可能有一个应用程序需要连接到某个第三方 IIOP 服务器。虽然可以修改用于 WebSphere 服务器对服务器通信的静态配置，但是对于满足第三方服务器的要求而言，使用单独的 SSL 配置以便不必修改原始静态 SSL 配置的行为可能更为适宜。
图 8 显示了动态出站端点 SSL 配置的创建过程。此配置对象允许将指定的一个或多个选择条件与某个特定 SSL 配置和证书别名相关联。在使用 JSSEHelper API 来为某个特定出站连接选择 SSL 配置时，将使用传入该 API 的连接信息来检查选择条件，以确定是否匹配。如果匹配，则使用该动态 SSL 配置，从而选择搜索过程结束。动态选择的命中和未命中情况都进行缓存以提高性能。
有关动态出站选择功能的更多信息，请参见信息中心的 Dynamic outbound selection of Secure Sockets Layer configurations。
图 8. 创建动态出站选择配置
直接选择 SSL 配置
如果您决定使用直接选择方式来管理 SSL 配置，图 9 显示了具体做法。该示例显示了针对一个 LDAP 注册中心的选择，但是同样的概念也适用于提供了该选项的所有 SSL 端点。此功能的工作方式与以前版本完全相同，并服从 SSL 配置选择规则，我们很快就会讨论这一点。
图 9. 端点配置中的 SSL 配置直接选择选项
编程方式的 SSL 配置选择功能
还可以通过编程方式控制 SSL 配置选择，虽然这不是本文的重点。首先，应用程序可以明确使用 IBM 提供的 JSSEHelper API 来访问 SSL 配置，以及使用那些配置来获得 SSLSocketFactory。使用 JSSEHelper API，还可以在建立出站连接前在线程上指定 SSL 配置。在使用那些直接使用缺省 JSSE 提供程序的现有代码时，这是非常有用的。稍后我们将对此进行讨论。
SSL 配置优先级规则
到目前为止，存在多种方法来控制所要使用的 SSL 配置，这一点应该已经很明确了。多个配置可以适用于某个特定的 SSL 使用，这是非常有可能的。为解决这种不明确性，WebSphere Application Server 运行时在选择要使用的 SSL 配置时使用以下优先级规则。这适用于 WebSphere Application Server SSL 使用、使用缺省 JSSE 提供程序时应用程序代码中的 SSL 使用，以及应用程序代码直接使用 JSSEHelper API 等情况。优先级规则如下（此列表中的第一个匹配者优先）：
基于线程的选择——应用程序已直接使用 IBM JSSEHelper API 以编程方式在线程上指定了属性。以后的隐式 JSSE 使用（即，使用 URL 提供程序打开 HTTPS 连接）将隐式地使用 JSSEHelper API 设置的特定于线程的设置。 动态出站选择——已找到与该特定出站连接信息匹配的动态出站配置。这同时适用于应用程序代码和 WebSphere Application Server 自己的使用。 直接选择——已直接为该端点指定了 WebSphere Application Server SSL 配置。对于 WebSphere Application Server SSL 使用，这可以通过管理方式完成。应用程序还可以使用 JSSEHelper API 来直接引用 SSL 配置。 带范围的选择——上述规则都不适用，所以基于拓扑的 SSL 配置选择方法将适用。
尽管有时可能有点混淆，但此方法为您提供了大量的灵活性。要特别注意的一点是，动态端点指定会同时改写直接端点指定和带范围的选择。这为管理员提供了更改 SSL 使用方式的强大能力，但也会导致意外的结果。
现在我们已经介绍了与 SSL 配置和选择有关的重要功能，我们将把注意力转向与密钥存储区和证书管理有关的功能。
证书管理
缺省证书配置
在以前版本中，WebSphere Application Server 在名为 DummyServerTrustFile.jks 和 DummyServerKeyFile.jks（位于概要的 /etc 目录中）的密钥存储区中包括缺省证书，其中包括虚拟证书（包括公共公钥和私钥）。为了实现引用该位置证书的应用程序的向后兼容性，WebSphere Application Server V6.1 仍然包括了这些文件；但是不再使用它们。
在概要创建期间，将为每个概要生成唯一的自签名证书，并位于 key.p12 密钥存储区中。签名者证书将从该个人证书中被提取出来并添加到 trust.p12 密钥存储区。这些密钥存储区是在配置存储库中的某个位置（要么在单元中，要么在节点目录中）创建的，支持通过管理控制台或 wsadmin 管理它们，并将它们与正确的节点进行同步。典型的缺省 WebSphere Application Server 配置将包含类似如下的密钥和信任存储区：
- 单元范围的密钥和信任存储区
- C:\WebSphere\AppServer\profiles\Dmgr01\config\cells\Machine40Cell01\key.p12
- C:\WebSphere\AppServer\profiles\Dmgr01\config\cells\Machine40Cell01\trust.p12
- 节点范围的密钥和信任存储区
- C:\WebSphere\AppServer\profiles\Dmgr01\config\cells\Machine40Cell01\nodes\Machine40Node01\key.p12
- C:\WebSphere\AppServer\profiles\Dmgr01\config\cells\Machine40Cell01\nodes\Machine40Node01\trust.p12
这些是在单元概要的概要创建期间创建的缺省密钥存储区。在密钥存储区配置面板中，您可以在任何位置配置任何类型的密钥存储区，以进一步自定义您的 SSL 配置。受支持的密钥存储区类型取决于您的平台。
由于 WebSphere Application Server 现在将密钥存储区作为一级管理配置部分来进行管理，因此现在存在许多可以利用的增强功能。下面将介绍一些更有意义的功能。
基本证书管理
您可以从管理控制台中管理证书及其密钥存储区。WebSphere Application Server V6.1 中的密钥管理实用程序基于以前版本中的 IKeyMan 功能。它将使用同样的术语并显示类似的视图。基本证书管理功能包括创建自签名证书、证书签名请求、签名者证书管理，等等。有关所有证书管理功能的信息，请参见信息中心的 Certificate management。
从远程端口获得签名者证书
通常，若要将 WebSphere Application Server 运行时配置为使用到另一个服务器的 SSL 连接，您必须人工获得其他服务器的签名证书，然后将其导入适当的信任存储区。然而，现在 WebSphere Application Server 中有一个功能可以简化此任务。取而代之的是，WebSphere Application Server 管理员可以使用 retrieve from port 选项（打开一个 SSL 连接以获取该证书）来直接从该服务器获得签名证书。管理员需要通过验证 SHA 摘要来验证该证书是正确的，然后可选地将其存储在本地信任存储区中。这极大地简化了设置到外部服务器（如 LDAP）的 SSL 连接的签名者交换过程。图 10 显示了 WebSphere Application Server 将与之连接以检索签名者证书的远程主机和 SSL 端口信息的设置。从图中可以看到，管理员输入主机名和端口，然后单击 Retrieve signer information 按钮。
图 10. 远程签名者证书检索
如果成功检索到签名者证书，则显示证书信息（包括用于确保证书未在传输过程中被修改的 SHA 摘要）以便验证。图 11 所示的面板允许管理员接受检索到的签名者证书，然后将其添加到信任存储区，在此例中为 NodeDefaultTrustStore。
图 11. 验证远程检索的签名者证书
管理 Web 服务器插件的证书
 | | 请不要将存储在 WebSphere Application Server 配置存储库中的密钥存储文件的管理与实际 Web 服务器插件的密钥存储文件混为一谈。下面我们将讨论如何维护插件密钥存储文件的 WebSphere 副本。每当插件密钥存储文件发生更改时，您仍然要负责确保将此更新后的文件相应地复制到 Web 服务器。此任务通常以人工方式执行，尽管还可以使用 WebSphere Application Server Web 服务器管理功能——但是出于安全考虑，很少有适合使用后一种方法的情况。 |
|
WebSphere Application Server 还为管理 Web 服务器插件的密钥文件做了准备。在创建 Web 服务器定义时，将会创建一个 CMSKeyStore 配置，此配置引用位于 config/cells/${CELL_NAME}/nodes/${NODE_NAME}/servers/${WEB_SERVER_NAME} 目录中的某个 CMS 密钥存储区（也称为 KDB 文件）和 CMS 密码存储文件（也称为 STH 文件）。缺省情况下，这两个文件分别命名为“plugin-key.kdb”和“plugin-key.sth”。在创建时，密钥存储区包括节点的个人证书和当前存在于单元公共信任存储区（单元目录中的 trust.p12 文件）中的所有签名者。这使得 Web 服务器插件能够随时发起与当前单元内的应用程序服务器中打开的所有内部 HTTPS 端口的 SSL 连接。在创建 Web 服务器定义后联合新节点时，需要将新节点的签名者添加到现有的插件密钥存储区中。对于 WebSphere Application Server V6.1.0.4，此文件将作为联合过程的一部分自动进行更新；在该版本之前，必须以人工方式执行此任务，因此强烈建议您获取该修复。
如果您由于某种原因需要人工管理插件密钥存储区，您可以使用与任何其他密钥存储区相同的证书管理功能来完成。Web 服务器插件配置面板在 SSL 证书和密钥管理下面具有返回证书管理面板的链接。图 12 显示了允许您编辑插件密钥存储区的 Web 服务器插件属性面板。
图 12. Web 服务器定义的插件属性面板
替换证书和签名者
在任何使用证书的环境中，您都必须不时地更新个人证书及其对应的签名者（对于自签名的证书）。这当然可以通过查看单元中每个信任存储区中的对应签名者来人工完成。取而代之的是，WebSphere Application Server 提供了简化此任务的功能。
图 12 显示了 Replace certificate 面板（将在选择 Replace 按钮之后显示出来），并在 Personal certificates collection 视图中选择了单个自签名证书。一旦显示了该面板，您就可以指定同一密钥存储区中应该用于替换刚才选择的个人证书的另一个证书。旧的证书将被删除，指向该证书（通过别名）的所有现有 SSL 配置都将更新为使用新证书的别名。此外，包含旧的签名者的所有信任存储区也将更新为包含新的签名者。WebSphere Application Server 通过匹配旧签名者的 SHA 签名并搜索单元中的所有信任存储区，从而查找旧的签名者。最后，该过程可以可选地删除旧的签名者和旧的个人证书。一般最好将旧的签名者保留在信任存储区中，直到您肯定所有对应的个人证书都已删除。
图 13. 自签名证书的替换
在更改证书时，由于密钥不兼容，很可能存在瞬时的 SSL 问题。为了最大程度地减少问题，如果启用了动态 SSL 更新，可以临时禁用 SSL 服务器身份验证 90 秒钟，以便留出时间来让密钥存储区完成节点同步，并让每个运行进程加载更新后的信息。因此，务必选择在网络上只有很小的流量的时候执行动态 SSL 配置更新。如果在完成同步所需的时间内更新了某个节点，或者在作出更改时节点未启动，则停止该节点并执行人工 syncNode 以将新的更改同步到该节点。如果未启用动态 SSL 更新，则服务器将在重新启动时使更改生效。
证书过期监视器和动态运行时更新
| | 下面描述的行为将通过 APAR PK34093 在 WebSphere Application Server 中（可能在 V6.1.0.6 中）实现，因此强烈建议您在该修复可用时升级到该修复级别。 |
|
一点也不奇怪，证书会过期。如果某个证书过期，使用该证书的 SSL 通信将无法进行，从而导致系统中断。WebSphere Application Server 竭尽全力阻止这种中断，并在它无法阻止时，尝试尽量在发生中断前向您发出警告。证书过期监视器任务按某个可配置的计划运行，缺省为每 14 天运行一次。该监视器的 Next start date 字段保存在配置中，并在每次运行时用一个新的日期来更新它。在 Network Deployment 环境中，它将在部署管理器进程中执行——或者如果为独立服务器——则它将在 WebSphere Application Server base 进程中执行。
在执行时，过期监视器将搜索一遍单元中配置的所有 KeyStore 对象，查找任何将在过期阈值（缺省为 90 天；可以通过一个自定义属性来对其进行配置）内过期的个人证书。如果找到任何符合条件的对象，则会发出即将过期通知警告。通知始终发送到针对所有已注册侦听器的严重事件流中。缺省情况下，这是管理控制台和 SystemOut.log。还可以使用 SMTP 服务器来通过电子邮件发送通知。
除了通知以外，WebSphere Application Server 还尝试在自签名证书过期之前替换它们。缺省情况下，过期监视器将在过期前 15 天（这是可配置的）针对任何自签名证书执行证书替换任务（已在前一部分提及）。该任务使用旧证书中的证书信息创建新证书，并使用新的签名者证书来更新单元中包含旧签名者的每个信任存储区。缺省情况下，旧的签名者证书将被删除。
每当过期监视器更改任何 SSL 配置所引用的密钥存储区或信任存储区时，它就将该配置标记为“已修改”。配置更改在过期更新任务完成后被保存，从而导致在整个运行时期间发生一次波动。随后发生的第一件事情是临时禁用 SSL 服务器身份验证（90 秒），以允许这些更改生效而无需重新启动服务器。如果您不希望发生这种情况，可以考虑禁用位于管理控制台中的 SSL 证书和密钥管理面板底部的 Dynamically update the run time when SSL configuration changes occur 选项。
遗憾的是，自动替换证书功能不是万能的。WebSphere Application Server 无法更新不在其控制之下的密钥存储区中的证书。特别是，这意味着使用以前的快速过期签名证书的 Web 服务器插件将在对应的个人证书被替换时停止工作。它还意味着，如果 WebSphere Application Server 使用个人证书来对某个其他系统进行身份验证，证书替换将导致中断。务必记住，这种中断是无论如何都会发生的——在此情况下只不过是提前了 15 天发生，并且是在 WebSphere Application Server 发送多个此类即将中断警告之后。WebSphere Application Server 只是在竭尽所能。
| | 为了降低缺省的 WebSphere 创建的证书所导致的中断风险，应知道它们的有效期缺省为 15 年。当然，过长的证书生存期的确会增加风险，并且对于担心此类风险的客户，我们建议更频繁地人工替换缺省证书。 |
|
在生产环境中让 WebSphere Application Server 自动更换过期证书非常危险，这应该是显而易见的，因为它会潜在地导致或长或短的中断。相反，您应该在收到即将过期通知时人工更换证书。自动替换主要旨在简化不太复杂的环境和能够接受短期中断的开发系统的管理。对于大多数生产系统，我们建议您改为监视并按照过期通知消息采取行动，同时禁用自签名证书的自动替换。图 14 显示了证书过期监视器的配置面板。
有关证书过期监视器的更多信息，请参见信息中心的 Certificate expiration monitoring。
图 14. 证书过期监视器配置面板
排除 SSL 问题
排除 SSL 连接问题可能相当困难。幸运的是，WebSphere Application Server V6.1 中汇集了大量用于改进错误消息质量的成果，使得诊断（并最终修复）SSL 相关问题更加容易。清单 1 显示了在尝试建立从客户端到服务器的 SSL 连接时发生的一个最常见错误的示例。在此例中，服务器发送了一个客户端无法识别的证书；也就是说，客户端的信任存储区没有包含对应的签名者。错误消息提供了有关该错误的详细信息，这应该会使得纠正错误更加容易。请注意，该错误消息指示了主机端口、丢失的签名者、SSL 配置甚至所使用的信任存储区。这准确地告诉了管理员需要采取什么措施：在此例中，需要获得丢失的签名者并将其添加到指定的 trust.p12 信任存储区。
清单 1. 丢失签名者证书时在出站连接期间发生的错误
CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN
"CN=192.168.1.204, O=IBM, C=US" was sent from target host:port
"192.168.1.12:9403". The signer may need to be added to local trust store
"c:/WebSphere/AppServer/profiles/Dmgr01/etc/trust.p12" located in SSL
configuration alias "DefaultSSLSettings" loaded from SSL configuration file
file:c:\WASX_a0633.07\AppServer\profiles\Dmgr01/properties/ssl.client.props". The
extended error message from the SSL handshake exception is: "No trusted certificate
found". |
我们现在已介绍了与大多数 WebSphere Application Server 管理员相关的普通证书/密钥存储区管理问题。下面将把注意力转向与证书管理相关的更高级问题。由于这些主题相当复杂，我们仅强调以下附加功能。请参见参考资料以了解更多信息。
高级证书和密钥管理问题
信任管理器增强功能
使用证书时，信任管理器负责执行证书验证，以确定证书是否可接受并满足生效的任何安全要求。WebSphere Application Server 提供了两个信任管理器：
缺省信任管理器 IbmX509 执行基本证书验证，包括证书签名验证（确保证书未被修改）和证书过期验证（确保证书还未过期）。此信任管理器缺省情况下不执行主机名验证，虽然您可以在安全自定义属性中设置 com.ibm.ssl.performURLHostNameVerification=true 属性来仅为 URL 连接启用此功能。如果作此设置，那么对于 URL 连接，该信任管理器将确保连接上指定的主机名匹配服务器返回的证书中的 SubjectDN（就像 Web 浏览器所做的那样）。 您可以选择的另一个 JSSE 信任管理器是 IbmPKIX 信任管理器。除了缺省执行上面列出的功能（只是仍然需要为 HTTPS URL 连接明确启用主机名验证）以外，此信任管理器还使用 CRL 分发点 (DP) 扩展（受大多数 CA 支持）或在线证书状态协议（Online Certificate Status Protocol，OCSP）系统属性，从而执行高级证书吊销列表（Certificate Revocation List，RL）检查。当选择 IbmPKIX 信任管理器作为缺省信任管理器时，会自动启用 CRL DP 处理。这将对包含 CRL 分发点的所有证书执行 CRL 检查。如果要更频繁地执行 CRL 检查，可以设置进程配置中的系统属性来启用 OCSP。有关启用 OCSP 所需要的属性的描述，请参见 Java Certification Path API Programmer's Guide。（虽然此信息针对 IBM JDK，但它适用于任何 WebSphere Application Server 安装，因为 IBM 对与 WebSphere Application Server 打包在一起的任何 JDK 添加了加密功能，包括 PKIX。）
如果您的环境需要更专门的证书验证，您甚至可以编写自己的自定义信任管理器。您可以插入任何数量的自定义信任管理器，以在 IBM 提供的信任管理器运行之后运行。在实现自定义信任管理器时，您应该考虑两个接口：
使用信任管理器基础设施的客户端的高级签名者交换管理
缺省情况下，客户端使用的信任存储区包括本地概要的受信任签名者。如果除了初始 WebSphere Application Server 基本概要以外，客户端还需要与其他 WebSphere 服务器通信，则需要完成一些额外的工作来建立此信任。在决定如何建立 V6.1 客户端和服务器之间的信任时，可以按简单性级别顺序来考虑以下可能性：
通过将位于概要 /properties 目录中的 ssl.client.props 文件中的 com.ibm.ssl.enableSignerExchangePrompt 属性设置为 true 来启用签名者交换提示。这缺省是启用的。在客户端的本地信任存储区中还没有签名者的情况下，这会在建立新连接后提示用户（当启用了签名者交换提示时）接受签名者。用户将看到关于证书的信息，包括证书的 SHA 摘要。这与您在浏览器客户端中看到的信任证书概念是相同的。有关更多信息，请参见信息中心的Secure installation for client signer retrieval。 从公共单元信任存储区下载所有签名者，然后使用这些签名者来更新客户端信任存储区。这是通过使用 retrieveSigners.bat（或 .sh）脚本来完成的。有关更多信息，请参见信息中心的 retrieveSigners command。 从服务器人工提取签名者证书，并将其导入客户端的信任存储区。 在应用程序客户端中使用编程 API 来以编程方式为特定连接建立信任——或永久地为所有连接建立信任（通过在信任存储区中保存签名者）。这消除了签名者交换提示和 retrieveSigners 脚本原本就需要的人工介入。此功能旨在用于自动化的测试环境或任何受到足够信任以允许启用 SSL 服务器身份验证延迟的环境。不应该在生产环境中使用此方法。有关更多信息，请查看信息中心的 com.ibm.wsspi.ssl.RetrieveSignersHelper SPI。
清单 2 显示了实现上面的选项 4 所必需的编程调用。这实际上对这些调用禁用了 SSL 服务器身份验证，因而只应该考虑在受信任的环境中使用。此示例显示了三种单独的方法：
- 以编程方式调用 retrieveSigner 功能来批量加载所有单元证书。
- 临时接受下一个服务器证书。
- 接受下一个服务器证书并持久地存储它以便将来使用。
清单 2. 在受信任环境中使用 RetrieveSignersHelper SPI 来建立信任
import com.ibm.wsspi.ssl.RetrieveSignersHelper;
A)/*** Obtain an instance of the helper class. ***/
RetrieveSignersHelper rsHelper = RetrieveSignersHelper.getInstance();
/*** Retrieve all cell level signers programmatically by passing in all of the same
parameters you would pass in from the command line. These arguments will download
all signers from the "CellDefaultTrustStore" into the
"ClientDefaultTrustStore". The -autoAcceptBootstrapSigner is important
to specify here in that it accepts the signer necessary to make the original
connection to begin with. ***/
String[] args = new String[] {"CellDefaultTrustStore",
"ClientDefaultTrustStore", "-autoAcceptBootstrapSigner"};
rsHelper.callRetrieveSigners (args);
B) /*** An alternative to calling the retrieveSigners capability up front, is to
allow trust in specific connections or the capability to download and possibly
store the signer for a particular connection. Here we accept temporarily the next
server certificate presented by the next SSL communication on this thread. */
rsHelper.autoAcceptSignerForThisConnectionOnly();
/*** OR **
This is just like the above accept that the signer is stored persistently in the
trust store. It will thus be used for all future requests. ***/
rsHelper.autoAcceptSignerAndStoreInTrustStore();
/*** Note that these two calls apply only to the next SSL communication. If multiple
servers need to be accepted these APIs will need to be called prior to each
communication. ***/ |
自定义的密钥管理器
在 WebSphere Application Server V6.1 中，可以对 JSSE 的密钥管理器进行自定义。一次只允许有一个密钥管理器，因此它要么是缺省的 IbmX509 密钥管理器（它知道如何从 WebSphere 配置的密钥存储区选择证书），要么是您配置的自定义密钥管理器。可以在客户端或服务器上使用可插入的密钥管理器。
如果您希望改写运行时查找证书的方式，则定义一个自定义密钥管理器可能是适宜的。最可能的场景是在客户端上；客户端可能需要支持智能卡或允许用户选择用于特定连接的证书。有关更多信息，请参见信息中心的 Key manager control of X.509 certificate identities。
使用 RetrieveSigners 脚本来更新服务器环境的信任存储区
我们刚才讨论了使用 RetrieveSigners 脚本来将签名者下载到客户端。RetrieveSigners 脚本通过读取 ssl.client.props 文件中的配置信息来确定要更新什么信任存储区。虽然该脚本旨在更新客户端信任存储区，但是在某些情况下，您可能希望将签名者从某个服务器（或单元）的信任存储区下载到另一个服务器（或单元）的信任存储区中。例如，如果您尝试配置跨单元通信，可能就会这样做。
当然，您可以人工将签名者从一个单元导出，并将它们导入第二个单元的信任存储区。然而，您还可以利用 RetrieveSigners 脚本来为您完成此任务。
若要将签名者导入某个服务器信任存储区，您可以编辑 ssl.client.props trustStoreName 属性，使其临时指向相应的信任存储区；这很可能是位于单元目录中的公共 trust.p12。清单 3 显示了更新 ssl.client.props 以引用单元级别信任存储区的示例。当然，必须在 DeploymentManager 节点上运行此示例，以便实际更新单元信任文件的主副本。
清单 3. 使用 RetrieveSigners 将签名者下载到服务器信任存储区
/*** Edit the properties/ssl.client.props file prior to running RetrieveSigners.
Change from:
# TrustStore information
com.ibm.ssl.trustStoreName=ClientDefaultTrustStore
com.ibm.ssl.trustStore=${user.root}/etc/trust.p12
Change to:
# TrustStore information
com.ibm.ssl.trustStoreName=ClientDefaultTrustStore
#com.ibm.ssl.trustStore=${user.root}/etc/trust.p12
com.ibm.ssl.trustStore=${user.root}/config/cells/Machine40Cell01/trust.p12
Now run the RetrieveSigners script pointing to a different Cell or Server that
contains a different trust.p12 than this one.
***/
C:\WebSphere\AppServer\profiles\Dmgr01\bin> retrieveSigners.bat
CellDefaultTrustStore ClientDefaultTrustStore –autoAcceptBootstrapSigner
–host otherdmgr.raleigh.ibm.com –port 8879 –user myadmin –password myadminpwd
CWPKI0308I: Adding signer alias "CN=machine40.austin.ibm.com, O=IBM,
C=US" to local keystore "ClientDefaultTrustStore"
with the following SHA digest:
A7:87:EA:E0:FA:26:38:F6:00:F7:CD:0C:88:6A:85:62:BC:D7:17:3D
CWPKI0308I: Adding signer alias "dummyclientsigner" to local keystore
"ClientDefaultTrustStore" with the following SHA digest:
0B:3F:C9:E0:70:54:58:F7:FD:81:80:70:83:A6:D0:92:38:7A:54:CD
CWPKI0308I: Adding signer alias "agentcert" to local keystore
"ClientDefaultTrustStore" with the following SHA digest:
88:12:C9:6D:3F:0E:9A:72:25:87:35:4F:BB:42:6D:A5:A8:62:89:D5
CWPKI0308I: Adding signer alias "dmgrcert" to local keystore
"ClientDefaultTrustStore" with the following SHA digest:
98:B3:A1:9C:16:DF:F8:A9:C2:31:12:A8:29:CC:D5:82:EE:F2:3A:F2
CWPKI0308I: Adding signer alias "dummyserversigner" to local keystore
"ClientDefaultTrustStore" with the following SHA digest:
FB:38:FE:E6:CF:89:BA:01:67:8F:C2:30:74:84:E2:40:2C:B4:B5:65 |
完成下载必要的签名者之后，您当然希望撤销对 ssl.client.props 文件的更改。而且，不要忘了执行一次完全节点同步，以强制将更新后的信任文件复制到单元中的其他节点。
将密钥存储区配置隔离到某个特定节点
一般情况下，部署管理器在配置存储库中管理密钥存储区，并将它们从那里复制到单元中的各个节点。在某些情况下，您可能希望隔离某个密钥存储区（或界定其范围），以便仅将它存储在单个节点上。例如，密钥存储区可能包含敏感密钥，只有该节点才能看到，甚至部署管理器也不应该复制它们。这种情况非常罕见，但是如果出现此要求，这种情况是可以解决的。
图 15 显示了节点范围和远程管理的密钥存储区配置的创建。远程管理它的原因是因为它没有存储在 WebSphere 配置存储库中，从而使得部署管理器无法直接操作该密钥存储区。相反，部署管理器使用远程 JMX 调用来要求目标节点上的节点代理管理该密钥存储区。
若要创建仅对特定节点上的端点可见的密钥存储区配置：
- 通过 Manage end point security configurations 链接来使用拓扑视图。
- 选择当前节点的适当管理范围，然后单击 New。
- 从图 15 所示的面板中，您现在可以为该节点创建新的密钥存储区。由于此例中的密钥存储区路径为 c:\temp，该密钥存储区将不在配置存储库中，从而部署管理器不会复制它。若要让部署管理器管理该密钥存储区，则必须对其进行远程管理。
我们这里所示的是一个简单示例，其中使用了基于文件的密钥存储区。然而，同样的原理也适用于加密令牌设备（例如，硬件密钥存储区）。由于只能从该节点访问这些物理设备，因此必须对硬件密钥存储区进行远程管理，并且应该从拓扑视图中的 Node 链接或更低级别创建，具体取决于您的隔离需要。
图 15. 创建远程管理的密钥
编程方式的 SSL 使用注意事项
虽然本文的重点不是编程方式的 SSL 使用，但是我们认为，简要强调一下一些可能影响使用 SSL 的现有应用程序的更改是非常重要的。这些更改一般都是改进，但是作为 WebSphere 用户，您仍然需要注意它们。存在两个方面的重要更改：
- 新的编程 API 使应用程序开发人员能够直接使用 WebSphere SSL 配置。
- 正如前面所述，缺省 JSSE 提供程序的行为已发生了变化。
JSSE API
WebSphere Application Server V6.1 引入了一个新的名为 com.ibm.websphere.ssl.JSSEHelper 的辅助 API，它充当 JSSE 编程模型和 WebSphere SSL 配置及运行时之间的粘合剂。应用程序可以像利用 WebSphere SSL 运行时一样利用此 API，或者它们可以继续直接使用 JSSE API 并自己管理配置，就像在以前版本中一样。图 16 显示了 JSSEHelper、SSL 配置和 JSSE 编程模型之间的交互，这些交互用于获得诸如 SSLContext、SSLSocketFactory、SSLServerSocketFactory 和 HTTPS URLStreamHandler 等构造。可以通过多种方法来利用此 API。我们将仅描述几个用例。
图 16. JSSEHelper 在 SSL 运行时中的作用
如果应用程序即将使用某一个使用了缺省 SSL 套接字工厂的代码段来发出 SSL 连接（例如，某个 URL 连接），那么通过使用基于线程的 SSL 选择功能，应用程序仍然可以控制所要使用的 SSL 配置。本质上，JSSEHelper 类可以从当前线程中设置应该在下一个 SSL 连接上使用的 SSL 配置。清单 4 显示了一个示例。
清单 4. 以编程方式在线程上指定 SSL 属性的示例
import com.ibm.websphere.ssl.JSSEHelper;
/*** For this example, just hard code an alias. ***/
String alias = "CellDefaultSSLSettings";
java.util.Properties props = JSSEHelper.getProperties(alias);
JSSEHelper.setSSLPropertiesOnThread (props);
/*** Make any URL connection here, for example, and the properties
will be picked up by the WebSphere socket factory. ***/ |
在清单 4 中，CellDefaultSSLSettings 将用于发出安全出站 URL 连接。这之所以能够工作，是因为用于 https 协议的缺省 URLStreamHandler 调用 SSLSocketFactory.getDefault()。然后这将使用 WebSphere JSSEHelper API 来确定所要使用的配置。
在我们的第二个示例中，我们将使用 JSSEHelper getProperties() API 来指定要使用的 SSL 配置。SSL 配置选择遵循前面在 SSL 配置优先级规则部分中讨论的规则。请注意，在清单 5 中，我们预先创建了各个常规事务对象，还提供了一个 SSL 侦听器。该侦听器是一个特定于 WebSphere 的扩展，并将在 SSL 配置被更改时收到通知，从而为您提供采取相应操作的机会。如果不需要事件通知，可以使用 Null。
清单 5. 用于获得 SSL 套接字工厂的 JSSEHelper 示例
import com.ibm.websphere.ssl.JSSEHelper;
String alias = "aliasforsomeconfiguration";
String host = "myhost.ibm.com";
String port = "443";
/*** Create a map of information to tell the SSL runtime the connection
information***/
final HashMap connectionInfo = new HashMap();
connectionInfo.put(JSSEHelper.CONNECTION_INFO_DIRECTION,
JSSEHelper.DIRECTION_OUTBOUND);
connectionInfo.put(JSSEHelper.CONNECTION_INFO_REMOTE_HOST, host);
connectionInfo.put(JSSEHelper.CONNECTION_INFO_REMOTE_PORT, port);
/*** An optional listener can be passed into the API to get notifications
when the returned configuration changes. ***/
MySSLConfigListener myListener = new MySSLConfigListener();
/*** obtain the SSL connection ****/
javax.net.ssl.SSLSocketFactory sslFactory = JSSEHelper.getInstance().getSSLSocketFactory
(alias, connectionInfo, myListener); |
第三个示例（清单 6）基本上与前一个示例类似，只不过这里不是直接获得 SSL 工厂，而是获得关于某个现有配置的属性。然后可以通过某种自定义方式来修改这些属性，之后可以再次使用 JSSEHelper 来获得经过简单自定义的 SSL 套接字工厂。
清单 6. 获取 SSL 配置属性
/*** Obtain the SSL connection information as a properties
object ***/
java.util.Properties props = JSSEHelper.getInstance().getProperties
(alias, connectionInfo, myListener); |
第四个示例（清单 7）演示了如何使用动态选择功能，从而使用 JSSEHelper 来选择端点。我们没有指定别名，而是依赖 WebSphere 运行时来查找适当的 SSL 配置。可以想象的到，这样能够实现更多的组合。JSSEHelper API 是相当灵活的。
清单 7. JSSEHelper 的 SSL 配置动态选择功能示例
import com.ibm.websphere.ssl.JSSEHelper;
String host = "myhost.ibm.com";
String port = "443";
/*** The endpointName is arbitrary but can be used for the dynamic outbound
configuration. ***/
String endpointName = "ConnToMyHost";
/*** Create a map of information to tell the SSL runtime the connection
information for making a dynamic outbound selection decision. Pass in
"null" if you do not care about the dynamic outbound configurations
being considered. ***/
final HashMap connectionInfo = new HashMap();
connectionInfo.put(JSSEHelper.CONNECTION_INFO_DIRECTION, JSSEHelper.DIRECTION_OUTBOUND);
connectionInfo.put(JSSEHelper.CONNECTION_INFO_REMOTE_HOST, host);
connectionInfo.put(JSSEHelper.CONNECTION_INFO_REMOTE_PORT, port);
connectionInfo.put(Constants.CONNECTION_INFO_ENDPOINT_NAME, endpointName);
/*** An optional listener **/
MySSLConfigListener myListener = new MySSLConfigListener();
javax.net.ssl.SSLSocketFactory sslFactory = JSSEHelper.getInstance().getSSLSocketFactory
(null, connectionInfo, myListener); |
若要了解有关 JSSE API 的更多信息，请参见 JavaDoc。有关各种 SSL 选择类型特征的更多信息，可以在信息中心的 Secure communications using Secure Sockets Layer 中找到。
对以前版本中的 JSSE 工作方式感兴趣的读者应该参阅 developerWorks 文章 在 WebSphere Application Server 中使用 Java Secure Socket Extension。
对缺省 SSLSocketFactory 和 SSLServerSocketFactory 的更改
可能影响现有应用程序的关键更改是对 Java SSLSocketFactory.getDefault() 方法行为的更改。许多应用程序都明确或隐式地使用此 API。在发出 SSL 连接而没有指定 SSL 工厂的许多场合都隐式地使用它；URL 提供程序、LDAP 提供程序、某些 Web 服务以及其他许多地方都会发生这种情况。
在独立 JDK 中，SSLSocketFactory.getDefault() 方法返回一个缺省 SSLSocketFactory，JDK 将其初始化为使用缺省密钥和信任存储区。正如前面提到的 JSSE 文章所述，这些属性通常设置为 JDK 系统属性。在 WebSphere 服务器进程中，系统属性影响整个 JDK 和所有运行在该 JDK 中的应用程序。
在 WebSphere Application Server V6.1 中，缺省的 JDK 套接字工厂已被 WebSphere 实现所取代，后者对如何解释配置信息具有更多控制，然后能够基于该配置创建 JSSE 套接字工厂，而不是对一切都使用静态系统属性。这不仅为管理员提供了更多的控制——即使是对于仅具有最基本功能的应用程序——而且还可以防止与 WebSphere Application Server 运行时的 SSL 使用发生冲突。
使用 SSLSocketFactory.getDefault() 的仅具有最基本功能的程序实际上将使用 WebSphere SSL 套接字工厂。此工厂遵循我们在“SSL 配置优先级规则”部分描述的所有 SSL 配置选择规则，唯一的例外是：如果设置了密钥存储区的 JDK 系统属性，则它们将改写 WebSphere Application Server 已设置的属性。这是为了实现向后兼容性，因此不要依赖此行为；最好让 WebSphere Application Server 管理您的 SSL 配置和密钥存储区。
初始概要创建时的密钥和证书生成
到目前为止，我们已讨论了稳定状态的缺省密钥、证书和 SSL 配置。一个显而易见的问题是，这些项最初是如何创建的？可以想象的到，它们是在概要创建过程期间创建的。概要创建任务为所创建的概要建立缺省配置。有些配置信息是在概要创建面板中指定的，而其他信息则是从环境中派生的。其中大多数信息都基于所创建的概要类型的模板。模板和环境确定了概要的缺省配置文档。
WebSphere Application Server V6.1 发行版的一个重要要求是删除缺省证书（也称为虚拟密钥文件），并将它们替换为在概要创建期间生成的真实自签名证书（该概要的唯一私钥）。此缺省配置可以在生产环境中使用，因为它缺省情况下是安全的。存在三个初始配置概要，每个配置概要具有稍微不同的初始配置：
Base Application Server 概要是使用 key.p12（PKCS12 格式）密钥存储区和 trust.p12（PKCS12 格式）信任存储区在配置目录 ${USER_INSTALL_ROOT}/config/cells/${CELL_NAME}/nodes/${NODE_NAME}/ 中创建的。这些密钥存储区的缺省密码（以及其他概要的缺省密码）始终为“WebAS”。请注意，此方法在节点之间提供了某种程度的隔离。如果将此基本服务器联合到 Network Deployment 单元中，此节点的自签名证书对该单元将是唯一的，并且其证书将在一个特定于节点的目录中。信息中心的 Secure Sockets Layer node, application server, and cluster isolation 描述了使用 SSL 来进一步隔离节点的附加场景。 部署管理器概要是使用目录 ${USER_INSTALL_ROOT}/config/cells/${CELL_NAME}/ 中的 key.p12 和 trust.p12 密钥存储区来创建的，这两个存储区分别包含一个自签名个人证书和签名者。位于该目录中的 trust.p12 密钥存储区称为公共信任存储区。 单元概要（包含一个部署管理器和一个节点）是使用同时用于部署管理器和节点的单个自签名证书来创建的，但它们将存储在单独的密钥存储区中（对于节点是节点范围的密钥存储区，对于部署管理器是单元范围的密钥存储区）。在此例中，这意味着部署管理器和单元中的一个节点碰巧共享相同的自签名证书。这可能有点令人吃惊，并且会在替换证书时导致意外行为。在替换与单元或单元密钥存储区共享相同证书的节点的自签名证书时，不要删除单元范围的 trust.p12 中的签名者——因为节点仍在使用它——除非您同时替换两个位置（节点和单元密钥存储区）的自签名证书。为避免这种意外共享，简单地创建一个部署管理器概要，然后创建一个基本应用程序服务器概要，这样也许是适宜的。
对于所有概要，在创建这些自签名证书时，还会将它们添加到 ${PROFILE_ROOT}/etc 目录中的 key.p12 和 trust.p12 中。这些密钥存储区由从该概要启动的客户端（例如，wsadmin）使用。这些证书为它们提供了与相同概要中的服务器通信所需的信任，从而不需要进行任何签名者交换。
虽然此配置不适合所有环境，但它适合大多数环境。然而，与 WebSphere Application Server 中的几乎所有其他功能一样，如果不喜欢缺省设置，您可以更改它们。
对自签名证书的创建进行自定义
在概要创建期间，为该概要创建的自签名证书是使用以下缺省值来创建的：
清单 8. 用于对自签名证书的创建进行自定义的属性
com.ibm.ssl.defaultCertReqAlias=default
com.ibm.ssl.defaultCertReqSubjectDN=cn=${hostname},o=IBM,c=US
com.ibm.ssl.defaultCertReqDays=5475
com.ibm.ssl.defaultCertReqKeySize=1024 |
| | WebSphere Application Server APAR PK34093（可能在 V6.1.0.6 中）将把 defaultCertReqDays 的值更改为 5475 天（15 年）。早期版本使用缺省值 365 天，这可能会由于生存期太短而导致生产问题。 |
|
这些属性设置不会在服务器配置模板中出现，但是通过作为自定义属性来指定新值，还是可以改写它们。若要改写在概要创建期间使用的缺省值，可以编辑 ${WAS_INSTALL_ROOT}/profileTemplates 目录中的 security.xml 文件，并在自定义属性部分仅指定您希望改写的属性。例如，若要修改某个“缺省”概要 (Base Application Server) 的属性，您可以在创建概要前将相关属性添加到以下 security.xml 文件：${WAS_INSTALL_ROOT}\profileTemplates\default\documents\config\cells\BaseApplicationServerCell\security.xml。在此例中，我们决定将新概要的证书生存期更改为 1825 天（5 年），从而改写 IBM 提供的缺省值。
清单 9. 改写缺省自签名证书过期周期所必需的属性更改
<properties xmi:id="Property_45"
name="com.ibm.ssl.defaultCertReqDays"
value="1825" required="false"/> |
创建基本服务器概要时，此设置将确保初始自签名证书具有五年的生存期。取决于您的安全策略，您可能希望更改 IBM 定义的 15 年缺省证书生存期。较短的生存期可以提高安全性，但是要记住，如果未得到正确的管理，证书过期会导致中断。
设置所创建证书的 SubjectDN 也是相当简单的，但是要注意，在缺省情况下，证书包括服务器的主机名。${hostname} 变量将通过 JDK java.net.InetAddress.getLocalHost().getCanonicalHostName() API 来进行解析。如果这没有解析为您希望的主机（也许您宁愿不在证书中嵌入主机名），则可以为 SubjectDN 指定一个不引用 ${hostname} 变量的值。
Web 服务器定义密钥存储区的创建
创建概要时，同时还可以创建 Web 服务器定义，如图 17 所示。在这种情况下，概要创建过程将把概要的自签名证书放置到一个 CMS 密钥存储区中，该存储区在概要配置存储库中位于 Web 服务器的服务器目录中。这意味着 Web 服务器将与初始节点共享相同的自签名证书。
图 17. JSSEHelper 在 SSL 运行时中的作用
LTPA 密钥生成
除了在概要创建期间创建的各个 SSL 自签名证书以外，在概要创建时还会生成缺省的 LTPA 密钥。相对于以前 WebSphere Application Server 版本的一个重要更改是 LTPA 加密密钥不再存储在 security.xml 文件中，而是在一个密钥存储区中进行管理。因此，将有多个版本 LTPA 密钥同时处于活动状态，从而支持使用旧密钥来验证旧令牌，并提供一种无缝的方法来生成新密钥而不会导致运行时中出现问题。管理加密密钥生命周期部分将对此进行更详细的讨论。
LTPA 密钥存储区名为 ltpa.jceks 并使用 JCEKS 格式，从而使得将密钥存储为原始“机密”密钥成为可能。与其他密钥存储区一样，LTPA 密钥存储区的缺省密码为“WebAS”。密钥存储区的位置取决于概要类型：
- 对于 Base Application Server 概要，ltpa.jceks 密钥存储区位于概要配置存储库的节点目录中。
- 对于部署管理器，ltpa.jceks 密钥存储区位于概要配置存储库的单元目录中。
概要创建期间的密钥和证书生成故障排除
任何事情都有出错的可能性。在概要创建期间，无论概要中是否启用了安全性，都会执行一个 AdminTask 来生成前面讨论的密钥和证书；该 AdminTask 要么是 PrepareKeysForCellProfile（在创建单元概要时调用），要么是 PrepareKeysForSingleProfile（在创建所有其他概要类型时调用）。这两个任务都会在 ${WAS_INSTALL_ROOT}/ logs/manageprofiles/${PROFILE_NAME}/keyGeneration.log 中创建一个日志文件。成功执行此任务将导致该日志文件中最后一行内容为“KeyStore creation and certificate exchange successful for Cell profile”。如果该语句或 keyGeneration.log 文件未出现，则表明概要创建期间在此任务执行之前或执行期间发生了问题。
结果证明，刚才讨论的安全任务还碰巧是概要创建期间调用 wsadmin 客户端所执行的第一个任务。因此，该任务失败通常与安全性无关，而是表明 wsadmin 存在某个问题。如果没有创建 keyGeneration.log，问题可能与密钥生成功能无关。如果创建了 keyGeneration.log，则问题可能与密钥生成功能有关，但也可能是 wsadmin 中的问题。若要进一步排除这些问题，可以查看文件 ${WAS_INSTALL_ROOT}/logs/manageprofiles/${PROFILE_NAME}_create.log 中的内容。这是通用的概要创建日志文件。请搜索该日志中出现 FAIL 的地方。
此外，您还可以启用跟踪来获取更多信息。若要启用更多的跟踪，可以编辑 ${WAS_INSTALL_ROOT}/profileTemplates/“profile_type”/documents/properties/wsadmin.properties 文件来启用跟踪，具体方法是取消对以下行的注释：
#com.ibm.ws.scripting.traceString=com.ibm.*=all=enabled
当然，您需要在开始创建概要之前编辑此文件。这将作为概要创建过程的一部分在 ${PROFILE_ROOT}/logs/ 目录中产生 wsadmin.trace 日志文件，此跟踪文件可以捕获该过程中的失败情况，除非概要管理工具本身存在问题。
既然我们已经讨论了 WebSphere Application Server V6.1 中的新概要初始配置状态，下面我们将把注意力转向在将节点添加到现有单元时发生的情况。
节点联合和迁移
在本部分中，我们将介绍 Network Deployment 节点联合步骤，此步骤导致 Base Application Server（独立服务器）成为 Network Deployment 单元中的一个节点。对于缺省 SSL 配置，此过程期间会执行某些自动化的步骤，以确保为 Base Application Server 概要创建的自签名证书受到该单元中已经存在的其他服务器的信任，反之亦然。
其目标是确保所有服务器在缺省情况下相互信任，以便管理员在使用缺省的现成配置时不需要采取任何附加步骤。当包括更复杂的混合版本和/或混合平台环境时，这并非始终是可能的。可能需要进行一些人工签名者交换，但是基于远程证书中的 Subject DN，从 WebSphere Application Server V6.1 运行时发出的消息使得确定哪个密钥存储区缺少所需的签名者变得更加容易。
本部分首先讨论一个纯 WebSphere Application Server v6.1 单元（不存在低版本节点或混合平台节点）中的典型同类环境的节点联合期间发生的步骤。然后我们将讨论由于异类节点平台和/或版本复杂性而可能需要人工介入的问题。
V6.1 节点的安全配置合并
在将 V6.1 基本服务器联合到某个现有单元中时，会将节点的个人证书添加到单元级别的信任存储区，并更新节点的安全配置以反映单元级别的信任存储区。这确保新节点能够与单元中的其他节点通信。还会执行其他更改来更新节点的安全配置，以确保它恰当地成为该单元的成员。
一旦联合过程完成，则在启动节点代理之前将配置存储库与该节点同步。这确保节点代理和应用程序服务器能够访问更新后的所需正确配置信息（包括签名者和 LTPA 密钥），以便安全地与单元的其他部分通信。其他单元成员会收到更新后的 SSL 配置信息的通知。如果启用了 SSL dynamic configuration changes 复选框，则会清空所有密钥存储区和 SSL 缓存，并且整个单元中的所有进程都加载新的配置信息。因此，新节点应该无缝地成为该单元的一部分而不必重新启动其他服务器。图 18 显示了 Dynamically update the run time when SSL configuration changes occur 复选框，需要启用此复选框才能确保无缝的联合不要求重新启动任何服务器。如果禁用此选项，则部署管理器和其他节点可能需要重新启动才能与新节点通信。
图 18. 在 SSL 配置更改发生时动态更新运行时
低版本的节点联合
当联合的节点来自早期版本的 WebSphere Application Server 时，该节点不知道新的自签名证书方案。它也不知道新的 SSL 配置对象、新的 LTPA 密钥存储区，等等。节点联合过程会尽可能尝试使用转换代码来解决此问题，该转换代码将 security.xml 文件从 V6.1 格式转换为低版本节点所期望的格式。
在低版本节点联合期间，如果该节点仍在使用缺省的 DummyServerKeyFile.jks 和 DummyServerTrustFile.jks，则会自动将这些存储区分别替换为单元范围的 key.p12 和 trust.p12 密钥存储区。这使得低版本节点能够与 V6.1 部署管理器和单元中的其他节点通信。然而，如果低版本节点未使用缺省密钥和信任存储区，则需要首先执行人工签名者交换，然后才能成功进行节点同步。此人工过程本质上与在具有非缺省密钥存储区的早期 WebSphere Application Server 版本中将节点添加到现有单元时的过程相同。
混合平台节点联合
对于大多数 WebSphere Application Server 平台，这方面都不存在任何重大的区别。然而，由于 WebSphere Application Server on z/OS® 利用了 z/OS 高级安全功能（包括证书管理），因此在同一单元中混合 z/OS 节点和非 z/OS 节点时，将存在一些额外的复杂性。
存在两个 z/OS 特有的问题：
- z/OS 已经包含一个使用 RACF（或某种其他 SAF 产品）的 PKI 环境，以利用 CA 来生成证书。
- z/OS RACF 密钥存储区是不可写入的，从而使 WebSphere Application Server 无法作为联合过程的一部分来更新密钥存储区。为了使节点代理能够在联合之后成功地与部署管理器通信，您需要人工将分布式签名者证书（来自单元信任存储区）添加到 RACF Keyring 中，并将 RACF 签名者添加到分布式单元的单元信任存储区中。
如果 z/OS 节点或 dmgr 概要是使用同类安全选项（即，使用 key.p12 和 trust.p12 密钥存储区而不是 RACF Keyring）来创建的，您可能需要人工将 trust.p12 签名者添加到 z/OS Daemon SSSL 配置 Keyring 中。在 WebSphere Application Server V6.1 中，z/OS Daemon 进程仅包含仍在对 SSL 运行时使用 z/OS System SSL (SSSL) 功能的端点。所有其他端点都使用 JDK IBMJSSE2 SSL 实现。然而，z/OS 上的 IBMJSSE2 SSL 配置通常仍然使用 RACF Keyring，其中包含 RACF 生成的证书。这是在 z/OS 中创建概要时在自定义对话框中配置的。
迁移
在迁移节点（也就是将它们从一个版本转换为另一个版本）时，将遵循不同的规则。基本迁移规则之一是尽可能不改变配置的行为。因此，迁移后的单元不利用自动化的自签名证书生成。尽可能对所迁移的单元作出最少的更改。迁移将旧式 SSL 配置的格式更改为 security.xml 文件中的新格式。迁移不更改所引用的证书或密钥存储区。如果部署管理器在迁移前使用虚拟证书，则它在迁移后仍然使用虚拟证书。当然，仍然存在高级的证书管理功能，可用于简化迁移后的证书创建。对于生产环境中的任何使用，应创建唯一证书来取代虚拟证书。
由于迁移后的环境中存在混合的 SSL 配置，每当将新节点联合到迁移后的单元中，可能需要执行一个人工 syncNode 才能实现正确的新节点同步。在某些情况下，可能需要执行人工签名者交换才能使一切正常工作。这是一个基本的 SSL 管理要求，通常需要人员来制定信任决策。每当迁移和合并代码认为证书和/或密钥存储区配置经过了自定义，它就宁可认为还没有进行签名者交换，以避免作出意外的信任决策。
管理加密密钥的生命周期
加密密钥的一个基本原则是应该不时地更改它们。认识到这个需要，WebSphere Application Server 现在包括了用于管理加密密钥生命周期的功能。此新功能用于管理 LTPA 加密密钥的生命周期。然而，此功能还可供应用程序使用。
以前的发行版仅存储一组 LTPA 密钥。当这些密钥在运行时中被更改时，运行时会删除旧密钥，然后仅使用新密钥。由于一般最好定期更改 LTPA 加密密钥，因此这种行为会导致中断。当密钥被更改时，所有的现有 LTPA 令牌（例如，在 Web 浏览器中创建的令牌）将不再可用，因为无法对它们解密。
WebSphere Application Server V6.1 中创建了一个通用密钥管理基础设施，它不仅供 LTPA 使用，而且还供需要执行加密的应用程序使用。此框架将帮助管理活动的密钥引用，并按计划的时间期限重新生成新密钥。对于 LTPA，缺省配置是每隔 90 天生成新密钥，并在任何给定的时间认可两个 LTPA 加密密钥。新的加密密钥用于生成/验证新令牌，旧的加密密钥用于验证旧令牌。由于 LTPA 令牌通常仅在几小时内有效，此方法以少许额外的加密工作为代价，从而确保更新加密密钥不会导致任何中断。可以想象的到，WebSphere Application Server 首先尝试使用新密钥来解密 LTPA 令牌，如果失败，则尝试使用旧密钥。这具有一些开销，但是相当小，因为仅有两个密钥版本受支持，并且使用以前密钥版本创建的 LTPA 令牌数量应该会快速减少。
图 19. 密钥生命周期管理基础设施
图 19 显示了 com.ibm.websphere.crypto.KeySetHelper API 如何与密钥管理运行时和配置进行交互。com.ibm.websphere.crypto.KeySetHelper API 由 LTPA 令牌组件在内部使用。应用程序也可以使用它来请求密钥，尽管我们不再对此作进一步的讨论。这里存在几个基本部分：
- 密钥存储区，其中包含多个版本的加密密钥。
- 密钥生成器，它们生成密钥。KeyPairGenerator 用于公钥/私钥对，KeyGenerator 用于机密密钥。
- 密钥集，包含和管理密钥，并使用密钥生成器来生成它们。
- 密钥集组，对跨多个密钥集的新密钥生成进行计划和管理。
下面我们将更详细地查看这些部分。
使用 KeySet 来管理密钥
KeySet 是用于跟踪特定密钥类型的配置对象。密钥类型可以是对称机密密钥或不对称密钥对（公钥和私钥）。KeySet 管理将在其中存储密钥的 KeyStore、正在活动地引用的别名和确定密钥生成方式详细信息的实现类。
确定密钥属性（如密钥长度、算法，等等）不是 KeySet 的工作；它仅知道密钥是密钥对还是机密密钥，因此它知道如何存储密钥。密钥对非常特殊，因为它们有两个关联的密钥，并且需要存储在某个相似的别名下以便检索。KeySet 将一个密钥对作为单个密钥引用来进行管理。
图 20 显示了 KeySet 配置中跟踪的信息。一旦配置了 KeySet，则通常将其放在 KeySetGroup 中，后者控制密钥生成的计划，等等，下面将对其进行讨论。有关 KeySet 的更多信息，请参见信息中心的 Creating a key set configuration。
图 20. KeySet 配置面板
使用 KeySetGroup 来组织 KeySet
KeySetGroup 管理一个或多个 KeySet。之所以出现这种情况，是因为多个密钥集可能以某种方式相关，它们全都需要同时更新。KeySetGroup 可用于更新所包含的 KeySet，无论是人工更新还是按计划自动更新。
在按计划进行更新时，调度程序会创建一个“next start date”值，此值存储在配置中，并在控制台中可见。一旦到达下一个开始日期，则会在部署管理器（对于 Network Deployment）或 Base Application Server（对于独立服务器）中执行自动密钥生成。如果在“next start date”时间过去之后，这两个进程中的任何一个进程没有启动，则会在那些进程下一次启动时执行密钥生成，并计算一个新的“next start date”。图 21 显示了用于配置 KeySetGroup 的面板。有关更多信息，请参见信息中心的 Creating a key set group configuration。
图 21. KeySetGroup 配置面板
LTPA 使用 KeySetGroup 来管理密钥
| | 细心的读者可能注意到，在配置 LTPA 时不再需要 LTPA 密码。相反，您只需在导入或导出 LTPA 密钥时指定 LTPA 密码。仅当将密钥导出到用于配置跨单元的 SSO 的属性文件时，才会使用 LTPA 密码来对密钥加密。 |
|
正如已经提到过的，LTPA 密钥在概要创建期间自动生成。从那以后，LTPA 密钥就通过 CellLTPAKeySetGroup（对于 Network Deployment）或 NodeLTPAKeySetGroup（对于 WebSphere Application Server base）来进行管理。图 22 显示了身份验证机制面板，您可以通过导航到 Secure administration, applications, and infrastructure => Authentication mechanisms and expiration 来访问该面板。请注意，其中指示了使用中的密钥集组。
图 22. LTPA 对 CellLTPAKeySetGroup 的引用
配置 LTPA 跨单元单点登录
遗憾的是，世界上没有免费的午餐。虽然新的 LTPA 密钥管理方法在安全性方面是个巨大的改进，但它影响跨单元的单点登录（Single Sign-On，SSO）。跨单元 SSO 依赖不同的单元共享相同的 LTPA 加密密钥——这就是单元之间能够相互信任彼此的 LTPA 令牌的原因。
与以前版本一样，若要配置 SSO，您必须从一个单元导入当前活动的 LTPA 密钥，并将它们导入另一个单元。然而，必须作出一个非常重要的配置更改：必须禁用自动密钥重新生成。如果不这样做，则在单元自动生成 LTPA 加密密钥的新版本时，它们将无法通信，因为它们的 LTPA 加密密钥不相同。
再次观察图 22 并注意与 CellLTPAKeySetGroup 对应的 Automatically generate keys 复选框。在交换 LTPA 密钥前，应同时在两个单元中禁用此复选框并保存配置。您仍然可以不时地在一个单元中人工生成 LTPA 加密密钥，然后将它们导入另一个单元中。这样，您就可以维持 SSO 并更改密钥。
结束语
本文概述了 WebSphere Application Server V6.1 为增强 SSL 运行时和配置而作的更改。缺省情况下，WebSphere Application Server 比以往任何时候都更安全，并且通过集中管理配置和使得 SSL 配置对拓扑更加敏感，从而使您更容易适应拓扑更改。这些更改还为进一步的增强奠定了基础，以便进一步简化和扩展 SSL、证书和密钥管理功能。
术语
下面提供本文中使用的部分基本术语的定义。
SSL——安全套接字层；一种用于通过签名和加密来在各种其他协议上建立真实性、完整性和机密性的协议。 真实性——确定连接一端或另一端具有它们所声称身份的过程，此过程基于双方已建立的证据（签名证书）。缺省情况下，SSL 客户端验证服务器的身份，但是 SSL 服务器不验证客户端的身份。您可以配置“相互”身份验证，从而同时在两个方向对证书进行验证。 完整性——验证数据在传输时未被动态修改的过程。这是通过创建发送端的数据摘要并将其与接收端的数据摘要进行比较来完成的。两个摘要必须准确匹配才能确保完整性。 机密性——确保其他人无法读取传输中的信息（从而需要加密）的过程。加密过程从纯文本创建密码文本。密码文本通过网络发送，并且不能人工读取。然后使用某个共享密钥（在 SSL 握手期间协商）来对密码文本解密，以将其恢复为人工可读取的纯文本（至少是其开始时的格式）。 X509Certificate——表示某个实体或人员身份的对象。其中包含区别名称（Distinguished Name，DN）和其他可使用的扩展（属性），如电子邮件，等等。X509Certificate 与某个公钥和私钥关联：公钥在证书内，而私钥在证书所代表实体的紧密控制下进行维护。私钥从不应该共享，但是将公钥提供给其他实体以便他们信任是完全可以的。 密钥存储区（JSSE 术语）存储个人证书，其代表 X509Certificate、公钥和私钥。这是该实体身份的表示形式。 信任存储区（JSSE 术语）仅存储 X509Certificate 和公钥（也称为签名者证书）。信任存储区必须包含来自它所信任的所有其他实体的所有签名者证书，以便与它们建立连接。如果没有远程实体的签名者证书，则会发生一个 SSLHandshakeException，并产生内容为“No trusted certificate found”的消息。 密钥管理器是执行以下功能的代码：它基于目标服务器在握手期间发送的可用签名者，从而在 SSL 握手期间从指定密钥存储区选择证书。有些密钥管理器基于已配置的属性来作出证书选择。WebSphere Application Server 使用 com.ibm.ssl.keyStoreClientAlias（对于客户端证书选择）和 com.ibm.ssl.keyStoreServerAlias（对于服务器证书选择）。 信任管理器是在握手期间作出信任决策的代码。缺省的 IbmX509 信任管理器执行证书验证，例如签名验证和过期检查。缺省的 IbmPKIX 信任管理器执行同样的验证，外加上更高级的证书吊销列表（Certificate Revocation List，CRL）检查，此检查确定证书是否已被证书颁发机构（Certificate Authority，CA）删除。CRL 分发点 (DP) 扩展可用于在接收证书时获得 CRL。当选择了 IbmPKIX 信任管理器并且存在此扩展时，则会自动获得 CRL。此外，在线证书状态协议（Online Certificate Status Protocol，OCSP）可用于执行证书有效性的在线检查；这要求指定附加的系统属性，IBM developerWorks 上的 JDK CertPath API 文档对此作了描述。
参考资料
作者简介 | | | Peter Birk 是 WebSphere Application Server Security Development 的一名高级软件工程师。Birk 先生在 WebSphere Security Development 团队已有超过 5 年的经验。Birk 先生曾经从事过各种各样的安全相关项目，包括 WebSphere Application Server v5.0 中用于 J2EE 1.4 遵从性 CSIv2 实现和 WebSphere Application Server v5.1.1 中的 Security Attribute Propagation 功能。他拥有奥斯汀德克萨斯大学的软件工程硕士学位和南佛罗里达大学的计算机工程学士学位。 |
对本文的评价
| 
