一桩由X509Certificate2引发的血案

A process serving application pool 'XXXX' suffered a fatal communication error with the Windows Process Activation Service. The process id was '10740'. The data field contains the error number.

在某次网站更新后，发现wcf服务不可用了，连续调用5次后就出现503错误了，检查服务器上的日志和事件，发现上面的警告，网上查了下，有各种解决方法，可是都不管用，于是逐行代码输出日志看看问题出在哪里，结果发现是X509Certificate2这个类引发的异常。

1	X509Certificate2(String, SecureString)	新实例初始化 X509Certificate2 类使用的证书文件名称和密码。
2	X509Certificate2(String, SecureString, X509KeyStorageFlags)	新实例初始化 X509Certificate2 类使用的证书文件名称、 密码和密钥存储标记。

在msdn上可以看到这个类有这么两个构造函数，区别就在

X509KeyStorageFlags

 这是它的枚举值：

成员名称	说明
	DefaultKeySet	使用默认的密钥集。用户密钥集通常为默认值。
	Exportable	导入的密钥被标记为可导出。
	MachineKeySet	私钥存储在本地计算机存储区而不是当前用户存储区。
	PersistKeySet	导入证书时会保存与 PFX 文件关联的密钥。
	UserKeySet	私钥存储在当前用户存储区而不是本地计算机存储区。既使证书指定密钥应存储在本地计算机存储区，私钥也会存储到当前用户存储区。
	UserProtected	通过对话框或其他方法，通知用户密钥被访问。使用的加密服务提供程序 (CSP) 定义确切的行为。

可以看到默认的枚举是使用DefaultKeySet，当使用第一个构造函数的时候就是使用的用户存储区的证书，当服务部署在IIS上的时候，如果没有导入证书，调用服务的时候会没有响应，注意是没有响应，而且程序不报任何错误，在系统事件里可以看到上面的警告信息，连续调用5次失败后，程序的应用程序池被自动关闭，这个是在应用程序池中的默认设置。将代码修改使用第二种构造函数后问题解决。

这个类的构造函数奇怪之处在于第一个参数都已经提供了证书的地址，第二个参数是证书密码，如果调用第一个构造函数竟然还要去用户存储区中读取证书。

更奇怪的是部署在Windows服务中使用第一个构造函数是没有问题的，只有发布到IIS需要使用第二个构造函数。

转载于:https://www.cnblogs.com/uptothesky/p/5972124.html