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. 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. Thanks again for your help, -Dave Fogel On Thu, May 6, 2010 at 1:09 PM, Bruno Harbulot <bruno.harbu...@manchester.ac.uk> wrote: ... > One way to diagnose what certificates are configured is to use OpenSSL > (often pre-installed on Linux/OSX): > > echo "" | openssl s_client -showcerts -connect local.mydomain.org:8083 > > The command above isn't configured with any trusted certificate, so it > will most likely say "verify error:num=19:self signed certificate in > certificate chain", which you can ignore. > > The important part is that it should show the certificate chain after: > > Certificate chain > 0 s:/C=UK/O=eScience/OU=Manchester/L=MC/CN=.../emailAddress=... > i:/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA > -----BEGIN CERTIFICATE----- > ... > XxdhCHujMWxwSLQq > -----END CERTIFICATE----- > 1 s:/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA > i:/C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root > -----BEGIN CERTIFICATE----- > ... > dZwURrmRAbx676x3Ef2po8s= > -----END CERTIFICATE----- > 2 s:/C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root > i:/C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root > -----BEGIN CERTIFICATE----- > ... > -----END CERTIFICATE----- > --- > Server certificate > subject=/C=UK/O=eScience/OU=Manchester/L=MC/CN=.../emailAddress=... > issuer=/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA > > > > Here, cert 0 (the server's) was issued by 1, which was issued by 2. I > didn't have anything explicit to do to get the server to serve the full > chain. I'm only using a keystore that contains these certs + the private > key for the server's cert, with extra config. (My keystore is in PKCS#12 > format, but that really shouldn't make any difference, your JKS seemed > fine, provided it contains the right intermediate certs.) > > What you should have is a chain that's not broken and that builds up to > at least something that's in Firefox's trusted CA certificates. > > > Best wishes, > > Bruno. > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2604404 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2605690
