第一个不同是在安全头部中出现了 <xenc:EncryptedKey> 元素。这个元素的内容提供了一个加密了的秘密密匙，使用了服务器的公开密匙执行加密。第二个不同之处在于实际的 SOAP Body 内容，它被替换为 <xenc:EncryptedData> 元素。这个已加密的数据从安全头部引用 <xenc:EncryptedKey> 值作为在 Body 内容中用于对称加密的密匙。

使用自己的自签名证书

要获得由权威认证机构签名的官方数字证书，需要生成一个公开-私有密匙对并使用公开密匙生成证书请求。然后将证书请求发送给您选择的机构并支付费用。证书机构将验证您的身份（保证整个过程的完整性的重要一步，但是可能会出现错误），并发出具有其签名的证书。

如果用于测试或内部用途，可以生成您自己的自签名证书。本文的示例代码使用了两个这种自签名证书，一个用于客户机，一个用于服务器。用于客户端的 client.keystore keystore 包含了客户机的私有密匙和证书，以及服务器证书（必须存储在客户机，这样在用于签名时，无需证书机构的签名就可以被作为有效证书接受，并且也可以直接用于加密）。用于服务器端的 server.keystore keystore 包含了服务器的私有密匙和证书，以及客户机证书（这样证书就可以作为有效证书被接受）。

您可以生成自己的私有密匙和自签名证书，并使用自己生成的密匙-证书对替换下载中的相应内容。要使用 JDK 附带的 keytool 程序实现替换，请打开控制台并输入以下命令代码（在这里将代码分解成多个行以适应页宽；您在输入时必须作为单一行输入）：

keytool -genkey -alias serverkey -keypass serverpass -keyalg RSA -sigalg SHA1withRSA 
   -keystore server.keystore -storepass nosecret

上面的命令生成了别名为 serverkey 的服务器密匙和证书，保存在名为 server.keystore 的新 keystore 中。（如果在此目录中已经有一个 server.keystore，那么首先需要删除使用该别名的现有密匙对）。keytool 提示了许多用于生成认证的信息项（这些信息都不会影响测试使用）并要求您确认这些信息。通过输入 yes 确认后，keytool 将使用私有密匙和证书创建 keystore，随后退出该程序。

接下来，再次运行这个程序来生成客户机密匙对和 keystore，这一次使用以下的命令（以单行形式输入）：

keytool -genkey -alias clientkey -keypass clientpass -keyalg RSA -sigalg SHA1withRSA 
   -keystore client.keystore -storepass nosecret

下一步是从服务器 storekey 导出证书，并将证书导入到客户机 keystore。要执行导出，使用下面的命令（为适应页面宽度而进行了分解；您必须以单行形式输入）：

keytool -export -alias serverkey -keystore server.keystore -storepass nosecret 
   -file servercert.cer

导出创建了一个名为 servercert.cer 的证书文件，您可以将它导入到客户机 keystore 中，使用以下命令（以单行形式输入）：

keytool -import -alias serverkey -keystore client.keystore -storepass nosecret 
   -file servercert.cer

运行导入命令时，keytool 输出了证书的细节并询问您是否信任该证书。当您通过输入 yes 接受密匙后，它将把证书添加到 keystore 并退出。

对于最后一步，导出客户机证书并将其导入到服务器 server keystore，输入以下命令（以单行形式输入）：

keytool -export -alias clientkey -keystore client.keystore -storepass nosecret 
   -file clientcert.cer

然后运行以下命令（为适应页面宽度而分行；您必须以单行形式输入）：

keytool -import -alias clientkey -keystore server.keystore -storepass nosecret 
   -file clientcert.cer

为什么要导出/导入两种证书？ 文本要求您为双方导出一个证书，然后将证书导入到另一方的 keystore。如果您使用了加密，那么需要为服务器证书执行这一操作，即使证书是由权威机构签名，因为加密需要访问另一方的公开密匙。另一方面，对于客户机证书，只需要将证书导入服务器 keystore，因为证书是自签名的并且无法通过其他方式验证。通过将证书导入到 keystore，您已经实现对其进行了确认，因此不需要再通过权威机构进行检验。 可以采用相同的办法处理多个使用自签名证书的客户机，只需要将每个客户机的证书导入到服务器 keystore。作为一种替代选择，与使用自签名证书不同的是，可以运行您自己的证书机构（使用 OpenSSL 之类的工具）并要求每个客户机获得由该机构签名的证书。通过这个方式，您可以向服务器 keystore 添加证书机构，并且任何具有由该机构签名的证书的客户机将被接受。或者通过支付费用来使用由权威机构签名的官方证书。

要利用新的密匙和证书，在运行客户机构建之前，必须将 client.keystore 文件复制到示例代码的 client/src 目录（或者只需将其复制到 client/bin 目录以立即生效），并在运行服务器构建之前将 server.keystore 文件复制到示例代码的 server/src 目录。

本节中的样例 keytool 命令使用了与附带的示例代码相同的文件名和密码。当您生成自己的密匙和证书时，您也可以修改这些值，但是那样做的话还需要修改示例代码以便匹配。在消息传递双方的策略文件中，keystore 密码和文件名都是 RampartConfig 中的参数。客户机密匙密码被硬编码到 com.sosnoski.ws.library.adb.PWCBHandler 类的客户机版本中，而服务器密匙密码则位于同一个类的服务器版本中。

结束语

在本文中，您了解了如何使用 Axis2 和 Rampart 实现基于策略的 WS-Security 加密和签名。这些强大的安全特性对于许多业务数据交换都至关重要，但是它们在处理开销方面会增加成本。在下一期 Java Web 服务 文章中，我们将介绍各种安全方法的相关性能开销情况，使您能够更好地判断如何在自己的应用程序中使用安全性。（责任编辑：A6）