一直以来无论是Web Form应用、Windows Forms应用还是Mobile&Smart Device应用，强密码保护的认证机制普遍缺失，点对点的非对称消息加密和数据内容签名因为缺少了这个可信赖的凭证也总是成为“沙丘上的城堡”，PKI环境中的证书机制也许是解决上述问题一个不错的选择。

最新一期的MSDN杂志刊发了用证书保护.NET 2.0应用的文章，文章提纲挈领地将如何使用证书，如何用证书完成SSL，如何对Web Service调用进行保护，如何对代码、安全策略（.NET Framework和Active Directory）、自动下发机制、数据进行签名支持等进行了介绍。对于开发人员而言，这些内容应该是非常珍贵的，因为它解决了应用中一个两难的问题：

◆为了安全和实施简便，.NET应用常常会选择集成活动目录域环境认证（或者是互信域认证）模式，这种情况普遍存在于IT环境相对比较好的企业内部，尤其被用于企业内部应用，企业分支机构（Branch Offices）的员工也通过包装的SSPI接口或者集成认证方式访问内部应用。但偶尔还会遇到很多信任域外的用户访问，出于安全考虑不能给他们开放域账号，但又想让他们访问企业信息资源的时候有个凭据；

◆应用本身定位于开放的互联网环境（跨域），采用用户名/密码的Forms认证方式，认证后的结果也“偷偷摸摸”地保存在某个调用上下文中（Session、Cookie）。如果进行一些无关痛痒的操作倒也无妨，但如果用于会有“别有用心”人特别惦记的一些操作时，例如：账户支付、医疗信息交换等，虽然算不上“裸奔”但也和“就穿着内衣过闹市”没什么区别。这些场景下，无论是法律规定，还是用户需求，往往都促使应用的设计者考虑一些跨信任域的强身份措施，以及在此基础上的非对称密码处理。

当“跨域”、“安全”、“简便”合并在一起的时候，好像现有技术手段中能胜任的寥寥无几，仅从.NET Framework层面看证书机制也许是最易于实施的一种，它本身基于PKI的公钥体系下，可以为各主要的安全机制提供强密码保护。而且在SOA大行其道的今天，似乎架构师们更关注与互通（Inter-Communication）和互操作（Interoperation），大家常常谈的“互”其实更多的指消息，但往往忽略了如果调用双方互相都不认识这个“互”似乎也太牵强了，而证书机制恰好也适合这个场景。不仅如此，如果设计人员将安全边界界定到应用服务部分的话，对外交户的内容不会仅限于消息，想想看：

◆您的应用不需要更新吗？如果需要更新的话，下发的、或者客户端应用调用的Assembly、ActiveX是您意愿中的那个版本吗？

◆变基于规则和硬性逻辑的治理为基于策略的治理是一个趋势，但是最终发布的这个策略（适于某个应用，或者某组应用，甚至于适于企业发布的各个应用）能忠实地发布到用户一端，并在目标应用执行中被正确解读吗？

◆WS-*协议组中，WS-SEC、XML-Signature之类的似乎给出了很圆满的应用无关、平台不管、开发技术无所谓的Web Service安全方案，但他充其量只说了结果、宾语，没有提过程的主语——“谁”。

数据、组件、安全策略、Web Service调用还有其他只要是与边界外对象交换的东西，如果需要，能用证书的就都给它用上证书好了，不过之前先要生成并分发好这些证书