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

Posted 2023-05-07

【中文标题】无法使用主题备用名称证书为 SSL/TLS 安全通道建立信任关系

【英文标题】：Could not establish trust relationship for the SSL/TLS secure channel with subject alternative name certificate

【发布时间】：2014-09-22 15:30:03

【问题描述】：

我得到一个 System.Net.WebException

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

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

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

当使用 System.Net.WebClient.DownloadString(String address) 对 www.foo.com 使用 www.bar.com 的证书但 www.foo.com 列在“主题备用名称”字段中时。

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

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

【问题讨论】：

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

WCF: Could not establish trust relationship for the SSL/TLS secure channel with authority的可能重复

有趣的是，这与 Sebastian 建议的私有静态 bool ValidateRemoteCertificate 解决方案类似，实际上导致了问题 - 以前的开发人员已经实现了代码来检查不包含 SAN 的 cert.Subject。一旦我们删除了该行并检查了政策错误，就很清楚了。

【参考方案1】：

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

是的，这是正确的。

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

您应该在CN 中输入一个友好的名称，因为它是呈现给用户的。您应该将 DNS 名称放在 SAN 中。

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

---

或者 WebClient 不使用主题备用名称字段来颁发给一个站点但在另一个站点上使用的 SSL 证书

据我所知，根据 RFC 6125 第 6.4.4 节，使用 CN=www.bar.com 和 SAN=www.foo.com 连接到 www.foo.com 是可以的；并且按照 CA/B 的基线要求第 9.2.1 和 9.2.2 节的规定。

因此，由于我们没有真实的服务器 URL 或服务器的真实证书，因此进行了一些猜测：

WebClient.DownloadString 有问题 属性具有意外编码（例如，IA5STRING 而不是UTF8 字符串） Issuer 的编码与 Subject 的编码不同（例如，签名者的 Subject 的 DN 是 IA5STRING，而最终实体的 Issuer DN 是 UTF8 字符串）

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

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

上图是从 Peter Gutmann 的Engineering Security 中无耻地撕下的。它可以在线免费获得，它会教你很多有趣的安全相关的东西。他特别喜欢在 PKI 中挖洞，并提供了两章介绍其在实践中的实际失败。

【讨论】：

谢谢 - 这很有帮助。我希望我能投票赞成你的答案并接受它。我真的没想到我在 *** 上的第一个问题会得到如此完整的答案。再次感谢。

答案没有问题。像 Steffen、Bruno 和 EJP 这样的人保持高标准。如需阅读答案，请参阅How does accepting an answer work?。