Hi, Alex, Thanks for your note!
Are you on Linux? There's some interesting stuff going on in the following directories on my debian machine: /etc/ssl/certs/ /usr/share/ca-certificates/ /usr/share/ca-certificates/mozilla/ One thing you might be able to get away with: take the "cacerts" file from Java 1.5.0_11 and copy it over your Java 1.5.0_06 version. yours, Julius On 2/15/07, Alex Orloff <[EMAIL PROTECTED]> wrote:
Julius, thanks for your response -- for a minute there I wasn't sure if I had asked a good question or one so boneheaded that no one would bother to answer (sometimes there is a fine line). Regarding #2, I will implement your suggestion -- the notion of having an alternate self-imposed protocol works well for me and allows the kind of fine grained distinction between URLs that should use proper SSL and ones that can (or must) be trusted. Regarding #1 -- I'd settle for a simple HOWTO page on installing the certificates in one's browser and leave it at that. The upgrade to 1.5.11 would be nice but the sysadmins don't move at the speed of "get this bug fixed now !" if you know what I mean. What would be better is if java had a more flexible mechanism for getting the JRE trusted keychain up to date than installing a new JDK... hmm, there's room for thought. cheers, alex Julius Davies wrote: > #1. Great idea. I wouldn't mind putting together this collection of > certificates and adding it to "not-yet-commons-ssl" > (http://juliusdavies.ca/commons-ssl/) as: > > TrustMaterial.FIREFOX2 > TrustMaterial.IE6 > TrustMaterial.IE7 > > But you're going to have to give me a few months before that happens > (if it ever does). And that means I have to get myself a proper SSL > cert for hosting "not-yet-commons-ssl"! I don't want people to > download a compromised collection of the ROOT certificates! (So > hmmm.... this might take longer than a few month!) (Do I have to > ditch the shared hosting, too!?!?! Groan!) (Interesting to note that > we download IE7 and Firefox2 over "http", so similar problem there). > > In the meantime, consider upgrading to Java 6 or Java 5 build 11. I > think there are a few additional root CA's in those versions. (Hmmm, > again downloaded over "http"!). > > > #2. You must be doing something wrong. Maybe try this instead: > > Download not-yet-commons-ssl.jar from here: > http://juliusdavies.ca/commons-ssl/download.html > > Code your use of HttpClient like so: > > ====================================== > import org.apache.commons.ssl.HttpSecureProtocol; > > HttpSecureProtocol f = new HttpSecureProtocol(); > // Trust all certificates! (Still blowup on expired and bad > hostnames, though). > f.setTrustMaterial( TrustMaterial.TRUST_ALL ); > > // To avoid deprecation warnings: > ProtocolSocketFactory psf = f; > Protocol trustHttps = new Protocol("https-insecure", psf, 443); > Protocol.registerProtocol("https-insecure", trustHttps); > > HttpClient client = new HttpClient(); > GetMethod httpget = new GetMethod("https-insecure://mydomain.com/"); > client.executeMethod(httpget); > String s = httpget.getStatusLine().toString(); > System.out.println( "HTTPClient: " + s ); > ====================================== > Notice that only URL's of the form "https-insecure://" will trust all > certificates after this code has executed. Regular "https://"; URL's > still get full security. > > > yours, > > Julius > > > On 2/14/07, Alex Orloff <[EMAIL PROTECTED]> wrote: >> >> >> To start, I want to acknowledge that the httpclient library is very >> useful and I have had a lot of success with it. And I need to state that >> I have read the SSL FAQ, and even implemented the >> EasySSLProtocolSocketFactory solution. However, I am still running into >> an issue and perhaps I can approach the solution I am looking for by >> asking 2 questions (not the usual "how do I get it to work with SSL"). >> >> So I use the library to connect to many different webservers, and >> occasionally one comes along with a certificate that causes httpclient >> to throw an exception like this : >> >> javax.net.ssl.SSLHandshakeException: >> sun.security.validator.ValidatorException: PKIX path building failed: >> sun.security.provider.certpath.SunCertPathBuilderException: unable to >> find valid certification path to requested target >> >> Now I can get around this by signing my keychain with the certificate in >> question, which is the typical approach. So here's my first question : >> >> 1. Are there a set of certificates, possibly found in the average >> browser, that once added will "complete" my vanilla JDK1.5.6 (64 bit) >> keychain and allow httpclient to successfully make an HTTPS connection >> "anywhere the browser can without asking permission ?" Has anyone had >> some success say, adding all certificates in IE and FF ? As an addendum, >> does anyone know how to export a certificate from FF ? IE makes this >> easy but FF doesn't seem to allow it. Typically the issue that I find is >> that an intermediary certificate in the chain is not recognized (usually >> just above the certificates presented by the webserver in question). >> >> I don't mind adding the odd certificate for self-signers, but I'd like >> to do it once and for (if possible) and not piecemeal. >> >> Now for question 2. I implemented the EasySSLProtocolSocketFactory, and >> turned it on to test some of these connections. But I still get the >> "unable to find valid certification path to requested target" exception. >> So here is question 2. >> >> 2. Have I made an error in my implementation or is this "unable to find >> valid certification path to requested target" possible even when using >> EasySSLProtocolSocketFactory ? >> >> Thanks in advance for any responses. >> >> alex >> >> -- >> >> Alex Orloff >> Software Engineering >> Root Exchange, a division of Root Markets >> http://www.rootexchange.com >> W – (510) 812-3163 >> F – (415) 643-6789 >> E - [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Alex Orloff Software Engineering Root Exchange, a division of Root Markets http://www.rootexchange.com W – (510) 812-3163 F – (415) 643-6789 E - [EMAIL PROTECTED]
-- yours, Julius Davies 416-652-0183 http://juliusdavies.ca/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
