Hi Dave, On 08/05/10 17:31, David Fogel wrote: > Hi Bruno- > > Thanks for your feedback and suggestions on this. We've sorted out a > few things: > > 1) You were right that the Simple extension needs to have the > truststorePath and truststorePassword configured in order to run. > Once we added those config params in (in addition to the keystorePath, > keystorePssword, and keyPassword, Simple extension works again for > HTTPS. It seems like having the truststore default to the keystore, > (or maybe the JRE defaults?), would be better, but at any rate we're > glad to have it working again.
Unless there's a bug, the current default truststore is the JRE default truststore, if nothing is specified (or whatever is passed via the -Djavax.net.ssl.truststore properties). I think this is better than having the truststore be the keystore too by default. Don't you? One of the problems with making the truststore be the keystore (as it was the case with the Simple connector before the patch between RC1 and RC3) is that you are then unable to specify another truststore (which may rightly be different to the keystore). It seems also more consistent to use the JRE default truststore as the default truststore in general. I guess the problem was triggered by the combination of (a) Simple always asking a for client certificate and (b) the default truststore being too big. Perhaps it might be worth checking that the default behaviour is the same as when you specify the JRE truststore explicitly. It would be in $JAVA_HOME/lib/security/cacerts and the default password is 'changeit'. I'd be interested in knowing how many certificates you have in yours when you get the problem. You can find this using this: keytool -list -keystore /usr/lib/jvm/java-6-sun/jre/lib/security/cacerts > 2) We managed to get our StartSSL.com signed cert into a JKS-format > keystore in a way that works, so now both Jetty and Simple produce > warning-free HTTPS operation in our browsers. After an irritatingly > large amount of time spent mucking around with keystores, we are still > not sure why certain processes of importing the cert from a PKCS12 > format file to a JKS result in a keystore that has all the right certs > in it but which doesn't seem to understand their relationship. But we > HAVE found a process that results in a correctly-configured keystore, > so we're happy to move on. :-) (Specifically, I found an open-source > GUI tool for working with keystores, called Portecle > http://portecle.sourceforge.net/ which allowed me to first import the > trustca root certs in to the pkcs12 file, and then convert the entire > resulting store into JKS format. This results in a keystore which > looks almost identical to one produced by first importing the signed > host cert into the JKS and subsequently adding in the root certs (both > keystores have the same three certs in them, with the same > fingerprints, etc, but only one of them produces (when deployed in > Simple, Jetty, etc) an SSL handshake which presents the full chain of > trust like you mentioned in your previous message. Frustratingly, I > have no idea why this is. Ah, good to know. I'll investigate what needs to be done with the JKS format. I must admit I tend to use the PKCS#12 format more because that's how I get the certificates from my CA into my browser (I think most browsers can import/export .p12, but not JKS). I've just tried with a JKS store imported from a P12 store and it worked fine (the full chain was presented), but it might depend on how that JKS store is built. If your PKCS#12 file contained the right chain, I'd suggest using that format directly. (You'd probably need to build a JKS store if you want to distribute the certificates without the private key, if your clients need to be configured with such a truststore). Since Java 6, keytool can import/export keystores. You could have made the conversion using this (or the other way around depending on which way you want to go): keytool -srckeystore file.jks -destkeystore file.p12 -destkeystoretype PKCS12 Note that: - PKCS#12 keystores use the same key for the keystore and the keys themselves. - If you export keys into a JKS store, the store will be protected with the destination password but the keys themselves will still be protected with the password with which they were imported (unless specified otherwise with -destkeypass). Alternatively, when I've had the private key in a separate file, I've been able to do this with OpenSSL: openssl pkcs12 -export -chain -in host.crt \ -CAfile cacertchain.pem -inkey host.key \ -out host.p12 Best wishes, Bruno. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2606825
