.net 无法为具有使用者备用名称证书的 SSL/TLS 安全通道建立信任关系
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/25046156/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Could not establish trust relationship for the SSL/TLS secure channel with subject alternative name certificate
提问by Jonathan
I'm getting a System.Net.WebException
我收到 System.Net.WebException
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel
底层连接已关闭：无法为 SSL/TLS 安全通道建立信任关系
The inner exception is System.Security.Authentication.AuthenticationException
内部异常是 System.Security.Authentication.AuthenticationException
The remote certificate is invalid according to the validation procedure
根据验证程序，远程证书无效
when using System.Net.WebClient.DownloadString(String address) against www.foo.com with a certificate for www.bar.com but with www.foo.com listed in the Subject Alternative Name field.
当使用 System.Net.WebClient.DownloadString(String address) 对 www.foo.com 使用 www.bar.com 的证书但在主题备用名称字段中列出 www.foo.com 时。
The certificate is issued by GoDaddy so Chrome and Internet Explorer consider the certificate valid when going to www.bar.com but also have no problems with the certificate when going to www.foo.com.
该证书由 GoDaddy 颁发，因此 Chrome 和 Internet Explorer 在访问 www.bar.com 时认为该证书有效，但在访问 www.foo.com 时证书也没有问题。
I think this should be a valid certificate for WebClient because the domain is listed in the Subject Alternative Name field, is this correct? Or does WebClient not use Subject Alternative Name field for SSL certificates issued to one site but used on another site?
我认为这应该是 WebClient 的有效证书，因为域列在“主题备用名称”字段中，这是正确的吗？或者，WebClient 是否不将“主题备用名称”字段用于颁发给一个站点但在另一站点上使用的 SSL 证书？
回答by jww
... this should be a valid certificate for WebClient because the domain is listed in the Subject Alternative Name field, is this correct?
...这应该是 WebClient 的有效证书，因为域列在主题备用名称字段中，这是否正确？
Yes, this is correct.
是的，这是正确的。
Additionally, there should be noDNS names in the CN. Placing a DNS name in the CNis deprecated by both the IETF/RFC 6125and the CA/Browser Forums.
此外，还应该是没有在DNS名称CN。IETF/RFC 6125和CA/Browser ForumsCN都不赞成在 中放置 DNS 名称。
You should put a friendly name in the CNbecause it is presented to the user. You should put the DNS names in the SAN.
您应该在 中放置一个友好名称，CN因为它会呈现给用户。您应该将 DNS 名称放在SAN.
While the practice is deprecated, its not forbidden...
虽然这种做法已被弃用，但并没有被禁止......
Or does WebClient not use Subject Alternative Name field for SSL certificates issued to one site but used on another site
或者 WebClient 是否不使用主题备用名称字段来颁发给一个站点但在另一个站点上使用的 SSL 证书
The best I can tell, connecting to www.foo.comwith CN=www.bar.comand SAN=www.foo.comis OK per RFC 6125, section 6.4.4; and its OK per CA/B's Baseline Requirements section 9.2.1 and 9.2.2.
最好我可以告诉，连接到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 节确定。
So, a few guesses since we don't have the real server URL or the server's real certificate:
因此，由于我们没有真实的服务器 URL 或服务器的真实证书，所以有一些猜测：
WebClient.DownloadStringhas a bug- The attribute has an unexpected coding (for example,
IA5STRINGrather thanUTF8string) - The Issuer's encoding differs from the Subject's encoding (for example, the signer's Subject's DN is
IA5STRING, and end entity's Issuer DN is aUTF8string)
WebClient.DownloadString有一个错误- 该属性具有意外编码（例如，
IA5STRING而不是UTF8字符串） - Issuer 的编码与 Subject 的编码不同（例如，签名者的 Subject 的 DN 是
IA5STRING，而最终实体的 Issuer DN 是一个UTF8字符串）
For the guesses above, Chrome and Internet Explorer could be more tolerant than WebClient.DownloadString.
对于上述猜测，Chrome 和 Internet Explorer 可能比WebClient.DownloadString.
If (3) is the issue, then WebClient.DownloadStringis actually correct. In the signing hierarchy below, the attribute encoding of the certificate's Issuer DN must be the same encoding as the signer's Subject DN. You can't mix and match them.
如果（3）是问题，那么WebClient.DownloadString实际上是正确的。在下面的签名层次结构中，证书颁发者 DN 的属性编码必须与签名者的主题 DN 编码相同。你不能混合和匹配它们。
The graphic above was shamelessly ripped from Peter Gutmann's Engineering Security. Its freely available online, and it will teach you a lot of interesting security related things. He especially likes poking holes in PKI and offers two chapters on its real-world failures in practices.
上图是从 Peter Gutmann 的Engineering Security无耻地撕下来的。它可以在线免费获得，它会教你很多有趣的安全相关的东西。他特别喜欢在 PKI 中寻找漏洞，并提供了两章关于它在实践中的实际失败。
