在 WAS 中使用 Java 安全套接字扩展(图) (2)

ication Server 包括了 JSSE 并完全地未经优化的支持它。您的部分中无需进一步的安装；事实上，禁止替换其他来源的 JSSE 或 JCE 实现。（您不能忽略核心的运行函数。当然，您可以拥有额外的提供方，但不能替换那里已存在的提供方）。您必须确保 JSSE 及其支持的 JAR 文件，例如 certpath.jar，在开发过程中位于您的类路径上（在运行时它们常常位于类路径上）。certpath.jar 是一个包，包含证书路径结构及 JSSE 运行时需要的验证功能，以便建立证书信任路径。您无需对 certpath.jar API 编程来建立 SSL/TLS 通信通道，但 JSSE 将会使用它。
　　
　　IBM JSSE 提供了 JSSE 功能用于您的 WebSphere Application Server 环境以及部署过的应用程序。这是静态地设置在 java.security 配置文件中的，该文件位于您的 WAS 安装路径下的 JDK 目录中。下面是 Windows? 系统的 java.security 文件中未经优化的缺省提供方的清单。注意，不同平台之间的提供方的名称是一样的；然而，排序可能是不同的。无论何种平台，您的用于 WebSphere Application Sever 的未经优化的 JSSE 提供方都是 IBMJSSEProvider。
　　
　　#
　　# List of providers and their preference orders
　　#
　　security.provider.1=sun.security.provider.Sun
　　security.provider.2=com.ibm.crypto.provider.IBMJCE
　　security.provider.3=com.ibm.jsse.IBMJSSEProvider
　　security.provider.4=com.ibm.security.cert.IBMCertPath
　　security.provider.5=com.ibm.crypto.pkcs11.provider.IBMPKCS11
　　
　　您无需更改其中的任一个。如果您很好奇，那么此处存在大量的提供方，大多数都与 JSSE 无关。与 JSSE 相关的提供方只是 IBMJSSEProvider、IBMJCE 以及 IBMCertPath。后两者由 IBMJSSEProvider 隐含地使用来进行证书处理及加密操作。
　　
　　信任库和密钥库：它们是什么以及我为何关注它们？
　　
　　SSL 协议基于公钥密码，加密密钥成对地出现在公钥密码中，它们是在数学上是相关的，但无法由一个推知另一个。这对加密密钥由私有密钥和公有密钥（私有，公共）组成的。私有密钥一直处于其所属实体的保护之下。注意，所有者确实拥有这对加密密钥，但公共密钥，如同它的名称所示，可以为众所周知，或至少自由地分散到与公共/私有密钥对通信的实体中。公钥密码启用的安全性服务是基于这样的消息解密机制，即共有密钥只能通过相应的私有密钥才能解密，反之亦然。这样，如果使用实体的公钥加密消息，那么可以保证只有该实体能够解密此消息。这时会在脑海中立即出现一个问题，即怎样确保正在使用的公钥的确被绑定到合法实体上而没有绑定到其它实体上。在此 Public Key Infrastructures（PKI）开始起作用了（请见参考资料）。
　　
　　 图 1. 客户端和服务器信任库/密钥库间的关系
　　　
　　公有密钥分布于名为公钥证书（PKC）的容器中。这些是由某一签名者（通常是 Certificate Authority，但公钥可以是自签名的）数字化地签署的。数字签名标志原始的真实性的验证。要记住的一点是相信计算机安全一定能通过计算的方法验证。为了验证公钥证书是合法的，我需要检验发出该签名的签名者。相反，这个过程是基于签名者的公有密钥的。
　　
　　在这里使用信任库。当将 JSSE 用于 SSL 通信时，需要在本地存储中维护一套信任的签名者的证书，由此得名信任库。例如，由 JSSE 运行时使用的客户端信任库为了验证试图连接到服务器的客户端确实使用合法的证书（由信任的签名者发出的