内容


IBM WebSphere 开发者技术期刊

在 WebSphere Application Server 中使用 Java Secure Socket Extension

JSSE 的内容是什么?

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

此内容是该系列的一部分:IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

引言

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 上的可用资源时它是多么简单。最后,我们说明了怎样在单一应用程序中同时使用多重密钥库/信任库。

配置及安装 IBM JSSE:我需要做什么吗?

WebSphere Application Server V5(以及后续的)和 WebSphere Studio V5 一起传输 ibmjsse.jar(支持 JSSE 1.0.3 版本)及其相关的 certpath.jar。因此,IBM JSSE 由运行在 WebSphere Application Server 环境下的应用程序自动地使用。重申,WebSphere Application 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. 客户端和服务器信任库/密钥库间的关系
图 1. 客户端和服务器信任库/密钥库间的关系
图 1. 客户端和服务器信任库/密钥库间的关系

公有密钥分布于名为公钥证书(PKC)的容器中。这些是由某一签名者(通常是 Certificate Authority,但公钥可以是自签名的)数字化地签署的。数字签名标志原始的真实性的验证。要记住的一点是相信计算机安全一定能通过计算的方法验证。为了验证公钥证书是合法的,我需要检验发出该签名的签名者。相反,这个过程是基于签名者的公有密钥的。

在这里使用信任库。当将 JSSE 用于 SSL 通信时,需要在本地存储中维护一套信任的签名者的证书,由此得名信任库。例如,由 JSSE 运行时使用的客户端信任库为了验证试图连接到服务器的客户端确实使用合法的证书(由信任的签名者发出的)与服务器交互。因此,服务器证书的签名者必须持有保存在客户端信任库中的 PKC。图 1 阐明了客户端和服务器信任库/密钥库间的关系。

出于同样的机制,服务器必须本地保护它的私有密钥并且使其能够访问 JSSE 运行时。在此处使用密钥库。密钥库与信任库有相同的格式,它只包含了不同的密钥。实际上,专业术语“密钥库”通常表示“信任库或密钥库”。

总之,信任库包含了签名者的证书,该签名者在使用信任库的环境中得到信任。另一方面,密钥库维护了实体的私有密钥,及其相应的 PKC。例如,当服务器面向客户端进行自身验证时,它需要从其密钥库中检索它的私有密钥来与加入客户端的 SSL 握手。所以,应该确实地重视信任什么签名者;也就是说,使用信任库的哪些内容。IBM 提供的缺省信任库包括了一些公认的且广泛信任的 Certificate Authorites(CA)。在这里一种好的实践是周期性地浏览您的信任库并且作出您关于其内容可信性的判断——可能删除一些 CA。

现在我们已经知道信任库是什么以及密钥库是什么,让我们来了解一下使用 IBM JSSE 在 WebSphere Application Server 环境中是如何定义它们的。

如何指定密钥库和信任库

为了打开 JSSE 的连接,您必须在信任库和密钥库中拥有合适的证书以及私有密钥。您需要配置 JVM 来使用您的信任库或密钥库。然而,如果您仅执行服务器验证(就是说,客户端使服务器的证书生效,但不允许反向),那么您只需要信任库。

如果您在没有明确地指定信任库或密钥库的情况下创建 SSL 连接,那么 JSSE 运行时将会使用“缺省”库。对于 WebSphere Application Server 来说,意味着 cacerts 文件被用作缺省的信任库(位于 WAS 安装目录下的 java/jre/lib/security 中)。

如果您联系的站点使用由公认的 CA 发出的证书,那么 IBM 提供的缺省证书很可能已经包含了您需要的信息。您可以使用 IBM 提供的 iKeyman 工具(WebSphere Application Server 安装后自动可用)打开 cacerts 文件来确定 JDK 中包含什么证书。

如果您访问的站点没有使用由 CA 发出的证书,CA 被包含在 WebSphere Application Server 中,那么您需要获得它们的签名证书并且将其添加到信任库中。我们推荐您不要修改现有的 JDK 文件,而是使用 iKeyman 创建新的信任库。然后您需要配置 WebSphere Application Server 运行时来使用该信用库,。

为了配置 WebSphere Application Server 来使用定制的信任库,您需要设置 JVM System 属性 javax.net.ssl.trustStore。使用管理控制台设置 WebSphere Application Server 中的该 JVM 变量:

  1. 从管理控制台,导航到 Servers => Application Servers => server_name => Custom Properties => New
  2. 输入属性的名称:javax.net.ssl.trustStore
  3. 输入属性值,即您的信任库的完全限定的文件名。
  4. 添加您所希望的描述。
  5. 类似地,定义附带的属性,它维护访问您的信任库所需的密码,通过导航到 Servers => Application Servers => server_name => Custom Properties => New 来实现。
  6. 关于密码值的属性名称:javax.net.ssl.trustStorePassword。(这里请注意密码一直在 cleartext 之中。)
  7. 密钥库可以以相同的方式使用属性 javax.net.ssl.keyStore 及其相应的 javax.net.ssl.keyStorePassword 来定义。

您也可以在您的应用程序中对这些属性进行硬编码,如下面的实例所示,但这并不是一个好的做法,因为除了需要通过浏览您的代码来确定这些属性值之外,它还潜在地限制了您应用程序的可移植性:

System.setProperty("javax.net.ssl.trustStore",                    
                   "yourTrustStoreFile"); 
System.setProperty("javax.net.ssl.trustStorePassword",
                         "yourPassword")
System.setProperty("javax.net.ssl.trustStorePassword",
                         "yourPassword")
System.setProperty("javax.net.ssl.keyStore",                    
                   "yourKeyStoreFile");

对于大多数情况,这样的配置就足够了。极少的情况下,您可能需要不只一个单独的缺省信任库/密钥库。随后,您将会看到如何程序化地将您的信任库和密钥库指定到 JSSE 运行时中,以及如何在您的应用程序中使用多重信任库及密钥库。

信任库搜索顺序

您已经看到了,您既可以依靠缺省的 cacerts 文件也可以定义您自己的信任库。这可能使您想了解 JVM 是如何搜索信任库的。

当需要信任库的时候,按照下面的顺序进行搜索直至找到与之匹配的为止:

  1. 如果已经通过 Java API(上面讨论的)程序化地定义了信任库,那么就将其用作信任库。
  2. 如果定义了 javax.net.ssl.trustStore 系统属性,那么就将属性值用作信任库的位置。
  3. 如果文件 lib\security\jssecacerts 没有定义在 java\jre 目录下,那么 jssecacerts 文件就被用作信任库。(WebSphere Application Server 没有传输 jssecacerts。我们只是为了完整性而叙述它,所以您可以忽略这一情况。)
  4. 如果文件 lib\security\jssecacerts 没有定义在 java\jre 目录下,那么 cacerts 文件就被用作信任库。

如果找到了特殊的信任库,那么搜索停止并且将这个找出的文件作为您的信任库。例如,如果通过使用其 Java System 属性指定信任库,如果在信任库中找不到有效的签名者,那么搜索将不会向后继续。

如果使用我自己的信任库或密钥库我需要什么?

WebSphere Application Server 传输名为 iKeyman 的实用程序,它在安装 WebSphere Application Server 后自动生效。它位于您的 WAS Install Root 下的 bin 目录中。(参阅由 WAS 绑定的 iKeyman 文档的详细信息来了解如何使用该功能,请见参考资料。)

简而言之,iKeyman 管理密钥库。密钥库以某种格式出现并且 iKeyman 支持最普通的格式,包括 Java Key Store,称为 JKS,它是 Java 应用程序所使用的“正常”格式(事实上,cacerts 信任库就是采用的这种格式)。

接下来,我们将会看到使用 iKeyman 创建自签名证书的简单实例。如果您与之通信的一方使用相同的证书就很恰当。如果他们已经拥有了他们自己的证书,那么您需要导入现有的签名证书,就像之前提到的那样。

为了启动这该流程,通过运行 ikeyman.bat(在 Windows 平台上的)来执行 iKeyman 工具。该工具显示了图形界面,如图 2 所示。

图 2. iKeyman GUI
图 2. iKeyman GUI
图 2. iKeyman GUI

生成包含了诸如自签名证书的密钥库:

  1. 选择 Key Database File => New
  2. 确定密钥数据库类型是用于 Java Key Store 的 JKS
  3. 输入文件名以及其位置(将 .jks 添加到您的文件中),然后选择 OK
  4. 填写密码值(此处不使用主要密码的检验规则),然后点击 OK
  5. 单击 Create,然后选择 New-Self-Signed Certificate
  6. 输入需要的证书信息,然后点击 OK
  7. 这时,您的密钥库中包含了您的私有密钥及您的公钥证书。突出显示您的密钥库文件名,然后选择 View/Edit。您应该看到图 3 所示的内容。
图 3. 密钥信息
图 3. 密钥信息
图 3. 密钥信息

您可以使用 iKeyman 来创建新的自签名证书,如我们刚才所示,或是向您的信任库中添加 CA 证书。而在此处我们不对其进行讨论,如果您希望使用 iKeyman 来向密钥库中添加新的证书,那么请记住,iKeyman 可以从二进制 DER 格式的文件中或从 base64 ARM 格式的文件中导入证书。(DER 代表 Distinguished Encoding Rules,它是数据编码的标准,并且 ARM 是 ASCII-armored-64 格式。)

当通过 URL 公布目标应用程序时如何使用 SSL ?

接下来,我们将要显示如何使用 JSSE 在 HTTP 上连接远程服务器的简单实例。在此实例中,我们假设现有的信任库中已经包含了所需的证书信息。接下来的步骤概括了必要的操作,它们使得 WebSphere Application Server 服务器端代码能够充当另一个远程服务器的 HTTP 客户端。

配置 JSSE 和 HTTP 所需的 JVM 属性

通过 JVM 配置,添加 com.ibm.net.ssl.internal.www.protocol 作为 Java 协议处理程序。缺省情况下,没有设置任何处理程序,所以这一步骤是必需的。最好将其定义为您的 JVM 属性的一部分,而不是在您的应用程序中对它进行硬编码。按照与定义密钥库/信任库属性相同的说明并且添加该属性: java.protocol.handler.pkgs,及其值:com.ibm.net.ssl.internal.www.protocol。该属性表明我们将 IBM HTTP 包用于 JSSE 框架。

如先前描述的那样使用 JVM 定制属性来定义您的信任库以及密钥库。由于缺省情况下 SSL 协议认证客户端的服务器,所以您可能仅需要已定义的信任库。认证到服务器的客户端是可选择的并且由服务器端的设置来控制(请见参考资料)。然而,客户端应用程序需要指定其密钥库,如同我们描述的那样。

在 WebSphere Application Server 环境下运行的客户端也许会选择使用 WebSphere Application Server 服务器密钥库。可是,我们不推荐这样做,因为这样一来,客户端就充当应用程序服务器的身份。如果您关心非法访问 WebSphere Application Server 密钥库的应用程序代码,那么您可以启用 Java 2 安全。一旦它被启用,在没有明确授权许可的情况下 WebSphere Application Server 将不允许应用程序访问密钥库(事实上是无法访问任何文件)。

编写使用 HTTPS 的代码

使用 HTTP 的 JSSE 程序 API 是非常简单的。本质上,从代码中显式地使用 JSSE,该代码打开了指向 HTTPS 的 URL。下几行演示了将 URL 创建到 HTTP 端点以及打开 HTTP 的连接。务必要恰当地处理任何可应用的异常(参考 Java 网络程序程序设计参考资料)。

String stringURL =
"https://targetHost:9443/MyWebApps/servlet/myServlet";
URL url = new URL(stringURL); 
HttpsURLConnection urlc =(HttpsURLConnection)url.openConnection();

现在您可以按照正常的编程模型来编写您应用程序的其他内容。例如,现在您可以从该 URL 连接中读取。

这些简单的行中隐藏了大量的复杂内容。当第一次使用 URL 连接时,SSL 握手将自动地发生,通过客户端接收服务器证书并且对照信任库验证证书的方法来认证客户端的服务器。同理,如果合适的密钥库是可用的并且服务器请求它,那么可能发生客户端认证。这一切通过 JSSE 运行时对您都是透明的。您的与目标服务器的交换现在受底层 SSL 信道保护。

终端验证
关于在此场景中使用 SSL 的很重要的一点是客户端没有验证与之通信的服务器实际上是预期的一方。在此场景中的证书认证实际上意味着“是服务器提供了有效的证书吗?”JSSE 运行时将会确保这一点,但它无法保证服务器是正确的服务器。Web 浏览器围绕该问题展开工作,通过在生效之后校验服务器证书来了解是否证书中的 Subject 名称与被访问的 DNS 主机名相一致。为了获得最高程度的安全(如果您关心这个特别细微——并且难于开发——安全漏洞),您应该执行类似于 Web 浏览器的验证,并且使用 HttpsURLConnection.getServerCertificates() 来确定服务器的证书。

特殊情形:Web 服务客户端

如果您对于使用 HTTP 作为客户端访问 Web 服务终端感兴趣,那么您可以做一些类似于先前的实例的操作。第二个实例使用 IBM 工具生成的 Web 服务客户端代理来打开 HTTP 连接。如同先前实例所示,我们假设已经遵循了本文前面所指明的步骤。

String string URL =   
             "https://targetHost:9443/MyWebApps/services/MyService";
	ServiceProxy proxy = new ServiceProxy();
	proxy.setEndPoint(stringURL);
	// proceed to invoke the proxy methods based on your application
	// ServiceProxy should be replaced by the name of your own application proxy
       ...

客户端 JSSE 套接字程序设计

我们已经向您展示了怎样打开隐式地使用 JSSE 的 HTTP 连接。在很多情况下,那是您所需的。虽然有时,当您访问使用 SSL 而不是 HTTPS 的对象时直接编码到 JSSE API 中是必要的。接下来,我们给出了具有少量代码的样例,该样例向您展示了基本内容。如前所述,我们假设您已经配置好了信任库和密钥库的环境属性。

实质上,我们获得 SSL 套接字工厂(缺省的也应该可以),从中创建 SSL 套接字,并且开始对其进行读写:

SSLSocketFactory sslFactory=(SSLSocketFactory)SSLSocketFactory.getDefault();
//substitute your targetHost and port
SSLSocket s=(SSLSocket)sslFactory.createSocket(targetHost,port); 

// example
OutputStream out=s.getOutputStream();
InputStream in=s.getInputStream();

无需调用 SSLSocket.startHandshake(),除非您希望重置握手的参数。

我可以同步地使用多重密钥库/信任库吗?

到目前为止,在我们的实例中假设存在一个通过 JVM 使用的信任库和密钥库。同时与多重服务交互的客户端也许会找到使用多重密钥库或信任库的需求,以便与每个独立目标应用程序建立 SSL 连接。JSSE 程序设计模型通过维护每个目标交互的独立 SSL 上下文来多重使用这样的证书库。每个这样的上下文都是由新的 SSLContext 对象封装的。下述的程序设计顺序展示了如何定义多重密钥库/信任库:

  1. 将您需要的密钥库载入运行时:

    KeyStore ks = KeyStore.getInstance("JKS");
    ks.load(new FileInputStream("yourKeyStore"),
            "yourPassword".toCharArray());
  2. 实例化然后初始化 KeyManagerFactory 对象来封装底层密钥库:

    KeyManagerFactory kmf = KeyManagerFactory.getInstance("IbmX509");
    kmf.init(ks, "yourPassword".toCharArray());
  3. 将您需要的信任库库载入运行时(实例化为 KeyStore 对象):

    KeyStore ts = KeyStore.getInstance("JKS");
    ts.load(new FileInputStream("yourTrustStore"), 
            "yourPassword".toCharArray());
  4. 实例化 TrustManagerFactory 对象并且使用您的信任库将其初始化:

    TrustManager[] tm;
    TrustManagerFactory tmf = 
                    TrustManagerFactory.getInstance("IbmX509");
    tmf.init(ts);
    tm = tmf.getTrustManagers();
  5. 获得 SSLContext 类的实例:

    sslContext = SSLContext.getInstance("SSL");
  6. 使用当前的信任管理员(封装带信任的 CA)以及密钥管理员(封装客户端的证书)初始化该实例:

    sslContext.init(kmf.getKeyManagers(), tm, null);
  7. 使用当前的 SSLContext 对象来获取 SSL Socket Factory 并且实例化其中的 SSL 套接字,如同前面章节中所描述的:

    SSLSocketFactory factory = sslContext.getSocketFactory();

此处的关键是 SSLContext 类并不是唯一的;也就是说,每个 getInstance 调用返回了不同的 SSLContext 对象。

具有多重密钥库的 HTTPS

如我们所见,用于 HTTPS URL 实现的信任和密钥管理是环境指定的。这使得通过简单配置或指定一些 JVM 属性来使用 SSL 变得非常容易。然而,该方法存在缺陷,即指定的属性将规定单一的信任库/密钥库。为了解决这一问题,我们使用 JSSE 接口为每个独立的 HTTP 连接定义 SSLContext。下述的编码向您展示了如何为您的 URL 连接建立定制的密钥库/信任库:

KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream("yourKeyStore"),   
                            "yourPassword".toCharArray());
KeyManagerFactory kmf = KeyManagerFactory.getInstance("IbmX509");
kmf.init(ks, " yourPassword ".toCharArray());
TrustManager[] tm;
TrustManagerFactory tmf = TrustManagerFactory.getInstance("IbmX509");
tmf.init(ks);
tm = tmf.getTrustManagers();
KeyStore ts = KeyStore.getInstance("JKS");
ts.load(new FileInputStream("yourTrustStore"), 
        "yourPassword".toCharArray());
TrustManager[] tm;
TrustManagerFactory tmf = 
                TrustManagerFactory.getInstance("IbmX509");
tmf.init(ts);
tm = tmf.getTrustManagers();
SSLContext sslContext = SSLContext.getInstance("SSL");
sslContext.init(kmf.getKeyManagers(), tm, null);
SSLSocketFactory sslSocketFactory =
        sslContext.getSocketFactory();
URL url = new URL(stringURL);
urlc = (HttpsURLConnection) url.openConnection();
urlc.setSSLSocketFactory(sslSocketFactory);
// at this point communication with this target url
// is set to use SSL with your custom truststore and keystore

而我们无法在此展示,如果您希望执行一些类似于 Web 服务客户端的操作,那么您必须通过 Web 服务客户端部署描述符来指定使用的 keyrings。

结束语

WebSphere Application Server 充分地支持 JSSE 作为框架的 SPI 提供方,以及作为一组用户 API。同样的,对于需要在 WebSphere Application Server 环境中建立 SSL/TLS 连接的应用程序而言,JSSE 是易于使用的。在本文中,我们检验并且提出了使用 JSSE 的推荐方法,着重强调怎样通过避免对 JSSE 实现所特有的结构进行硬编码来维护应用程序的可移植性。当然,要记住 SSL/TLS 连接的信任基础主要依赖于公钥证书及其相应的私有密钥的可靠性和安全性。我们也描述了如何在您的应用程序中使用定制的信任库以及密钥库,以及如何使用多重这样的结构来与不同实体建立连接。


相关主题

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文
  • Introduction to the Public Key Infrastructure for the Internet,Messaoud Benantar,Prentice Hall,ISBN 0-13-060927-7,2001
  • IBM Secure Socket Layer Introduction and iKeyman
  • SSL and TLS,Designing and Building Secure Systems,Eric Rescorla

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=83669
ArticleTitle=IBM WebSphere 开发者技术期刊: 在 WebSphere Application Server 中使用 Java Secure Socket Extension
publish-date=04012005