您的位置:在 WAS 中使用 Java 安全套接字扩展(图) (1)
[ 来源：互网络 | 更新日期:2007-10-05 04:19:41 | 浏览次数：9355]
简介：对于大多数情况，这样的配置就足够了。极少的情况下，您可能需要不只一个单独的缺省信任库/密钥库。随后，您将会看到如何程序化地将您的信任库和密钥库指定到 JSSE 运行时中，以及如何在您的应用程序中使用多重信任库及密钥库。
引言
Java 安全套接字扩展（Java Secure Socket Extension，JSSE）是将低级编程接口封装到安全套接字层（Secure Socket Layer，SSL）协议及其相应的标准传输层安全性（Transport Layer Security，TLS）协议中的 Java 标准。IBM JSSE 是 JSSE 框架的 Java 实现。它支持 SSL V2 和 V3 以及 TLS V1。将 JSSE 这样架构以便其能够提供两套接口：一套被称为服务提供方接口（Service Provider Interface，SPI），而另一套是应用程序编程接口（Application Programming Interface，API）。
那些提供特定实现的功能插件使用提供的程序接口（本质上，是接口中的插件）。通常，应用程序开发人员仅处理 API。他们可以编写可移植的代码，该代码仅依赖于标准的公共 API 中公布的方法。IBM JSSE 实现也包括 IBM JSSE 加密提供方。
重要的是，开发人员应该遵循最佳的编程实践来启用应用程序的可移植性。只要没有将提供应用程序的特定信息的用法嵌入或强制编码到应用程序中，JSSE API 就可以进行移植。IBM 没有声明与其它 JSSE 提供方的互操作性。IBM 开发实验室没有执行任何正式的测试。
分离 API 和 SPI 接口的目的在于保护来源于程序提供者的应用程序，以便达到可移植性。但每个程序提供者所提供的功能可能不必与其它提供的功能相匹配。IBM JSSE 包括了 IBM 的提供方，而其他供应商拥有自己的提供方。当使用 WebSphere Application Server 时，例如，我们重在 IBM 自己的提供方。因此，应用程序代码假设任何特殊的提供方都是不可移植的。一个公共实例是显式地装载了 com.sun.* 类的应用程序代码。由于 com.sun.* 不是 JSSE（或者对于那种情况是 J2SE）的一部分，所以这样的代码是不可移植的。当您开发您的代码时，应该尽量避免程序提供者所特有的依赖。我们此处的实例说明了这种方法。
简化 JSSE 编程很大程度上是由于高级别的抽象，它提供了关于标准套接字的编程接口。这使得在两个希望使用 TCP/IP 协议上的传输层安全性来进行消息传递的终端之间建立网络连接变得非常容易。由 JSSE 提供的安全性服务是由传输层消息完整性、可靠性（加密）、服务器验证、以及可选的客户端验证组成。
在本文中，我们提出了 IBM JSSE 的配置问题，探讨了密钥库和信任库，并且推荐了在 WebSphere Application Server 环境下处理这些重要的 JSSE 元素的方法。随后，我们给出了 JSSE 编程模型并且说明当访问 HTTPS 上的可用资源时它是多么简单。最后，我们说明了怎样在单一应用程序中同时使用多重密钥库/信任库。
SSL 是由 Netscape Communications Corporation 于 1994 年开发的，而 TLS V1.0 是由 Internet Engineering Task Force（IETF）定义的标准，它基于 SSL V3.0，并且在使用的加密算法上与其有些许的不同。例如，SSL 使用 Message Authentication Code（MAC）算法来生成完整性校验值，而 TLS 应用密钥的 Hashing for Message Authentication Code（HMAC）算法。
配置及安装 IBM JSSE：我需要做什么吗？
WebSphere Application Server V5（以及后续的）和 WebSphere Studio V5 一起传输 ibmjsse.jar（支持 JSSE 1.0.3 版本）及其相关的 certpath.jar。因此，IBM JSSE 由运行在 WebSphere Application Server 环境下的应用程序自动地使用。重申，WebSphere Appl
