我在向IIS Web服务器分配新的SHA256证书时遇到了一个奇怪的问题。
服务器启用了SSL 3.0，TLS 1.0,1.1和1.2，并且在使用RSA（而非SHA256RSA）签名的站点上使用服务器证书时，客户端会连接并协商TLS_RSA_WITH_AES_256_CBC_SHA以进行TLS加密。
第二个SHA256证书在网站上使用，然后尝试使用TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA。
奇怪的是，在使用www.ssllabs.com服务器测试检查时，我可以看到，当使用或不使用SHA256证书时，服务器会显示完全不同的密码。
密码套件在使用SHA1证书的网站上展示。
TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECHDE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WTH_RC4_128_MD5
使用SHA256证书的网站上提供了密码套件。
TLS_ECHDE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
我找不到任何信息来说明为什么会发生这种情况，但我知道TLS_RSA_WITH_AES密码与TLS 1.2兼容，并且似乎没有文献说明服务器证书是否为SHA256，它强制使用Elliptical Curve Difie Helman Exchange进行密钥加密。
任何人都可以解释为什么会这样吗？
亲切的问候
James Tighe
答案 0 :(得分：0)
我现在设法解决了这个问题，以防其他人得到它。
似乎与用于请求CSR的加密/密钥存储提供程序有关。
如果使用加密API提供程序（例如Microsoft Strong Cryptographic Provider）在Windows Server 2008 R2计算机上生成CSR，并且在生成CSR时未特别提及KeySpec，则会设置 KeySpec = 2 AT_SIGNATURE < / strong>即可。 KeySpec确定密钥是否可用于签名，密钥交换（加密）或两者。
将Cryptography提供程序设置为Crypto API提供程序时，似乎会导致Windows Server 2008 R2计算机完成请求，但默认为 KeySpec = 2 在我们的情况下，这是因为我们生成了一个。由于IIS无法强制使用SHA256作为签名算法，因此与CERTREQ一起使用的INF文件。
如果在.INF文件中将KeySpec设置为 KeySpec = 1 AT_KEYEXCHANGE ，那么这应该有效，尽管我们以不同的方式解决了这个问题。
为了解决此问题，我们更改了.INF文件以设置ProviderName =＆＃34; Microsoft软件密钥存储提供程序＆＃34; （CNG提供商）。证书完成后，显示 KeySpec = 0 AT_NONE ，即密钥存储提供商设置为CNG时。
此问题已提交给Microsoft以帮助我们更好地理解，看起来我们在KeySpec行为和密码提供程序的使用方面是正确的。
他们确认.INF文件（或Cert MMC中的客户模板注册）您需要确保KeySpec属性设置为1 AT_KEYEXCHANGE，否则默认为2 AT_SIGNATURE 。如果您使用CNG提供程序，它将默认使用0 AT_NONE并且将正常工作。
我希望这可以帮助其他可能会遇到这个恼人问题的人，因为很难找到解决方案。
亲切的问候
James Tighe