Mailing-List: contact httpclient-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Subject: RE: HTTPS Certification problem
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpClient User Discussion <httpclient-user@jakarta.apache.org>
In-Reply-To: <86866D5BDA41694F82D46C0E00C30DBF02A1B5A5@tis_xchange_srv>
References: <86866D5BDA41694F82D46C0E00C30DBF02A1B5A5@tis_xchange_srv>
Content-Type: text/plain
Date: Thu, 05 Jul 2007 11:47:57 +0200
Message-Id: <1183628877.772.12.camel@okhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2007-07-05 at 15:03 +0530, Dhanushka Amarakoon wrote:
> Yes I agree. If you take a look at the code that I have submitted then
> you'll see that I have tried the approach using
> AuthSSLProtocolSocketFactory.
> 

Dhanushka,

A key store and a trust store (at least conceptually) is not the same
thing. Are you sure you are not confusing the two? 

> But it still points to the default keyStore and not the one that I have
> specified. 

That does not seem to be a problem with HttpClient, does it?

Oleg

> I also tried to initialize the keyStore using an SSLContext. But
> nothing seems to work.
>
> Please help
>
> 
> Reguards
> 
> Dhanushka Amrakoon
> 
> 
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org] 
> Sent: Thursday, July 05, 2007 2:59 PM
> To: HttpClient User Discussion
> Subject: RE: HTTPS Certification problem
> 
> On Thu, 2007-07-05 at 08:28 +0530, Dhanushka Amarakoon wrote:
> > Hi
> > 
> > I believe that I also tried what you suggested earlier. I reinitialized
> the
> > keyStore just before executing the httpGet method. But it still doesn't
> > work.
> 
> You mean the trust store, don't you? As I said just creating a new trust
> store is not enough. You have to create a new SSLContext using that new
> trust store. Essentially that means you have to create a new instance of
> the AuthSSLProtocolSocketFactory.
> 
> Oleg 
> 
> 
> > Can you please provide me with the necessary steps as to how to achive
> what
> > I require.
> > 
> > 
> > Reguards
> > 
> > Dhanushka Amrakoon
> > 
> > 
> > -----Original Message-----
> > From: Oleg Kalnichevski [mailto:olegk@apache.org] 
> > Sent: Wednesday, July 04, 2007 5:16 PM
> > To: HttpClient User Discussion
> > Subject: RE: HTTPS Certification problem
> > 
> > On Mon, 2007-07-02 at 11:52 +0530, Dhanushka Amarakoon wrote:
> > > Hi
> > > 
> > > I did what you suggested but I am unable to still obtain the result that
> I
> > > require.
> > > 
> > > Can anyone please tell me a way to dynamically change the truststore
> used.
> > > It doesn't have to be something related to AuthSSLProtocolSocketFactory.
> > Any
> > > way to do it would be fine. 
> > > 
> > > I need to
> > > 1. Execute a HTTP get command
> > > 2. Check the truststore for any valid certificates.
> > > 3. If the truststore doesn't have the valid certificate obtain it from
> the
> > > end server and store it in the truststore.
> > > 4. reexecute the HTTP get command. Have to make sure that the truststore
> > > used is the newly updated truststore.
> > > 
> > > I am able to do steps 1-3 successfully.
> > > But I am not able to reexecute the HTTP command again successfully as it
> > > still only obtains certificates from the old truststore not the new
> > updated
> > > one.
> > > 
> > 
> > If the trust store changes, you need to make sure the SSLContext
> > instance used to create SSL sockets gets reinitialized (recreated using
> > the new trust store).
> > 
> > Hope this helps
> > 
> > Oleg 
> > 
> > > BTW
> > > Thanks go out to Roland for helping me out.
> > > 
> > > Reguards
> > > 
> > > Dhanushka Amrakoon
> > > 
> > > 
> > > -----Original Message-----
> > > From: Roland Weber [mailto:ossfwot@dubioso.net] 
> > > Sent: Friday, June 29, 2007 10:49 PM
> > > To: HttpClient User Discussion
> > > Subject: Re: HTTPS Certification problem
> > > 
> > > Hello Dhanushka,
> > > 
> > > >     while (retry <= retryCount) {
> > > > 
> > > >       try {
> > > > 
> > > >         Protocol authhttps = new Protocol("https",
> > > >                                           new
> > > AuthSSLProtocolSocketFactory(
> > > >             new URL(
> > > >  
> > > > "file:E:\\Dhanushka\\Connectors\\AptiloConnector_new\\my.keyStore"),
> > > 
> > > That is a really strange format for a URL. I would have used
> > > file:///e:/Dhanushka/Connectors/AptiloConnector_new/my.keyStore
> > > Anyway, if it works.
> > > 
> > > >             "112233",
> > > >             new URL(
> > > >  
> > > > "file:E:\\Dhanushka\\Connectors\\AptiloConnector_new\\my.keyStore"),
> > > >             "112233"), 443);
> > > > //        httpclient.getHostConfiguration().setHost("localhost", 443,
> > > > authhttps);
> > > >         Protocol.registerProtocol("https", authhttps);
> > > 
> > > It is a rather bad idea to register the protocol in a loop.
> > > And it may not work as expected, depending on how the
> > > AuthSSLProtocolSocketFactory relates to SSL contexts.
> > > I can't tell you details, because I don't know them.
> > > But this _feels_ all wrong.
> > > Use one single AuthSSLProtocolSocketFactory. Modify the
> > > code of that factory so you can update the key store at
> > > runtime. Test and debug until you are sure that the new
> > > key store content is picked up at runtime.
> > > Then verify that the initial key store is read from the
> > > file referenced above. Afterwards, verify that updates
> > > to the key store are written to that very file. And make
> > > sure that the writing succeeds and is not prevented by
> > > some spurious file locks because a file is not properly
> > > closed or some such interference.
> > > 
> > > good luck,
> > >   Roland
> > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > > 
> > > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org