概述
Windows Communication Foundation (WCF) 是 Microsoft 为构建面向服务的应用程序而提供的统一编程模型（摘自MSDN），在分布式环境下的安全问题尤为重要，如果你觉得使用了WCF默认的安全措施可以让你高枕 无忧，那明天你可就以回家种田了，当然，对于学习来说，足够了~，但我们讲的是真正的项目应用，WCF在各种协议下的安全提供和保证是不尽相同的。
X509证书介绍
X.509 是由国际电信联盟（ITU-T）制定的数字证书标准，相信这是人尽皆知的了，目前X.509证书据我所知有三个版本，.net中使用的是x.509-2，X.509-2 版引入了主体和签发人唯一标识符的概念，以解决主体和/或签发人名称在一段时间后可能重复使用的问题，x509-2(以下简称x509)证书由两把钥匙组成，通常称之为密钥对，公钥加密，私钥解密。今天我想在这里对x509进行一个深入的介绍和了解，因为在WCF的安全体系中，x509证书应用是非常频繁的，或者说是不可缺少的。
1、如何生成证书？
使用微软提供的Makecert.exe测试证书生成工具可以很好的帮助我们得到一个x509标准证书，具体方法如下：下载Makecert.exe或者定位到你的计算机目录：C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin下，找找就看见了，我强烈建议你copy Makecert.exe到一个单独的目录中，如copy到D:\\cers。
现在点击开始菜单-运行-输入cmd，运行控制台应用程序，定位到D:\\cers，在控制台输入：makecert -r -pe -$ individual -n “CN=mailSecurity” -sky exchange -sr currentuser -ss my mailSecurity.cer，即可在当前用户证书存储区下的个人区中生成一个名为mailSecurityr的x509证书，并在当前目录输出了证书文件mailSecurity.cer，以下简单介绍一下各种参数意义，更复杂的参数请参考：证书创建工具帮助
---------------------------------------------------------------------------------------------
makecert 证书工具名
-r 表示即将生成的证书是自我签署的，自己给自己发奖(这里主要是指颁发机构）
-pe 表示将所生成的私钥标记为可导出。这样可将私钥包括在证书中
-$ 证书是个人用还是商用(individual/commercial）老美就是搞啊，这玩意用美元符号还真是形象得很。
-n 表示证书主题，你就当它是标题吧，不管你取什么名字，必须包含CN＝前缀
-sky 指定主题的密钥类型，必须是 signature、exchange 或一个表示提供程序类型的整数。默认情况下，可传入 1 表示交换密钥，传入 2 表示签名密钥
-sr 指定主题的证书存储位置。Location 可以是 currentuser（默认值）或 localmachine（实际是必须是这两个中的一个值)
-ss 指定主题的证书存储名称，输出证书即存储在那里
mailSecurity.cer 证书名称，不必与主题一致，不过建议你还是致的好。
----------------------------------------------------------------------------------------------
通过在开始菜单-运行-输入mmc可以选择证书单元来查看和管理证书，通过微软的提供的certmgr.exe证书管理工具也可管理证书，和makecert.exe在同一目录，使用相当简单，双击就可了，当然你还可以通过命令行模式来运行它，在微软的很多批处理文件中就很好的体现了这一点，具体使用参见：证书管理器工具
2、证书中都包含些什么秘密？
首先我们必须知道的是：微软提供的证书生成工具给我们准备了两种密钥算法(MD5/SHA1）我们可以在生成证书的时候指定，如果没有指定，则默认使用MD5算法。但是我当我用SHA1算法生成证书的时候，奇怪的事情发生了.
公钥加密强度为：1024
算法签名：sha1RSA
3、看到这里，我想我们都很想知道，为什么会这样？ 不是采用的SHA1算法吗？为什么算法签名为：sha1RSA？
看来，在这里不得不提到RSA算法提供程序，看看微软的官方说明：如果安装了 Microsoft Enhanced Cryptographic Provider，则 RSACryptoServiceProvider 支持长度从 384 位至 16384 位（增量为 8 位）的密钥。如果安装了 Microsoft Base Cryptographic Provider，则支持长度从 384 位至 512 位（增量为 8 位）的密钥。
本机肯定是安装了Microsoft Enhanced Cryptographic Provider的，因为我今天刚测试过了，用最长密钥长度生成密钥，时间可能你都不敢想，看图说话算了。
几近7分钟，长度16384位。
RSA加密过程：
4、从这里可以看出，我们证书所能生成的密钥长度还可以很长，当你使用SHA1算法生成证书时，makecert默认加密强度为1024位，加密后的内容长度为128位，很标准的，当然，你还可以用上面的代码测试其它长度，但请注意，每个长度增量为8位，如1024位，下一个长度为：1024+8＝1032,指定密钥长度必须符合增量规范。
5、证书存储位置选择
有朋友也许认为，证书存储位置一般不都是照搬微软的那一套嘛，其实不然，有以下几种情况是我们在真正的项目应用中不容忽视的。
1）开发模式：开发模式时，为方便我们一般都采用控制台作为WCF服务的宿主，意味着当前运行的帐户权限为当前账户，估计多半是管理员权限了，这个时候你是不用担心你的证书存储在哪里的，只要你的证书生成了就好，实际真的就是这么回事，当你将你的WCF安全配置更改一下，看代码了：
如果你的证书现在不受信任，如果你还过得了服务，你就牛X了。 证书authentication （服务器与客户端）共有四种：
None= 未执行任何证书验证
PeerTrust=如果证书位于被信任的人的存储区中，则有效
ChainTrust=如果该链在受信任的根存储区生成证书颁发机构，则证书有效
PeerOrChainTrust=如果证书位于被信任的人的存储区或该链在受信任的根存储区生成证书颁发机构，则证书有效
Custom=用户必须插入自定义 X509CertificateValidator 以验证证书(这种模式很有意思，后面会提到)
实际上，只要你把信任模式更改为：None，证书放在哪里都无所谓了。
2）部署模式
我强烈推荐以windows service作为WCF宿主，不论从效率或者安全及稳定性上来说，windows service都是最棒的，特别是你的WCF服务还是以TCP命名管道作为主要通信手段的时候，windows servcie就更值得你考虑了，先不要说IIS6.0不支持TCP协议先。
在以windows servcie方式运行WCF host的时候，你首先会碰上第一个问题，找不到证书，一般都会提示你，不能以下列搜索标准找到证书，该进程必须具有对私钥的访问权限，哥们，听我一句话，在这个时候，你就千万不要相信人云亦云的通过微软的FindPrivateKey工具找到证书文件，给LOCAL SERVICE访问权限，你不信去试试，问题依旧。
实际上产生这个问题的原因很搞笑，只是因为你在开发时总是使用同一个证书，想当然的部署的时候只是用一个证书，如果你一开始就用两个证书，客户端和服务器之间利用证书时行相互认证和加密，那你应该是没有问题的，以下第一条是很严肃的原则。
（1）以windows servcie作为WCF Host宿主，如果采用了消息加密策略，并启用了X509证书安全，那X509证书的安装位置必须为LocalMachine，同时，证书应位于TrustedPeople位置中。
（2）这只是最基本的要求，不要把它当作教条，实际上，证书必须存储在LocalMacnine是没错的，但是位置就应该按你的 <authentication certificateValidati/>策略来调整了，如果你把证书放在了：ROOT（受信任的根证书颁发机构），你再把证书放到哪里去都是没有问题，甚至可以放到My(个人）区中。
（3）同时，你还应当把客户端证书复制到受信任的证书人区域中，最基本的嘛，当然，这还是和安全策略有关。
（4）客户端和服务器使用证书进行相互认证，并在真正意义上使用了不对称加密，关于客户端和服务相互认证，下次再说吧，我觉得有点长了。
3）当你启用安全策略时的思考
千万记住，安全策略决定着你的服务安全级别，当然也不是越高越好，你刚才也看到了，光是生成个密钥就用了7分钟，很难消受得起的嘛~~，是不？