噩梦开始了，到此为止，.net给web Service开发者带来的便利真的是无话可说，绝对的傻瓜级，但是就是这短短的几段代码，最后一句话执行的时候总是出现错误，那个黄色的小框让我看得快崩溃了。

　　根据上图的提示，错误应该在客户端这边，Java服务端也看过，已经接收到请求并且认证签名通过，并且反签发送回客户端，同时从Response的InnerXml中拷贝出来可以看到返回的结果Soap包都是正确的，客户端的错误就是Referenced security token could not be retrieved，这个就表明了客户端的alisoft的公钥没有找到，导致检查返回结果的时候出现了问题，那么就去找是否是因为格式不同导致公钥没有导入或者导入错误（错误的查错方向）。

　　最后发现原因出在了获取key的标示上，前面说到如果不是第三方权威的CA认证模式下，需要双方互相导入对方的公钥到本地的证书管理库中，我们是将Jks中的公钥导出，然后导入到了本机的证书管理模块中。公钥证书的引用在WS-Security中分成两种：SKIKeyIdentifier 和IssuerSerial，由于我们前面提到的扩展ISV证书动态载入的需要，我们一直使用的是IssuerSerical。但是微软的工具生成的是x.509v3版本，而java keytools生成的是x.509v1版本，如果使用IssuerSerical会有问题。那么只能使用SKIKeyIdentifier，但是使用SKIKeyIdentifier，.net默认使用的是自身的window的序列化方式，不过可以设置其为java的RFC3280协议方式，但是.net wse 2和wse 3的RFC3280方式都不一样，wse 2的可以和java互通，wse 3就不可以，也就是说2和3本身在RFC3280的序列化方式上都有差别，自己也不能互通，因此没有办法，只能够安装2版本，重新来生成。下面将描述一下如何用wse 2来订制web service 的WSSE客户端。

　　WSE2客户端的操作流程（使用的是WSE 2 sp3）：

　　首先还是要设置WSE的Policy到新建项目中去，不过这而WSE 2没有像WSE3那么好的集成到VS2005中，新建好工程以后，建立Web Reference（这和WSE3不太一样，这里先建Web Reference，然后手动的去设置）。同样去选择project菜单的show all files。这时候通过外部打开WSE 2的配置工具，配置工具选择打开新建的这个项目的app.config文件，然后开始配置策略。配置如下列图：

　　红色部分很重要，需要选择这种协议来序列化获得key reference。

　　这里配置策略文件有所不同，这里首先会让你输入这个Policy所属的URI，和3不同，3中是在代码中配置进去的，在配置中只是申明，而没有对应配置到具体的哪一个请求，这边可以填入某一个URI，那么你对那个URI的WebService做任何请求的时候都会采取该策略，同时如果你就不填任何内容，直接用他默认的<DefaultEndpoint>，那么所有不在指定URI对应策略中出现的URI请求和响应，都将采取这种策略，我就默认采用这种模式，因为如果不采用这种模式，相应回来的请求就找不到可以使用的策略了（这个出错信息也困扰我不少时间）。继续配置下面的内容：

　　这里我们只需要做signature，所以只配置了签名。

　　这里选择证书根据前面页面中配置的存储位置相关，第一个证书是用来签名的带有私钥的证书。第二个是受信的返回的签名交验证书。