Could not establish trust relationship for the SSL/TLS secure channel with subject alternative name certificate

Question

I'm getting a System.Net.WebException

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel

The inner exception is 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.

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.

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?

Answer 1

... this should be a valid certificate for WebClient because the domain is listed in the Subject Alternative Name field, is this correct?

Yes, this is correct.

Additionally, there should be no DNS names in the CN. Placing a DNS name in the CN is deprecated by both the IETF/RFC 6125 and the CA/Browser Forums.

You should put a friendly name in the CN because it is presented to the user. You should put the DNS names in the 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

The best I can tell, connecting to www.foo.com with CN=www.bar.com and SAN=www.foo.com is 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.

So, a few guesses since we don't have the real server URL or the server's real certificate:

1. WebClient.DownloadString has a bug
2. The attribute has an unexpected coding (for example, IA5STRING rather than UTF8 string)
3. 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 a UTF8 string)

For the guesses above, Chrome and Internet Explorer could be more tolerant than WebClient.DownloadString.

If (3) is the issue, then WebClient.DownloadString is 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.

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.