Re: HttpWebRequest failure with TLS
From: Peter Jakab (someone_at_from.hu)
Date: Fri, 7 Oct 2005 10:34:01 +0200
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
and importing the client certificate to the LOCAL_MACHINE\Personal
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...
On the other hand, this article is great, I think.
"Joe Kaplan (MVP - ADSI)" <email@example.com> wrote
in message news:eqzkmnqwFHA.2132@TK2MSFTNGP15.phx.gbl...
> 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" <SholtoDouglas@discussions.microsoft.com> wrote in
> message news:2512E596-9C97-4A50-AB6C-ACAA17F47DCC@microsoft.com...
>> 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
>> 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,
>> it doesn't get (either from my app, or from IE). I get no message
>> 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
>> private key because when I try to export the certificate (in MMC), it
>> 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,
>> should always have access to the Current User store.
>> I activated the SCHANNEL logging, setting the value to 7 (i.e
>> However I only got one (Information) line - it just said "Creating an SSL
>> client credential." There were no error messages, suggesting it bombed
>> 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
>> "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
>>> the service process' account, but it should work in either for the
>>> 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
>>> certificate should go in the personal store.
>>> You probably don't need the server's certificate on your machine at all
>>> long as your machine trusts it.
>>> If you can't bring up the page in IE, that might mean that the
>>> Wininet goo can't get to it either. Be careful with that as this might
>>> 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
>>> Joe K.