Wimdows.NET

Wim's .NET blog

WebRequest and SSL (The underlying connection was closed. Could not establish trust relationship with remote server.)

internal class AcceptAllCertificatePolicy : ICertificatePolicy
{
  public
AcceptAllCertificatePolicy()
  {
  }

  public bool CheckValidationResult(ServicePoint sPoint,
    
X509Certificate cert, WebRequest wRequest,int certProb)
 
{
   
// Always accept
   
return true;
  
}
}

Yep - that's what you need when you want to make sure that your programmatic SSL WebRequest accepts the SSL challenge. At least when you are encountering the Exception: "The underlying connection was closed. Could not establish trust relationship with remote server."

Before you call call the web request, you then set the static property CertificatePolicy on the ServicePointManager class like so:


ServicePointManager.CertificatePolicy = new AcceptAllCertificatePolicy();

And that should work like a treat!

Posted: Apr 02 2004, 12:51 PM by Wim | with 25 comment(s)
Filed under:

Comments

Ramon Smits said:

Yeah works like a charm allright but not secure as hell :)
# April 2, 2004 7:57 AM

Wim said:

Of course not. Like I said, it does apply to the whole AppDomain as well.

Only recommended to use this in a scenario whereby you know to what you're connecting. I.e. within your own organisation, intranet or the like.

Cheers,
Wim
# April 2, 2004 8:02 AM

Ramon Smits said:

@Wim: Usefull in test environments but not in any production environment.

"know what you're connecting"

Seems to me that you aren't sure any more now because you disabling that with the source example. Isn't that where SSL is used for? To know for sure that you are connecting to something you are supposed to connect??

ok, you have encryption of you data but a man in the middle will be able to spoof the client this way thus the data you are sending is at risk.

My opinion is to just use 'openssl' to generate certifcates for testing secure http. Even in a test environment!
# April 2, 2004 10:32 AM

Wim said:

Ramon,

I think you're missing the point here.

What this actually does, is not disable SSL, it simply makes sure that the client accepts the server's SSL certificate.

This can be necessary because for a number of reasons, the name in the HTTP request does not always exactly match the name for the server certificate, which results in the SSL challenge. To work-around this, you can implement ICertificatePolicy, and have it accept the certificate, even though the name does not exactly match the cert.
# April 2, 2004 10:51 AM

Ramon Smits said:

Indeed you have encryption as I posted :)

But the checks that make sure the host that you are connecting to is the intended one (the server must prove that he is who he suggest he is) is not performed. Like checking the CA signing of the server certificate and to see if the server certificate is still valid by checking the revocationlist.

For example, if the certificate issuer is not trusted, the certicate is expired and the hostname in the certificate does not match the one you are connecting to then you STILL get a connection to the server/host.

So indeed, the communication is encrypted but not safe at all.

I think you are missing to point of why server certificates exist :). The main purpose (for me) is authentication. If authentication fails then swapping of the symmetric key between client and server is not secure at all!

If you would connect to your internetbank and the security popup says that one of the above three things are wrong. Will you still perform that banktransaction or read your account by submitting your username/password?? If your anwser is yes then your account will probably be empty the next day :)
# April 2, 2004 1:21 PM

Wim said:

I understand SSL encryption. But you don't have enough details about this scenario. ;) And to be honest, that is completely besides the point of my original post...

This is a client app that connects to a pre-defined server on our network.

Believe me, in our case for this particular client app which connects to this pre-defined and static server of ours, it's the right solution.
# April 2, 2004 3:56 PM

JS said:

I ran into this EXACT problem recently.

My company signs our own certificates. so when an application that uses HttpWebRequest hits the https site, it would fail 1 of the 3 main certificate validations.

// passed
const long CertCN_NO_MATCH = 0x800B010FL ;
// passed
const long CertEXPIRED = 0x800B0101L ;
// failed due to the fact we sign our own certs
const long CertUNTRUSTEDROOT = 0x800B0109L ;

so, in order to allow HttpWebRequest to authenticate, we bypassed one of the 3 (untrustedroot) error codes.

which in part lets us through. And still makes sure that the certificate has not expired and that the URL matches the certificate.

in addition to the certificate checks, we do IP and userid/pwd (basic).

so, in the end, we bypassed one of the checks because it was impossible for us to get by it any other way.

Hope this helps...

ServicePointManager.CertificatePolicy = new CertPolicy();


class CertPolicy: ICertificatePolicy
{
/*
const long CertVALIDITYPERIODNESTING = 0x800B0102L ;
const long CertROLE = 0x800B0103L ;
const long CertPATHLENCONST = 0x800B0104L ;
const long CertCRITICAL = 0x800B0105L ;
const long CertPURPOSE = 0x800B0106L ;
const long CertISSUERCHAINING = 0x800B0107L ;
const long CertMALFORMED = 0x800B0108L ;
const long CertCHAINING = 0x800B010AL ;
const long CertREVOKED = 0x800B010CL ;
const long CertUNTRUSTEDTESTROOT = 0x800B010DL ;
const long CertREVOCATION_FAILURE = 0x800B010EL ;
const long CertWRONG_USAGE = 0x800B0110L ;
const long CertUNTRUSTEDCA = 0x800B0112L ;
*/

const long CertCN_NO_MATCH = 0x800B010FL ;
const long CertEXPIRED = 0x800B0101L ;
const long CertUNTRUSTEDROOT = 0x800B0109L ;

public bool CheckValidationResult(ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem)
{
// you can do your own certificate checking here
// you can get the error values from WinError.h, all the certificate errors start with Cert_

// we just return true so any certificate will work with this sample


if ((certificateProblem==unchecked( (int)CertEXPIRED)) )
{
MessageBox.Show (" Cert is in invalid time");
return true;
}

else if (certificateProblem== unchecked ((int)CertUNTRUSTEDROOT))
{
MessageBox.Show ("The CA is not trusted");
return true;
}

else if ( certificateProblem== unchecked ((int)CertUNTRUSTEDROOT))
{
MessageBox.Show ("The certificate name is not match");
return true;
}
else if (certificateProblem == 0)
{
return true;
}
else
{
MessageBox.Show("Server Certificate has other problem" );
return false;

}
}
}



# April 28, 2004 6:17 PM

Ramon Smits said:

Why not add the CA root certificate to the trusted CA's on that machine?

Just open up the managementconsole (mmc.exe) and add the Certificate snap-in. Select local machine and then import the certificate in the right folder.

These are realy workarounds that aren't necessary if the system is properly configured.

Never forget that there are two scenario's. Server validation and client validation.

The server validation has an interesting side effect as it uses encryption for the datatransfers.

You use the certificate to validate the identity of the client or the server. To have 100% proof you really need to check the certificate chain. If you don't by disabling it then there is a security hole. It is very possible to setup a man in the middle attack that can catch the username/password. Because you also check ip adres you minimize the possibility to let the hacker do anything usefull with it. One thing should not have happened and that is that the client submitted it's password to an unsafe environment.

Really guys, never ever disable any certificate checking in a production environment!

Ofcourse there are environments where the possibility of an intruder to monitor network traffic is almost not possible because of a very secure intfrastructure. Like server to server communication in a secure network segment. Then this would be an option but you could even better just disable encryption for a performance gain.

Do it good or don't do it at all!
# April 29, 2004 9:35 AM

Lars said:

I don't know who posted this code snippet but I owe you lunch to feed that big brain of yours.
# May 9, 2004 1:25 PM

Long Le said:

Awesome blog...! Works like a charm... :)
# June 8, 2004 12:16 PM

rape stories said:

Your article is prety nice. It's a pity that i didn't see it more later.
# June 19, 2006 9:08 PM

Brutus said:

Accept certificate in a usercontrol in a webform (C#) works fine, but when I implement this code in a usercontrol-webpart : the ssl connection could not be established and I get an error.

Does anyone know what the problem is, here?

ps. The SSL connection is necessary because of the data the webpart recieves from a webservice...
# June 26, 2006 2:48 AM

santy said:

@ramon

hey would u tell how to solve the problem of client and server common name mismatch which results in above listed error without a workaround solution

# November 15, 2006 11:57 AM

Jane said:

<a href='http://desitamilmasala.androot.info/'>desi tamil masala</a>  [URL=http://desitamilmasala.androot.info/ ]desi tamil masala[/URL]  

<a href='http://videoscristianoronaldo.androot.info/'>videoscristiano ronaldo</a>  [URL=http://videoscristianoronaldo.androot.info/ ]videoscristiano ronaldo[/URL]  

<a href='http://visualboyadvanceemulatorgamesharkcodes.androot.info/'>visual boy advance emulator gameshark codes</a>  [URL=http://visualboyadvanceemulatorgamesharkcodes.androot.info/ ]visual boy advance emulator gameshark codes[/URL]  

<a href='http://keralafilmmasala.androot.info/'>kerala film masala</a>  [URL=http://keralafilmmasala.androot.info/ ]kerala film masala[/URL]  

<a href='http://haifawehbeporn.androot.info/'>haifa wehbe porn</a>  [URL=http://haifawehbeporn.androot.info/ ]haifa wehbe porn[/URL]  

<a href='http://homemadeporn.com.androot.info/'>homemadeporn.com</a>  [URL=http://homemadeporn.com.androot.info/ ]homemadeporn.com[/URL]  

<a href='http://www.blackpussy.com.androot.info/'>www.blackpussy.com</a>  [URL=http://www.blackpussy.com.androot.info/ ]www.blackpussy.com[/URL]  

<a href='http://filmatid'epoca.androot.info/'>filmati d'epoca</a>  [URL=http://filmatid'epoca.androot.info/ ]filmati d'epoca[/URL]  

<a href='http://winxclubhairclip.androot.info/'>winx club hair clip</a>  [URL=http://winxclubhairclip.androot.info/ ]winx club hair clip[/URL]  

<a href='http://truthordareblog.androot.info/'>truth or dare blog</a>  [URL=http://truthordareblog.androot.info/ ]truth or dare blog[/URL]  

# March 25, 2007 7:39 PM

Ryan Melville said:

Anyone know what the 'problem' param is if multiple things are wrong with the cert?  It doesn't seem to be an OR'd together field given the possible values.  

For example, if I'm trying to override *only* CertUNTRUSTEDROOT (because in that case I do my own cert id/verification against my embedded CA cert) can I catch *only* CertUNTRUSTEDROOT and return true - or could that unintentionally override some other problem with the cert?

The only way I see this working is if CheckValidationResult() gets called by the framework for *each* problem with the cert - but I don't see this covered in the MSDN documentation at all.

Thanks.

# April 27, 2007 5:10 PM

Ryan Melville said:

Oh, and in case someone here knows:

How would one hand verify the cert against a known CA cert?  Is there a .NET call to do that check?  Is CertVerifySubjectCertificateContext() adaquate and if so anyone have sample code?

BTW, in response to all of the "just add it to the Windows cert store" comments:  Sometimes that is not feasible or desireable.  For example, try explaining to simple users why your app causes all sorts of alarming cert store access warning dialogs from Windows that they've never seen before from other apps.  As long as one does the legitimate cryptographic cert validation in an app override it still very very secure.

# April 27, 2007 5:18 PM

Ryan Melville said:

After posting I realized I could experimentally answer my own question:  Yes, CheckValidationResult() seems to get called once for *each* problem with a cert (and once for the success as well).

Still not sure about the question in my second post, thought...

# April 27, 2007 5:25 PM

Stether said:

cigarettes.blogbugs.org - cigarettes blog

# May 24, 2007 2:55 AM

wledt said:

<a href= volny.cz/.../anne-hathaway-nude.html >anne hathaway nude</a> <a href= volny.cz/.../creampie-pussys.html >creampie pussys</a> <a href= volny.cz/.../jessica-rabbit-porn.html >jessica rabbit porn</a> <a href= volny.cz/.../kim-possible-porn.html >kim possible porn</a> <a href= volny.cz/.../natalie-portman-nude.html >natalie portman nude</a>

# June 17, 2007 3:16 AM

金鹏 said:

ServicePointManager.ServerCertificateValidationCallback属性

ms-help://MS.MSDNQTR.v90.chs/fxref_syste...

# February 27, 2008 12:33 AM

single dating sites said:

It is correct that getting reliable material on this topic can be time consuming.

# March 4, 2008 1:23 AM

https & webrequest | hilpers said:

Pingback from  https &amp; webrequest | hilpers

# January 21, 2009 11:55 AM

www.verybig.ru said:

��� ������ � ���������

# February 14, 2009 4:20 AM

www.verybig.ru said:

��� ������ � ���������

# February 14, 2009 4:24 AM

nick_rozeln said:

# April 9, 2009 5:07 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)