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]
