Hi Bruno, Thanks for the extra details, I've updated the RFE with the last part of your reply:
"SSL connector configuration improvements" http://restlet.tigris.org/issues/show_bug.cgi?id=489 What you propose sounds great to me. I don't think either that Jetty 7 should be part of Restlet 1.1, more likely part of Restlet 1.2. Best regards, Jerome -----Message d'origine----- De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot Envoyé : mercredi 2 juillet 2008 16:45 À : [email protected] Objet : Re: SSL + Virtual Hosts and Issue #489? Hi Alex, I'll start with the short answer: the workaround you're using, which consists of putting a single pair of key/certificate (with associated chain of certificates perhaps) per keystore, seems to be the most practical solution. That's what I do, personally. I find it easier to manage my keys and certificates using PKCS#12 (.p12) files, storing a single private key per file. PKCS#12 files are a type of keystore that's recognised by Java, using keyStoreType="PKCS12". This is perhaps because that's how I get my certificates from our certification authority: that's the format the browser (Firefox at least) uses to export key/certificates (this saves me some import/export operations to JKS using keytool). The other type of keystore I tend to use is the Apple KeychainStore (OSX only), but it has a bug whereby only one private key can be used anyway. Any particular reason why you would need two pairs of private key/certificates in the same keystore in practice? If you want to use two certificates, you're going to have to configure two connectors anyway, so I would imagine having two keystore files is not necessarily a major problem. More details... I don't think this problem is specific to Restlet. What I've tried to do with jSSLutils and the SSL extension to Restlet is to make it a bit easier to configure the SSLContext, preferably independently of the underlying type of connector. Choosing the alias can be done by configuring the X509KeyManager, I've tried to make this a bit more flexible with jSSLutils by providing an X509KeyManagerWrapper (since version 0.3). This being said, it's not something I've tried extensively, but it should be possible to write a relatively simple wrapper that helps you pick a given alias based on the hostname of the socket. Currently, although the classes related to SSLContext factories are in the Restlet tree, they're not used. What's missing is: 1. We'd need to agree on a parameter name to pass an SslContextFactory instance, in a similar way to the way the current SSL parameters are passed; this shouldn't be a big problem. 2. The underlying Jetty connectors (of Jetty) used by the Jetty connector (of Restlet) don't support "setSslContext". I've submitted a patch to Jetty for this, but I don't think it's been integrated yet. I should follow this up (I think they'd be keen on seeing a unit test), but I haven't had time to do so recently. I haven't really pushed for this, since I doubt this feature will be in Jetty 6.1.x anyway, only in 7.x, which most certainly won't be used in Restlet 1.1. What we could do meanwhile would be to have a custom implementation of a Jetty connector (org.mortbay.jetty.AbstractConnector) that would support setSslContext in the Restlet connector. The other connectors (Grizzly and Simple) can use "setSslContext" or equivalent. Best wishes, Bruno. Alex Milowski wrote: > I ran into a problem just yesterday with wildcard SSL certificates. I > had a new keystore with > two wildcards certificates in it and, by default, restlet seemed to > pick the wrong one. When I > deleted the wrong wildcard from the keystore, everything worked fine. > > I'll confess that the interaction between keystores, SSL, and Restlet > is something I > just don't quite understand. > > Now, looking at issue #489, I see that there are some changes coming that > should help me. Can some detail how I'll be able to use this new SSL > context factory > to handle associating certifcates (or aliases in a keystore) with a > virtual host? > > --Alex Milowski >
