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

Question

我收到了System.Net.WebException

  

基础连接已关闭：无法建立信任   SSL / TLS安全通道的关系

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

  

根据验证程序

，远程证书无效

对www.foo.com使用System.Net.WebClient.DownloadString（字符串地址）时带有www.bar.com证书，但主题备用名称字段中列出了www.foo.com。

证书由GoDaddy颁发，因此Chrome和Internet Explorer在访问www.bar.com时认为证书有效，但在访问www.foo.com时也没有证书问题。

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

Answer 1

  

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

是的，这是正确的。

此外，CN中应该有没有 DNS名称。 IETF/RFC 6125和CA/Browser Forums不推荐在CN中放置DNS名称。

您应该在CN中添加友好名称，因为它会呈现给用户。您应该将DNS名称放在SAN。

中

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

---

  

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

我能说的最好，根据RFC 6125，第6.4.4节，使用www.foo.com和CN=www.bar.com与SAN=www.foo.com连接是正常的。根据CA / B的基准要求第9.2.1和9.2.2节确定其正常。

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

1. WebClient.DownloadString有错误
2. 该属性具有意外编码（例如，IA5STRING而不是UTF8字符串）
3. 发卡行的编码与主题编码不同（例如，签名者的主题DN是IA5STRING，以及最终实体的发行人DN是UTF8字符串）

对于上述猜测，Chrome和Internet Explorer可能比WebClient.DownloadString更宽容。

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



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