Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Security > HttpWebRequest failure with TLS

Reply
Thread Tools

HttpWebRequest failure with TLS

 
 
Sholto Douglas
Guest
Posts: n/a
 
      09-23-2005
I am using HttpWebRequest to access a WebLogic web servce. It is currently
in a console app, but will be 'elevated' to a service.
The code is pretty standard, but I get the dreaded WebException:
The underlying connection was closed: Could not establish secure channel
for SSL/TLS
It uses 2-way SSL/TLS. I am adding the client certificate to the
ClientCertificates property. I have added the server certificate to my
CurrentUser store. The server has my (client) certificate. What more can I
do, for heavens sake?
The WebLogic log shows that we complete the first 3 stages of the handshake,
namely up to here:

*** ServerHelloDone
HttpProcessor[8082][4], WRITE: TLSv1 Handshake, length = 4972
HttpProcessor[8082][4], received EOFException: error
HttpProcessor[8082][4], handling
exception:javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake
HttpProcessor[8082][4], SEND TLSv1 ALERT: fatal, description =
unexpected_message
HttpProcessor[8082][4], WRITE: TLSv1 Alert, length = 2
...
...

At this point the client should send the client certificate to the server,
but it doesn't.
For what it's worth, here is the code:

HttpWebRequest webRequest =
(HttpWebRequest)WebRequest.Create(sUri);
webRequest.Method = "POST";
webRequest.KeepAlive = false;
webRequest.ContentType = "text/xml";
webRequest.ContentLength = in_sXml.Length;
// Add the authentication certificates
if (m_x509ClientCert != null)
webRequest.ClientCertificates.Add(m_x509ClientCert );

StreamWriter SW = new StreamWriter(webRequest.GetRequestStream());
SW.Write(in_sXml);
SW.Close();

// Wait for response...
HttpWebResponse webResponse =
(HttpWebResponse)webRequest.GetResponse();

It throws the exception at the webRequest.GetRequestStream() call.

In the class constructor I have set the ServicePointManager.SecurityProtocol
to
SecurityProtocolType.Tls, and the CertificatePolicy to accept all
certificates.

Can anyone tell me what I have missed?
--
Thanks for any help,
Sholto Douglas
His Nerdship Pty Ltd
 
Reply With Quote
 
 
 
 
Joe Kaplan \(MVP - ADSI\)
Guest
Posts: n/a
 
      09-23-2005
This generally means that your client code doesn't have access to the
private key for the certificate in question, although it could be an issue
with certificate trust as well.

Debugging these issues is notoriously difficult I'm afraid.

The first thing I would do is make sure the certificate in question has a
private key associated with it. Then, make sure you can navigate to the
page in question with the browser and that IE will prompt you for the client
certificate.

After that, using regmon and filemon while the program is running is often
very helpful for determining where Windows is looking for the private key
file and who is getting denied access.

There are also some kbase articles on this issue.

Joe K.

"Sholto Douglas" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I am using HttpWebRequest to access a WebLogic web servce. It is currently
> in a console app, but will be 'elevated' to a service.
> The code is pretty standard, but I get the dreaded WebException:
> The underlying connection was closed: Could not establish secure channel
> for SSL/TLS
> It uses 2-way SSL/TLS. I am adding the client certificate to the
> ClientCertificates property. I have added the server certificate to my
> CurrentUser store. The server has my (client) certificate. What more can
> I
> do, for heavens sake?
> The WebLogic log shows that we complete the first 3 stages of the
> handshake,
> namely up to here:
>
> *** ServerHelloDone
> HttpProcessor[8082][4], WRITE: TLSv1 Handshake, length = 4972
> HttpProcessor[8082][4], received EOFException: error
> HttpProcessor[8082][4], handling
> exception:javax.net.ssl.SSLHandshakeException: Remote host closed
> connection
> during handshake
> HttpProcessor[8082][4], SEND TLSv1 ALERT: fatal, description =
> unexpected_message
> HttpProcessor[8082][4], WRITE: TLSv1 Alert, length = 2
> ...
> ...
>
> At this point the client should send the client certificate to the server,
> but it doesn't.
> For what it's worth, here is the code:
>
> HttpWebRequest webRequest =
> (HttpWebRequest)WebRequest.Create(sUri);
> webRequest.Method = "POST";
> webRequest.KeepAlive = false;
> webRequest.ContentType = "text/xml";
> webRequest.ContentLength = in_sXml.Length;
> // Add the authentication certificates
> if (m_x509ClientCert != null)
> webRequest.ClientCertificates.Add(m_x509ClientCert );
>
> StreamWriter SW = new StreamWriter(webRequest.GetRequestStream());
> SW.Write(in_sXml);
> SW.Close();
>
> // Wait for response...
> HttpWebResponse webResponse =
> (HttpWebResponse)webRequest.GetResponse();
>
> It throws the exception at the webRequest.GetRequestStream() call.
>
> In the class constructor I have set the
> ServicePointManager.SecurityProtocol
> to
> SecurityProtocolType.Tls, and the CertificatePolicy to accept all
> certificates.
>
> Can anyone tell me what I have missed?
> --
> Thanks for any help,
> Sholto Douglas
> His Nerdship Pty Ltd



 
Reply With Quote
 
 
 
 
Sholto Douglas
Guest
Posts: n/a
 
      09-23-2005
Thanks for answering, Joe,

> Debugging these issues is notoriously difficult I'm afraid.
>

Tell me about it..... What is annoying is that whatever the problem, I
always get the same exception message. The .NET error messages should be
more explicit.

> This generally means that your client code doesn't have access to the
> private key for the certificate in question, although it could be an issue
> with certificate trust as well.
>

I put both keys (client and server) into the Personal 'folder' of the
CurrentUser store. Do they need to be in the LocalMachine store? If so,
which folder? Personal, Trusted People? I imagine the CurrentUser store
would be less prone to permission problems, which is why I put them there.
How can I be sure I do have the required access?

> The first thing I would do is make sure the certificate in question has a
> private key associated with it. Then, make sure you can navigate to the
> page in question with the browser and that IE will prompt you for the client
> certificate.
>

I am confident there is a private key, because I was asked if I wanted to
export it (I didn't, of course!). I am actually going through a colleague's
laptop with Tomcat installed, then to a proxy, before the actual web service.
So I have never been able to bring up the page in IE (they aren't making it
easy for me).

Thanks again, Joe,
Sholto Douglas
His Nerdship Pty Ltd (Australia)


"Joe Kaplan (MVP - ADSI)" wrote:

> This generally means that your client code doesn't have access to the
> private key for the certificate in question, although it could be an issue
> with certificate trust as well.
>
> Debugging these issues is notoriously difficult I'm afraid.
>
> The first thing I would do is make sure the certificate in question has a
> private key associated with it. Then, make sure you can navigate to the
> page in question with the browser and that IE will prompt you for the client
> certificate.
>
> After that, using regmon and filemon while the program is running is often
> very helpful for determining where Windows is looking for the private key
> file and who is getting denied access.
>
> There are also some kbase articles on this issue.
>
> Joe K.


 
Reply With Quote
 
Joe Kaplan \(MVP - ADSI\)
Guest
Posts: n/a
 
      09-24-2005
My guess is that you are going to want it in the machine store as the
account your web service client is running under will eventually change to
the service process' account, but it should work in either for the console
app as your user profile will be loaded.

The MMC snap-in will tell you for sure if the client certificate has a
private key associated with it in the cert properties dialog. The client
certificate should go in the personal store.

You probably don't need the server's certificate on your machine at all as
long as your machine trusts it.

If you can't bring up the page in IE, that might mean that the underlying
Wininet goo can't get to it either. Be careful with that as this might not
be a client certificate issue at all.

Another useful thing is to play with the schannel logging level to see
detailed log messages on the certificate exchange stuff in the event log:
http://support.microsoft.com/?id=260729

Joe K.

"Sholto Douglas" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thanks for answering, Joe,
>
>> Debugging these issues is notoriously difficult I'm afraid.
>>

> Tell me about it..... What is annoying is that whatever the problem, I
> always get the same exception message. The .NET error messages should be
> more explicit.
>
>> This generally means that your client code doesn't have access to the
>> private key for the certificate in question, although it could be an
>> issue
>> with certificate trust as well.
>>

> I put both keys (client and server) into the Personal 'folder' of the
> CurrentUser store. Do they need to be in the LocalMachine store? If so,
> which folder? Personal, Trusted People? I imagine the CurrentUser store
> would be less prone to permission problems, which is why I put them there.
> How can I be sure I do have the required access?
>
>> The first thing I would do is make sure the certificate in question has a
>> private key associated with it. Then, make sure you can navigate to the
>> page in question with the browser and that IE will prompt you for the
>> client
>> certificate.
>>

> I am confident there is a private key, because I was asked if I wanted to
> export it (I didn't, of course!). I am actually going through a
> colleague's
> laptop with Tomcat installed, then to a proxy, before the actual web
> service.
> So I have never been able to bring up the page in IE (they aren't making
> it
> easy for me).
>
> Thanks again, Joe,
> Sholto Douglas
> His Nerdship Pty Ltd (Australia)
>
>
> "Joe Kaplan (MVP - ADSI)" wrote:
>
>> This generally means that your client code doesn't have access to the
>> private key for the certificate in question, although it could be an
>> issue
>> with certificate trust as well.
>>
>> Debugging these issues is notoriously difficult I'm afraid.
>>
>> The first thing I would do is make sure the certificate in question has a
>> private key associated with it. Then, make sure you can navigate to the
>> page in question with the browser and that IE will prompt you for the
>> client
>> certificate.
>>
>> After that, using regmon and filemon while the program is running is
>> often
>> very helpful for determining where Windows is looking for the private key
>> file and who is getting denied access.
>>
>> There are also some kbase articles on this issue.
>>
>> Joe K.

>



 
Reply With Quote
 
Sholto Douglas
Guest
Posts: n/a
 
      09-26-2005
Hi Joe,
Still no progress.... However I do have a couple of pointers.
Firstly when I try to bring up the web service in IE, I just get "The page
cannot be displayed". On the Tomcat server they get exactly the same log
message as when it fails from my app, and it dies at the same point
(ServerHelloDone). Apparently the server is waiting for a certificate, which
it doesn't get (either from my app, or from IE). I get no message prompting
me for a client certificate.
I have added the client key to the Personal folders of both the Local
Machine store, and the Current User one. As I said, there is definitely a
private key because when I try to export the certificate (in MMC), it prompts
me if I want to export the private key.
I have also added the root certificate to the Trusted Root Certification
Authority in both stores. As you said, given that it is a console app, it
should always have access to the Current User store.

I activated the SCHANNEL logging, setting the value to 7 (i.e everything).
However I only got one (Information) line - it just said "Creating an SSL
client credential." There were no error messages, suggesting it bombed out
early.

Finally to see if the problem was TLS related, I removed the code that
forced a TLS handshake (so it would default to SSLv3). Still failed.

I appreciate your help Joe. This whole business is making me look very
incompetent!
--
Cheers,
Sholto


"Joe Kaplan (MVP - ADSI)" wrote:

> My guess is that you are going to want it in the machine store as the
> account your web service client is running under will eventually change to
> the service process' account, but it should work in either for the console
> app as your user profile will be loaded.
>
> The MMC snap-in will tell you for sure if the client certificate has a
> private key associated with it in the cert properties dialog. The client
> certificate should go in the personal store.
>
> You probably don't need the server's certificate on your machine at all as
> long as your machine trusts it.
>
> If you can't bring up the page in IE, that might mean that the underlying
> Wininet goo can't get to it either. Be careful with that as this might not
> be a client certificate issue at all.
>
> Another useful thing is to play with the schannel logging level to see
> detailed log messages on the certificate exchange stuff in the event log:
> http://support.microsoft.com/?id=260729
>
> Joe K.


 
Reply With Quote
 
Joe Kaplan \(MVP - ADSI\)
Guest
Posts: n/a
 
      09-26-2005
Interesting. No Schannel error on the client credential creation? It
sounds like it is actually creating the client certificate part of the
handshake. Is it possible that the server side implementation doesn't
properly trust the client certificate or there is a configuration issue on
their side?

I have no idea how to suggest to troubleshoot that as I only know IIS, but
they probably use OpenSSL and I think it has some good logging facilities.

Best of luck on this one...

Joe K.

"Sholto Douglas" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Joe,
> Still no progress.... However I do have a couple of pointers.
> Firstly when I try to bring up the web service in IE, I just get "The page
> cannot be displayed". On the Tomcat server they get exactly the same log
> message as when it fails from my app, and it dies at the same point
> (ServerHelloDone). Apparently the server is waiting for a certificate,
> which
> it doesn't get (either from my app, or from IE). I get no message
> prompting
> me for a client certificate.
> I have added the client key to the Personal folders of both the Local
> Machine store, and the Current User one. As I said, there is definitely a
> private key because when I try to export the certificate (in MMC), it
> prompts
> me if I want to export the private key.
> I have also added the root certificate to the Trusted Root Certification
> Authority in both stores. As you said, given that it is a console app, it
> should always have access to the Current User store.
>
> I activated the SCHANNEL logging, setting the value to 7 (i.e everything).
> However I only got one (Information) line - it just said "Creating an SSL
> client credential." There were no error messages, suggesting it bombed
> out
> early.
>
> Finally to see if the problem was TLS related, I removed the code that
> forced a TLS handshake (so it would default to SSLv3). Still failed.
>
> I appreciate your help Joe. This whole business is making me look very
> incompetent!
> --
> Cheers,
> Sholto
>
>
> "Joe Kaplan (MVP - ADSI)" wrote:
>
>> My guess is that you are going to want it in the machine store as the
>> account your web service client is running under will eventually change
>> to
>> the service process' account, but it should work in either for the
>> console
>> app as your user profile will be loaded.
>>
>> The MMC snap-in will tell you for sure if the client certificate has a
>> private key associated with it in the cert properties dialog. The client
>> certificate should go in the personal store.
>>
>> You probably don't need the server's certificate on your machine at all
>> as
>> long as your machine trusts it.
>>
>> If you can't bring up the page in IE, that might mean that the underlying
>> Wininet goo can't get to it either. Be careful with that as this might
>> not
>> be a client certificate issue at all.
>>
>> Another useful thing is to play with the schannel logging level to see
>> detailed log messages on the certificate exchange stuff in the event log:
>> http://support.microsoft.com/?id=260729
>>
>> Joe K.

>



 
Reply With Quote
 
Peter Jakab
Guest
Posts: n/a
 
      10-07-2005
Hi Sholto,

I already told you in an email, that we were in the same situation, and the
problem was with the server certificate, that we used on the weblogic, re
creating it with the keytool solved the problem.

One more thing iwould like to add:

In case you want to access the weblogic web service from a web application,
for the process to have access to the client certificate, the client
certificate must be placed into the LOCAL_MACHINE store, and the account,
with whose identity the application pool of the app is running, must have
access to the cert.

If the app pool was running with NEtwork service identity, you should have
to grant access to it using the

C:\Program Files\Windows Resource Kits\Tools>winhttpcertcfg -g -a "NETWORK
SERVICE" -s "pannongsm.hu" -c LOCAL_MACHINE\MY

command (after downloading and installing the winhttpcertconfig tool from MS
from

http://www.microsoft.com/downloads/d...displaylang=en

and importing the client certificate to the LOCAL_MACHINE\Personal
store.

In case we imported the client cert to the current_user store of the service
account, it worked fine until the first reboot of the server, after that the
worker process couldn't access the cert stored in the users store.
This is NOT mentioned in the MS Article...

http://msdn.microsoft.com/library/de...SecNetHT13.asp

On the other hand, this article is great, I think.

Best regards

Peter Jakab



"Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
in message news:(E-Mail Removed)...
> Interesting. No Schannel error on the client credential creation? It
> sounds like it is actually creating the client certificate part of the
> handshake. Is it possible that the server side implementation doesn't
> properly trust the client certificate or there is a configuration issue on
> their side?
>
> I have no idea how to suggest to troubleshoot that as I only know IIS, but
> they probably use OpenSSL and I think it has some good logging facilities.
>
> Best of luck on this one...
>
> Joe K.
>
> "Sholto Douglas" <(E-Mail Removed)> wrote in
> message news:(E-Mail Removed)...
>> Hi Joe,
>> Still no progress.... However I do have a couple of pointers.
>> Firstly when I try to bring up the web service in IE, I just get "The
>> page
>> cannot be displayed". On the Tomcat server they get exactly the same log
>> message as when it fails from my app, and it dies at the same point
>> (ServerHelloDone). Apparently the server is waiting for a certificate,
>> which
>> it doesn't get (either from my app, or from IE). I get no message
>> prompting
>> me for a client certificate.
>> I have added the client key to the Personal folders of both the Local
>> Machine store, and the Current User one. As I said, there is definitely
>> a
>> private key because when I try to export the certificate (in MMC), it
>> prompts
>> me if I want to export the private key.
>> I have also added the root certificate to the Trusted Root Certification
>> Authority in both stores. As you said, given that it is a console app,
>> it
>> should always have access to the Current User store.
>>
>> I activated the SCHANNEL logging, setting the value to 7 (i.e
>> everything).
>> However I only got one (Information) line - it just said "Creating an SSL
>> client credential." There were no error messages, suggesting it bombed
>> out
>> early.
>>
>> Finally to see if the problem was TLS related, I removed the code that
>> forced a TLS handshake (so it would default to SSLv3). Still failed.
>>
>> I appreciate your help Joe. This whole business is making me look very
>> incompetent!
>> --
>> Cheers,
>> Sholto
>>
>>
>> "Joe Kaplan (MVP - ADSI)" wrote:
>>
>>> My guess is that you are going to want it in the machine store as the
>>> account your web service client is running under will eventually change
>>> to
>>> the service process' account, but it should work in either for the
>>> console
>>> app as your user profile will be loaded.
>>>
>>> The MMC snap-in will tell you for sure if the client certificate has a
>>> private key associated with it in the cert properties dialog. The
>>> client
>>> certificate should go in the personal store.
>>>
>>> You probably don't need the server's certificate on your machine at all
>>> as
>>> long as your machine trusts it.
>>>
>>> If you can't bring up the page in IE, that might mean that the
>>> underlying
>>> Wininet goo can't get to it either. Be careful with that as this might
>>> not
>>> be a client certificate issue at all.
>>>
>>> Another useful thing is to play with the schannel logging level to see
>>> detailed log messages on the certificate exchange stuff in the event
>>> log:
>>> http://support.microsoft.com/?id=260729
>>>
>>> Joe K.

>>

>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Success Or Failure: There Is No Such Thing As Failure bs866806@163.com C Programming 0 01-06-2008 11:41 AM
Problems with EAP-TLS with smart cards jr Wireless Networking 1 06-23-2006 09:20 PM
[JAVA] [EVALUATION] - The Java Failure (Sorry: The Java(tm) Failure) Ilias Lazaridis Java 0 02-01-2005 10:32 AM
EAP-TLS & Windows XP SP2 ? Al Blake Wireless Networking 3 10-03-2004 11:04 PM
Does EAP-TLS *NEED* Windows 2003 server? Robert Irwin Wireless Networking 3 07-12-2004 09:34 PM



Advertisments