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

Question

我遇到了一个System.Net.WebException异常

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

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

远程证书未按照验证过程的要求有效

当使用System.Net.WebClient.DownloadString(String address)访问www.foo.com网站，但使用针对www.bar.com的证书并在Subject Alternative Name字段中列出了www.foo.com时。

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

我认为对于WebClient来说，这应该是一个有效的证书，因为该域名列在Subject Alternative Name字段中，这个理解是否正确？或者WebClient不会使用发给一个网站但用于另一个网站的SSL证书的Subject Alternative Name字段吗？

- Jonathan

---

如果您能提供服务器的URL，那么我们可以更好地查看发生了什么。 - jww

可能是重复的问题：WCF：Could not establish trust relationship for the SSL/TLS secure channel with authority。 - jww

有趣的是，类似于Sebastian建议的private static bool ValidateRemoteCertificate解决方案实际上导致了问题 - 之前的开发人员已经实现了检查cert.Subject的代码，但其中并不包含SAN。一旦我们删除了那行代码并检查了策略错误，问题就变得清晰明了了。 - Jonathan

Answer 1

...这应该是WebClient的有效证书，因为该域名在“Subject Alternative Name”字段中列出，这是正确的吗？

是的，这是正确的。

此外，在CN中不应该有任何DNS名称。将DNS名称放在CN中已被IETF/RFC 6125和CA/Browser Forums弃用。

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

尽管这种做法已被弃用，但并未被禁止...

---

我尽力理解，连接到具有“CN = www.bar.com”和“SAN = www.foo.com”的SSL证书的“www.foo.com”是可以接受的，符合RFC 6125第6.4.4节以及CA / B的基线要求第9.2.1和9.2.2。对于上述猜测，Chrome和Internet Explorer可能比“WebClient.DownloadString”更宽容。这些猜测包括：1. “WebClient.DownloadString”存在错误；2. 属性具有意外的编码（例如，“IA5STRING”而不是“UTF8”字符串）；3. 签发者的编码与主题的编码不同（例如，签名者的主题DN是“IA5STRING”，而最终实体的签发者DN是“UTF8”字符串）。

如果问题是关于(3)，那么WebClient.DownloadString实际上是正确的。在下面的签署层次结构中，证书发行者DN的属性编码必须与签名者的主题DN相同。你不能混用它们。

上面的图形是从Peter Gutmann的工程安全中无耻地复制而来。它在网上免费提供，将教你许多有趣的与安全相关的知识。他特别喜欢揭示PKI的漏洞，并提供了两章关于它在实践中的真实失误。

- jww

---

谢谢 - 这非常有帮助。我希望我能够投票支持您的答案并接受它。我真的没有想到在Stackoverflow上提出我的第一个问题会得到如此完整的答案。再次感谢。 - Jonathan

答案没问题。像Steffen、Bruno和EJP这样的人保持了高水平。关于阅读答案，请参见如何接受答案？。 - jww