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" <[EMAIL PROTECTED]>
Reply-To: "HttpClient User Discussion" <[email protected]>
To: "HttpClient User Discussion" <[email protected]>
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
