hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Suematsu <richa...@syncadd.com>
Subject Re: Certificateless SSL
Date Fri, 01 Dec 2006 19:58:44 GMT
Hi Jake,

When you hit the 3rd party app, does IE give you a Security Alert box 
that says "The security certificate was issues by a company you have 
chosen not to trust. View the certificate..."

If so, what thats saying is that the certificate on the server was 
signed by a CA that IE doesn't know about.  Click on the View 
Certificate button and look at the Issued by: field.

Your HttpClient connection is dying because the server has an 
unrecognized CA and HttpClient can't just pop up a window asking the 
user to continue like IE.

Check out: http://jakarta.apache.org/commons/httpclient/sslguide.html

About half way down the page there is a EasySSLSockeyProtocolFactory 
that will allow HttpClient to ignore unrecognized CAs.

Jake C wrote:
> Thanks for the quick reply!
>
> Maybe I'm misunderstanding the exception I'm getting. IE is normally 
> used to access the 3rd party application, and it does NOT require us 
> to install or even select a certificate. It DOES prompt us to accept 
> THEIR certificate. We certainly don't have to generate a certificate 
> and install it in a keystore for every client.
>
> The exception I'm getting in HttpClient is:
>
> [INFO] HttpMethodDirector - I/O exception 
> (javax.net.ssl.SSLHandshakeException) caught when processing request: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to 
> find valid certification path to requested target
>
>> From what I saw in the mailing list archives, and from a Google 
>> search, that 
> meant that I didn't have a certificate installed in JSSE.
>
> Here is what I get when running the ping utility:
>
> Writing:
> ================================================================================ 
>
> HEAD / HTTP/1.1
> Host: <IIS Server>
>
> Reading:
> ================================================================================ 
>
> HTTP/1.1 200 OK
> Content-Length: 1433
> Content-Type: text/html
> Content-Location: https://<IIS Server>/iisstart.htm
> Last-Modified: Sat, 22 Feb 2003 02:48:30 GMT
> Accept-Ranges: bytes
> ETag: "<ETag>"
> Server: Microsoft-IIS/6.0
> X-Powered-By: ASP.NET
> Date: Fri, 01 Dec 2006 17:02:43 GMT
>
> Server Certificate for: [<IIS Server>:443]
> ================================================================================ 
>
> <IIS Server>
> Valid: 2006/Nov/30 - 2007/Nov/30
> s: CN=<IIS Server>, OU=<My Department>, O="<My Company>, Inc.", L=<My

> State>, ST=<My City>, C=US
> i: CN=<IIS Server>, DC=<My Company>, DC=com
> -----BEGIN CERTIFICATE-----
> <Lots of certificate info>
> -----END CERTIFICATE-----
>
> Thanks again for your quick reply, and your help!
>
>> From: "Julius Davies" <juliusdavies@gmail.com>
>> Reply-To: "HttpClient User Discussion" 
>> <httpclient-user@jakarta.apache.org>
>> To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
>> Subject: Re: Certificateless SSL
>> Date: Thu, 30 Nov 2006 23:21:23 -0500
>>
>> Hi, Jake,
>>
>> I'll take a stab at this one!
>>
>> Certificates don't really have much to do with encryption.
>> Certificates address the issue of trust.  Think about it this way:
>>
>> How do I know I'm actually talking to "https://web.da-us.citibank.com/"?
>>
>> That's why they're called "certificates".  They really are like a
>> virtual piece of paper, nicely framed, with a nice stamp and some
>> ribbons, hanging on your Doctor's office wall.  "I guess he really
>> must be a doctor, because few people have access to those fancy
>> ribbons!"
>>
>> The "trust" works for a few reasons:
>>
>> - Only Citibank will be able to obtain a certificate for
>> "citibank.com" from a root certificate authority (like thawte,
>> verisign, many others pre-loaded into your browser).
>>
>> - (Or, alternatively, if Citibank can't get a certificate for
>> "citibank.com", they'll choose a different domain name, and print that
>> on all their marketing materials).
>>
>> - Once Citibank has obtained that first certificate no-one else will
>> be able to acquire a new one for the domain, even after the first one
>> expires.
>>
>> The fact that the ROOT CA's already trusted by your browser came
>> pre-loaded is important.  This means those CA's were installed
>> "out-of-band" - through a different medium compared to that through
>> which you are conducting your online business.  In the case of IE6
>> those root CA's presumably came on the CD-ROM that came with Windows
>> XP, and NOT over the internet.
>>
>> (You can then use those out-of-band root ca's to bootstrap your
>> acquisition of additional ca's.  You now have at least a few (quite a
>> few) https:// sites you already trust, and those can provide you with
>> additional root ca's.  This makes me think that all Firefox downloads
>> should be over https, since that is one way we acquire new ROOT ca's -
>> by downloading a new browser!....  anyway, confusing digression, you
>> can give this paragraph a few months to sink in.)
>>
>> There's quite a lot of detail behind all of this.  For example, how
>> does the "citibank.com" certificate get associated with those ROOT
>> CA's already loaded in the browser?  If someone managed to temporarily
>> steal the "citibank.com" domain, why can't they also just steal the
>> certificate off of Citibank's website?  How does the domain name fit
>> into all this?  For now let's just assume all this stuff is okay.
>>
>> Client certificates provide exactly the same service.  But now it's a
>> question of "how does the server really know that Julius Davies is
>> driving that browser?"  Usually a username/password is considered
>> adequete, so client certificates are quite rare.  But they do create a
>> 2nd factor of authentication.  Client certificates could be used to
>> dramatically reduce phishing attacks.  But it's impractical.  The
>> thing that's so great about client certs is that they make it harder
>> for the public at large to access a given site.  The "public" must get
>> a username/password, and then they must also acquire a unique client
>> cert, install it, and regularly update it because of its expiry cycle!
>> As much as CitiBank wants to avoid phishing, they also want their
>> customers to be able to access the website without clogging the phone
>> lines.
>>
>> Just like anything, client certs (and server certs) never provide a
>> 100% bulletproof solution.  The private key behind the public
>> certificate can be stolen, just like the keys to your house can be
>> stolen.  A safe that's impossible to open is not useful.  A safe that
>> can be opened can also be opened by the wrong person.
>>
>> But client certs do add one more layer of hassle to the bad guy's
>> life.  "Great, not only do I need to get his username and password, I
>> need to get the private key that goes with his client certificate."
>>
>>
>> Onto your question:  if IIS is configured to require client certs from
>> HTTPClient, then I suspect it's also requiring client certs from your
>> browser.  Your browser might just not be telling you that it's sending
>> the client cert.  Are you using Firefox?  By default Firefox won't
>> bother prompting you to select the client certificate to use.  Firefox
>> will just automatically provide it to the server.  But you can get
>> Firefox to always prompt by changing the settings.
>>
>> (Interesting side note:  if Firefox is just automatically providing
>> it, that means that the client cert is ultimately protected only by
>> your screensaver password.  People probably can't "export" the client
>> cert to a file without a special admin password, but they can still
>> just sit down at your computer and start using the browser. But I
>> think that's the right way to go.  In the long run (5 years from now?)
>> that initial-logon/screensaver password is going to be the only
>> password you ever use.)
>>
>> Perhaps you can try downloading "not-yet-commons-ssl.jar" from
>> http://juliusdavies.ca/commons-ssl/.  There is a useful "ping" utility
>> there to try and help debug HTTPS issues.  Can you try running this
>> test?
>>
>> java -jar not-yet-commons-ssl.jar -t [IIS IP]:port
>>
>> If you recieve this response, then, yeah, your server wants a client
>> certificate:
>>
>> javax.net.ssl.SSLHandshakeException: Received fatal alert: 
>> bad_certificate
>>
>>
>> I have to signoff now.  But I'll be able to respond with part 2
>> tomorrow.  Sorry I haven't answered all your questions yet.
>>
>> yours,
>>
>> Julius
>>
>>
>>
>>
>> On 11/30/06, Jake C <buddhabuddy@hotmail.com> wrote:
>>> I am a complete SSL noob, so please pardon me if my questions are 
>>> silly...
>>> :-) I've seen similar questions in the archive, but nothing that really
>>> spelled it out.
>>>
>>> We need an encrypted connection to a 3-rd party application, but we 
>>> don't
>>> need validation. The data being transmitted is validation enough for 
>>> us.
>>> However, the application we are sending to (running on Windows under 
>>> IIS) is
>>> requiring a certificate.
>>>
>>> I know it is possible to use SSL without requiring a certificate, as 
>>> the
>>> test application at the bottom of the HttpClient SSL Guide works for
>>> Verisign, but not for our application.
>>>
>>> I see two possible ways of getting around this, and I'd just like some
>>> validation that these would work the way I want (not requiring our 
>>> users to
>>> mess with certificates).
>>>
>>> 1) Use an Authenticating Proxy Server. We should be able to set up 
>>> one of
>>> these that accepts SSL connections without requiring a certificate, and
>>> configure the connection between it and our 3-rd party application 
>>> using a
>>> certificate just for the proxy server, and not for each individual 
>>> client.
>>>
>>> 2) Modify the IIS configuration of our 3-rd party application so 
>>> that it
>>> doesn't require client certificates, as the data being sent contains 
>>> the
>>> real authentication information. I"m not sure this is really an 
>>> option, as I
>>> don't know IIS at all. We DO have access to the server, though.
>>>
>>> Do both of these methods work, and encrypt our data? If so, is the
>>> encryption in the second case just as strong as if we used client
>>> certificates, or is it weaker because there is only a server 
>>> certificate? Is
>>> there any other method I missed?
>>>
>>> The application we are accessing initially provides a login page, 
>>> and we
>>> just provide a MethodPost with the needed data, so the SSL 
>>> Connection itself
>>> isn't initially authenticated. What I don't really understand is how a
>>> generic web browser certificate is any better than no certificate at 
>>> all.
>>> Why is a personal certificate required via HttpClient and not via a web
>>> browser?
>>>
>>> _________________________________________________________________
>>> Get FREE company branded e-mail accounts and business Web site from
>>> Microsoft Office Live
>>> http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: 
>>> httpclient-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>> -- 
>> yours,
>>
>> Julius Davies
>> 416-652-0183
>> http://juliusdavies.ca/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>>
>
> _________________________________________________________________
> All-in-one security and maintenance for your PC.  Get a free 90-day 
> trial! 
> http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://clk.atdmt.com/MSN/go/msnnkwlo0050000001msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail

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


-- 
Aloha,
Richard Suematsu
SynCaDD Systems, Inc.


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


Mime
View raw message