无法与主题备用名称证书建立SSL/TLS安全通道的信任关系

Question

我收到了System.Net.WebException

底层连接已关闭:无法为SSL/TLS安全通道建立信任关系

内部异常是System.Security.Authentication.AuthenticationException

根据验证程序,远程证书无效

当使用System.Net.WebClient.DownloadString(字符串地址)对www.foo.com时,使用www.bar.com的证书,但在主题备用名称字段中列出了www.foo.com.

该证书由GoDaddy颁发,因此Chrome和Internet Explorer认为该证书在访问www.bar.com时有效,但在访问www.foo.com时也不会出现证书问题.

我认为这应该是WebClient的有效证书,因为该域列在主题备用名称字段中,这是正确的吗？或者,WebClient是否不将"主题备用名称"字段用于发布到一个站点但在另一个站点上使用的SSL证书？

Answer 1

...这应该是WebClient的有效证书,因为域名在"主题备用名称"字段中列出,这是正确的吗？

是的,这是正确的.

此外,应该没有 DNS名称CN.IETF/RFC 6125和CA/Browser论坛CN都不推荐在DNS中放置DNS名称.

您应该在其中添加一个友好名称,CN因为它会呈现给用户.您应该将DNS名称放入SAN.

虽然这种做法已被弃用,但并未被禁止......

或者,对于发布到一个站点但在另一个站点上使用的SSL证书,WebClient不使用"主题备用名称"字段

最好我可以告诉,连接到www.foo.com同CN=www.bar.com和SAN=www.foo.com是按照RFC 6125 OK,第6.4.4节; 按照CA/B的基线要求第9.2.1和9.2.2节的确定.

所以,一些猜测,因为我们没有真正的服务器URL或服务器的真实证书:

1. WebClient.DownloadString 有一个错误
2. 该属性具有意外编码(例如,IA5STRING而不是UTF8字符串)
3. Issuer的编码与Subject的编码不同(例如,签名者的Subject的DN是IA5STRING,并且最终实体的Issuer DN是一个UTF8字符串)

对于上面的猜测,Chrome和Internet Explorer可能比以上更耐心WebClient.DownloadString.

如果(3)是问题,那么WebClient.DownloadString实际上是正确的.在下面的签名层次结构中,证书的颁发者DN的属性编码必须与签名者的主题DN的编码相同.你不能混合和匹配它们.

上面的图形被Peter Gutmann的工程安全部门无耻地撕掉了.它可以在网上免费获得,它将教你很多有趣的安全相关的东西.他特别喜欢在PKI中挖掘漏洞,并提供两章关于其在实践中的真实失败.