.Net和Java的互通

　　Java 的客户端和服务端Security互通很快就搞定了，只是对于一些应用场景做证书管理的扩展。然而，在经历了.net客户端调用Java发布的ws返回数组对象类型的问题以后，又一个大难题摆在了我的面前，ISV support小组和测试部的日报上把.net客户端无法在wsse的模式下调用Java 发布的 Web Service作为了重点问题，需要我支持，那么当然当仁不让的接下来尽快搞定了，虽然对.net来说，我算是新手中的新手，不过经过两天的测试，让我总结出了.net调试的技巧，那就是截包分析（感觉又回到我前几年在通信行业干活时的状况，对于对方协议不了解，又没有源码可看，那么就截报文来分析么）。开始挺乐观的，想着WS-Security微软也是参与者么，应该会严格遵守的，估计一天搞定，结果活活的折腾了两天，下面所描述的如何互通可能总的看起来应该不是很复杂，不过摸索的过程可真是很费事，google的每一条老外的信息都被我看过了，但是Question多Answer少。废话不多说，进入正题。

　　首先不管是什么客户端调用什么服务端，都需要先做一件事情，准备key pairs。在Java中证书管理库可以通过Jdk提供的key tools这个工具生成jks格式的Java Key Store，可以将公钥导出，或者将公钥导入，同时可以生成秘钥对保存在证书中。在.net中可以通过makecert的工具来生成符合Public Key Cryptography Standards #12，PKCS#12标准定义，包含了公钥和私钥的二进制格式的证书形式，以pfx作为证书文件后缀，同时可以通过mmc对windows的证书存储区进行管理，导入或者导出证书。其实.net和java的互通关键问题就是出在证书格式不同以及获取证书的算法上。下面就具体的描述一下如何从Java的开发者来做好Java WebService和.net互通的工作。

　　一．准备双方的证书和公钥

　　首先通过Java的keytools 生成了两个jks，一个叫做alisoft.jks，另一个叫做myisvdemo.jks，这里需要注意，在使用keytools生成证书的时候会提示需要输入两个密码，一个是keystore的密码（每次对keystore作操作的时候都需要输入密码来验证），另一个是私钥保护密码（使用私钥作签名或者加密的时候需要输入），这两个密码可以设置为不同的值，不过为了后面转换为.net的pfx格式的证书需要，两者需要设置为相同，同时在早期的tomcat中使用证书也有这种限制。然后将两个证书都自签名并将公钥导出，分别叫做alisoft.rsa和myisvdemo.rsa（因为我这里用的是rsa算法，所以用了这个后缀，其实可以直接命名为.cer后缀，因为它们的类型其实就是base64编码后的没有私钥的证书，可以直接导入到windows中）。

　　准备好了这四份文件以后，将myisvdemo.rsa导入到alisoft.jks中（由于测试不采用上面提到的数据库存储的方式，因此直接导入作测试）。然后，通过一个叫做jks2pfx的工具包，将myisvdemo.jks转成为myisvdemo.pfx文件，通过mmc导入到本地计算机的证书管理中。

　　这时候，双击这两个证书都会显示当前的Ca根证书不受信任，可以直接拖动复制增加到受信任的根证书颁发机构的证书中，就不会再显示这样的提示了。最后分别将这两个证书在复制到受信任人的证书中。至此，客户端和服务端的证书都已经准备好了，接下去就是如何配置使用.net的客户端来调用已经发布成为带有WSSE的Java Web Service了。