应用WSDK －实践Web Services的X.509证书签名(序)

关注

原创最新推荐文章于 2026-07-16 15:58:25 发布 2.9k 阅读 AI 写同款· GEO 优化 ›

汽车LED驱动芯片TPS92682-Q1 SPI接口配置与调试实战指南 SPI（串行外设接口）作为一种高速、全双工的同步串行通信总线，广泛应用于微控制器与外围设备之间的数据交换。其工作原理基于主从架构，通过时钟、数据线和片选信号实现设备间的精准时序控制。在汽车电子和工业控制领域，SPI因其简单高效、易于扩展的特性，成为配置复杂电源管理芯片、传感器和存储器的关键技术。通过SPI接口，工程师能够动态调整设备参数、实时读取状态信息，并实现复杂的故障诊断与保护策略，极大地提升了系统的灵活性与可靠性。本文以汽车级双通道LED恒流驱动器TPS92682-Q1为例，深入解析如何通过SPI接口阅读详情

应用WSDK －实践Web Services的X.509证书签名

小气的神

2002-12-18

Article Type: OverView

难度等级：2/9

版本：1.18

好了，我想这是一个美貌的时刻，至少对于许多平凡、依赖、新潮而且很Cool的微软开发人员来说，WSE 1.0(Web Services Enhancements 1.0 for Microsoft.NET)的发布绝对是一种经济而解脱的选择和期许。WSE1.0 会很快占领所有低端和中高的Web Services开发和应用市场，它非常的经济而低廉并且非常”Strong”，甚至无法不吸引任何Web Services的开发人员。难怪Don Box一个月前豪语预言Web Services的第二阶段已经结束，未来任何书面上的协议书写和争论已不再重要，市场上需要重量和杀手级的“Web Services Server”。很好，整个WSE一扫Web Services所有有关Message级的协议和应用的关键点，无论这个领域的竞争对手多么顽强和凌人，毫无疑问的是落后了很大的一步，整个2002年度微软的所有产品，不是技术、市场和.NET策略的问题，而是太快，速度太快；无论今年IT裁员的比例多大，都没有微软的用户掉队的比例大，”他们明显和轻而易举的放慢了前进的步伐”。

WSE最早的版本是GXA->WSDK->WSE，也请原谅我还没有使用最新WSE作为文章的标题，尽管我们已经在使用它了。我愿意在这里讨论一下我们的旅途，我的第一篇《应用WSDK》是关于WSDK的，第二篇《应用WSDK》则讲述了有关从WSDK迁移到WSE的一些命名空间的变化，这和9个月前从Framework Bate2迁移到Framework V1.0一样，但工作量小很多。第三篇《应用WSDK》则开始了Web Services有关WS-Security的实践，之外也强调了有关调试工具的问题，也就在那篇文章，WSE1.0发布了。

这篇文章我们会实践Web Services中WS-Security有关X.509证书签名的问题，在之后还有一篇或两篇文章会实践对称加密(Symmetric Encryption)和非对称加密(Asymmetric Encryption)的问题，当你也实践过这五篇文章之后，你会发现实际上它覆盖了WSE最基本的功能和编程方式，这也覆盖了目前WSE1.0 中QuickStart的所有例子（我更喜欢自己的这些例子和实践）。之后我也修改文章的标题，迁移到新的WSE的“称谓”上，之后的旅程可能是关于一些高级或WSE1.0基本功能之上的应用ContentBaseRouting(第二篇之上的高级应用)，CustomBinarySecurityToKen（第三四篇之上的高级应用）、CustomFilter以及Pipeline定制(WSE内核或原理级的一些应用)。整个的过程其实是你学习和理解WS-Routing(WS-Referral), WS-Security, WS-Attachments(DIME)等Web Services协议的过程，所以会非常的美妙和有趣。

当然WSE也是有缺点的，你接触的越久会发现它显著的”A Filter-centric Model”，目前可能你如果用WSE写了你的Services，那么可能意味着你也需要用WSE或兼容的工具来生成你的客户端，浅台词是你需要能够对Server和Client端都有足够的控制能力，因为目前IBM或Bea的Web Services工具可能并不完全兼容或认识WSE的描述(当然你说这不好，不符合你以前印象中的Web Services，是的，你这么想是非常中肯和正确的)。又比如，Tim Ewald也说了，”The WSE implementation of WS-Security gives you direct control over when and how a message is authenticated, but you have to write some code to map username to passwords or interpret the meaning of particular digital certificates.” 我或是你的老板都会教导我们：从“Long Time”和“Short Time”来计划或做一件事情或一笔生意，WSE我想也一样，需要你从更多的角度和眼光来看待它，短期它是非常非常好的技术和基础，它可以真正让Web Services为你做一些雄心勃勃而现实的事情；但从长远来看，它不是最终的，它不是微软GXA策略的最终体现，它会改变、发展和成长(甚至为IBM、这些Web Services对岸的合作者妥协或混合)，但目前它迈出的这一步是非常必要、优雅和意味深长。

”From my perspective, the flexibility of WSE is a huge asset. It provides plumbing to handle the grungy details of building messages with advanced protocol headers without forcing you to adopt a particular programming model. The means you can use WSE to solve a very wide range of problems without having to stay inside a particular set of architectural boundaries.” (Tim Ewald / December 2002)

也请允许我改变讲述的方式，对于这次实践我不在像之前那样介绍很详细的步骤和过程，因为所有的方式是类似的，不同的是一些需要注意的细节，那么我会在下面的文章中一一的说明。因为这整个的过程是一个理解和实践的过程，行动是最大障碍。

1. 有关相关的文章。

这是我愿意实践的最大原因，因为我发现相关的文档相当的少，所有的文章历历可数，而中文的文档我希望你们愿意从这里看到最新的J

你一定需要看的：

Programming with Web Services Enhancements 1.0

WS-Security Authentication and Digital Signatures with Web Services Enhancements

Inside the Web Services Enhancements Pipeline

可以参考和找到的

Compare Web Service Security Metrics

Use X.509 Certificates with the WSDK Technical Preview

Dig Into WS-Security with the WSDK Technical Preview

Test-Drive Microsoft's New Web Services Development Kit

Web Services Development Kit Technology Preview (MS)

/WSDK Web Service Development Kit dev article

无论如何这些文档是有帮助也可能是没有帮助的，但它们可能是有关于这个话题尽可能多的资源了。有关WSE只有我上面列的一定要看的三篇。我的应用WSDK篇从第二篇开始和WSE都是兼容的。

在WSE环境中调试和实践WSDK是痛苦和苦闷的，我想这里最大的挑战是你需要熟悉WSE的编程模型，因为WSDK->WSE本质上没有变什么。

2. 有关安装。

这里主要是关于针对那些安装WSDK的。据我的经验许多安装过WSDK的机器，再安装WSE时会有些小小的问题，有时WSE不能完全删除原来GAC中WSDK的问题，而在安装WSE时产生错误。

如果你已经安装了WSDK或WSE1.0之前的版本，那么安装之前，你最好执行下面的命令：

Gacutil /u Microsoft.Web.Services ( 或 Microsoft.WSDK )

nGen / delete Microsoft.Web.service ( 或 Microsoft.WSDK )

另外有关X.509 证书的问题。

请你无论如何请参考WSE文档中的Readme.htm 和Managing Applications Created with the Web Services Enhancements->Managing X.509 Certificates 一节的描述，先设置你的Certificates环境。

如果你没有Certificates Server 或是你无法获得一个CA Certificate那么你可以使用.NET Framework 中的makecert.exe 也可以生成一个可以使用的证书。这篇文章使用的也是用makecert.exe 生成的证书。

如果你决定使用makecert.exe 那么确保你的.NET Framework 必须是最新版本的也就是至少要1.1的，不然老工具生成出来的证书是无法工作的。

我测试通过的环境是Windowns .NET Server 2003 RC1 3663, VS.NET 7.1.2215(Everett Bate 1) . Microsoft.NET Framework 1.1.4322

如果你也同样使用Windows.NET Server 2003 那么你需要保证ASP.NET 也运行在Framework 1.1上。并且清楚apnet_wp 现在运行在NETWORK SERVICES用户下而不是以前的System下。

3. 有关新的工具和环境。

这里需要讲一下你可能会Download的Web Services Enhancements 1.0 Settings 这是WSE Team内部使用的一个工具，作为VS.NET 的一个Plug-in 工具在使用，没有任何的技术支持，也许未来会并在Everett中，它主要帮助你完成比较繁琐的配置文件(web.config)的手工设置问题，因为在使用WSDK时那么神秘的PublicKeyToken数值让我迷惑和不知道从那里获得，现在非常好了，如果你使用VS.NET 它很好的集成在里面，几乎都是自动的。当然我不知道中文版本的VS.NET是否一样可以。但我想一样可以使用。

重要的是这个工具几乎对你的编程不会有任何的帮助，它减少的是你手工粘贴/复制的机械劳动。不安装这个软件用VS.NET仍然可以开发WSE的应用。但我很难想象不使用VS.NET来使用WSE的，当然也可以，但真的很少有人这么做。当然这里还有一个未证实的说法，我曾在第二篇中提过，安装WSE1.0之后，VS.NET在加入有Microsoft.Web.Services.DLL的Web Services引用时会自动生成两个代理类一个从原来的System.Web.Services.Protocols.SoapHttpClientProtocol继承，另外一个从Microsoft.Web.Services.WebServicesClientProtocol 继承并且会将代理类名后自动加”Wse”区别原来的代理类。这将非常方便，上几篇我都是手工用WSDL.exe来产生代理类，然后手工替换。现在的传说是，有一种说是安装WSE1.0后就有这个功能；另外一种说是安装了WSE Setting之后才有这个功能，至于是那种我就不清楚了J

我的建议是:在你项目的开始你先用这个工具设置好相关的参数，因为之后如果你的Solution Explorer中有多个Project，特别是有WinForm的Project时，WSE Setting的菜单可能会突然不出现了。这样你几乎又要重新开始手工设置了。当然可能是我自己的原因，因为我当时安装WSE Setting时没有关闭VS.NETJ