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?
Go to Central Administration =>Security =>Manage Trust. In the ribbon interface, go to Trust Relationships Tab =>Manage group =>Click on New button. In the Root Certificate to trust relationship section, click on Browse. Select the certificate that we have exported.
A common reason you may receive the error Could not establish trust relationship for the SSL/TLS secure channel is because the SSL certificate isn't trusted. If the SSL certificate is not trusted, you will need to install the SSL certificate's root certificate.
SSL/TLS creates a secure channel between a users' computer and other devices as they exchange information over the internet, using three main concepts: encryption, authentication, and integrity to accomplish this. Encryption hides data being transferred from any third parties.
This problem usually happens when the computer is using the Proxy/VPN. Please disable the Proxy/VPN temporary and try again. If you're using the Proxy Settings in Driver Easy, please go to the Settings panel and set it to Use default browser settings.
... 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:
WebClient.DownloadString
has a bugIA5STRING
rather than UTF8
string)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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With