Re: SSL issue with Jetty, Simple
Hi Bruno- Actually, we were using the keytool's importKeystore command, which was part of the problem. For whatever reason, the result of importing a PKCS12 keystore which only contains the cert+key, combined with importing the trustca certs in the chain directly into the JKS store in a separate step, produced a broken store. When we created a PKCS12 file and imported the trustca certs into that (which I used Portecle for), and only then converted the whole thing into a JKS format, everything worked. I don't know why, but tha's what happened. :-) thanks again, -Dave Fogel On Mon, May 10, 2010 at 9:28 AM, Bruno Harbulot bruno.harbu...@manchester.ac.uk wrote: ... 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 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2607800
Re: SSL issue with Jetty, Simple
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=4447dsMessageId=2606825
Re: SSL issue with Jetty, Simple
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=4447dsMessageId=2604404 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2605690
SSL issue with Jetty, Simple
Hi all- We're having a problem with serving our restlet web application over SSL. It's very possible that we're doing something wrong with how we're setting up the keystore and cert. We had previously set up SSL with a self-signed cert, generated using java keytool. This worked fine on Jetty and, until recently, with the Simple connector, which had some hanging issues a few revisions ago (but which may have been fixed, we're not sure. overall we'd prefer to get back to using the simple connector). Our configuration involved something like this: SeriesParameter params = s.getServers().add(Protocol.HTTPS, 8443) .getContext().getParameters(); params.add(keystorePath, path/to/keystore.jks); params.add(keystorePassword, secret); params.add(keyPassword, secret); So, like I said, this worked fine with a self-signed cert, although obviously browsers complain at first. We recently decided to acquire a real CA-signed cert, which we got from StartSSL.com. I built up a keystore which imports their root certs and the cert they signed for us. Doing a keytool -list command shows something like this: Keystore type: JKS Keystore provider: SUN Your keystore contains 3 entries startcom.ca.sub, Apr 26, 2010, trustedCertEntry, Certificate fingerprint (MD5): 30:B0:5A:F7:B2:F4:BE:0C:28:67:15:EA:CC:5B:24:20 startcom.ca, Apr 26, 2010, trustedCertEntry, Certificate fingerprint (MD5): 22:4D:8F:8A:FC:F7:35:C2:BB:57:34:90:7B:8B:22:16 startcom pfx certificate, Apr 26, 2010, PrivateKeyEntry, Certificate fingerprint (MD5): 15:F4:A5:34:C6:B1:DE:BE:BF:4E:5D:83:BA:97:89:1E Here is what we experience now: With Jetty: - everything seems to work great in our Safari, Chrome, and IE browsers, in that HTTPS works and the browser doesn't complain. - Firefox complains that the cert is Untrusted With Simple extension, and using the same configuration: - no access at all via HTTPS. no response or log message at all on the server at startup or on request Anyone else successfully serving up CA-signed HTTPS using Jetty or Simple? And why doesn't the default connector do HTTPS? Also, I've never been clear on what the org.restlet.ext.ssl module is for- will it add HTTPS support to the default restlet connector? Thanks, -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604257
Re: SSL issue with Jetty, Simple
Hi Dave, On 06/05/2010 15:16, David Fogel wrote: We had previously set up SSL with a self-signed cert, generated using java keytool. This worked fine on Jetty and, until recently, with the Simple connector, which had some hanging issues a few revisions ago (but which may have been fixed, we're not sure. overall we'd prefer to get back to using the simple connector). Have you tried the Simple connector since 2.0-RC2? It should incorporate the fix discussed in the thread you started at the end of March http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2464621 (a newer release of the Simple library). Our configuration involved something like this: SeriesParameter params = s.getServers().add(Protocol.HTTPS, 8443) .getContext().getParameters(); params.add(keystorePath, path/to/keystore.jks); params.add(keystorePassword, secret); params.add(keyPassword, secret); This looks correct (although you might need to configure a truststore too if you're using the Simple connector, see below). We recently decided to acquire a real CA-signed cert, which we got from StartSSL.com. I built up a keystore which imports their root certs and the cert they signed for us. Doing a keytool -list command shows something like this: Keystore type: JKS Keystore provider: SUN Your keystore contains 3 entries startcom.ca.sub, Apr 26, 2010, trustedCertEntry, Certificate fingerprint (MD5): 30:B0:5A:F7:B2:F4:BE:0C:28:67:15:EA:CC:5B:24:20 startcom.ca, Apr 26, 2010, trustedCertEntry, Certificate fingerprint (MD5): 22:4D:8F:8A:FC:F7:35:C2:BB:57:34:90:7B:8B:22:16 startcom pfx certificate, Apr 26, 2010, PrivateKeyEntry, Certificate fingerprint (MD5): 15:F4:A5:34:C6:B1:DE:BE:BF:4E:5D:83:BA:97:89:1E Here is what we experience now: With Jetty: - everything seems to work great in our Safari, Chrome, and IE browsers, in that HTTPS works and the browser doesn't complain. - Firefox complains that the cert is Untrusted What does Firefox say in detail? Usually, you can get the certificate and it will tell you what's wrong with it (on the first dialog after the warning page, the one where you can get the cert and choose to accept/refuse it). Maybe the StartSSL CA certificates aren't installed in this Firefox (it may also vary depending on the distribution on Linux for example). I'm afraid I haven't tried StartSSL. The ability for a CA to be trusted by a browser often has nothing to do with the browser or its technical capabilities, but is rather an administrative, legal or political issue as to which CAs get bundled with the browser's installer. With Simple extension, and using the same configuration: - no access at all via HTTPS. no response or log message at all on the server at startup or on request Perhaps try setting the truststore to use the keystore too? params.add(truststorePath, path/to/keystore.jks); params.add(truststorePassword, secret); Otherwise, you might run into a similar problem as in this thread: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2599797 (This is due to the fact that Simple always ask for a client-certificate at the moment). Anyone else successfully serving up CA-signed HTTPS using Jetty or Simple? And why doesn't the default connector do HTTPS? I have. Admittedly, mostly with the UK e-Science CA: its certificates aren't bundled by default with browsers, but that's an admin/trust problem, not a technical one. Also, I've never been clear on what the org.restlet.ext.ssl module is for- will it add HTTPS support to the default restlet connector? The SSL extension is mostly useful if you want advanced SSLContext settings (e.g. specific client certificate settings or non-default trust models such as those used with FOAF+SSL or grid computing). You probably don't need it if you're not using client certificates at all. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604285
Re: SSL issue with Jetty, Simple
Hi Bruno- Thanks for responding about this, comments inline.. On Thu, May 6, 2010 at 11:18 AM, Bruno Harbulot bruno.harbu...@manchester.ac.uk wrote: Have you tried the Simple connector since 2.0-RC2? It should incorporate the fix discussed in the thread you started at the end of March http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2464621 (a newer release of the Simple library). Our current issue with Simple is based on the most recent released simple jar and the restlet trunk for org.restlet.ext.simple. However, I have not yet retried simple with the self-signed cert, so it's possible it will work with that. This looks correct (although you might need to configure a truststore too if you're using the Simple connector, see below). I will try simple with the truststore configured. What does Firefox say in detail? Usually, you can get the certificate and it will tell you what's wrong with it (on the first dialog after the warning page, the one where you can get the cert and choose to accept/refuse it). firefox is saying: local.mydomain.org:8083 uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) Maybe the StartSSL CA certificates aren't installed in this Firefox (it may also vary depending on the distribution on Linux for example). I'm afraid I haven't tried StartSSL. The ability for a CA to be trusted by a browser often has nothing to do with the browser or its technical capabilities, but is rather an administrative, legal or political issue as to which CAs get bundled with the browser's installer. Looking at firefox's list of certificate authorities, I see the various startcom certs. So as far as I understand it, it should work. From what I've heard elsewhere, firefox differs from other browsers in part by using it's own list of trusted root certs, instead of the host system's built-in list. But either way, the certs seem to be there. I'm pretty sure that the startcom/startssl certs are widely enough used that they're trusted by all browsers and operating systems. They also specifically claim this on their site. So I feel it is more likely that I've misconfigured the keystore or misconfigured restlet/jetty/etc. -Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604309
Re: SSL issue with Jetty, Simple
Hi Dave, On 06/05/2010 17:07, David Fogel wrote: What does Firefox say in detail? Usually, you can get the certificate and it will tell you what's wrong with it (on the first dialog after the warning page, the one where you can get the cert and choose to accept/refuse it). firefox is saying: local.mydomain.org:8083 uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) Maybe the StartSSL CA certificates aren't installed in this Firefox (it may also vary depending on the distribution on Linux for example). I'm afraid I haven't tried StartSSL. The ability for a CA to be trusted by a browser often has nothing to do with the browser or its technical capabilities, but is rather an administrative, legal or political issue as to which CAs get bundled with the browser's installer. Looking at firefox's list of certificate authorities, I see the various startcom certs. So as far as I understand it, it should work. From what I've heard elsewhere, firefox differs from other browsers in part by using it's own list of trusted root certs, instead of the host system's built-in list. But either way, the certs seem to be there. I'm pretty sure that the startcom/startssl certs are widely enough used that they're trusted by all browsers and operating systems. They also specifically claim this on their site. So I feel it is more likely that I've misconfigured the keystore or misconfigured restlet/jetty/etc. 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=4447dsMessageId=2604404
