Re: SSL + Virtual Hosts and Issue #489?
Hello, Following the changes in the way Components can be configured (latest subversion revisions), configuring SSL to use an SslContextFactory is now possible this way: 1. Using the DefaultSslContextFactory: component xmlns=http://www.restlet.org/schemas/1.1/Component; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.restlet.org/schemas/1.1/Component; client protocol=FILE / server protocol=HTTPS port=8183 parameter name=sslContextFactory value=com.noelios.restlet.util.DefaultSslContextFactory / parameter name=keystorePath value=/path/to/keystore.p12 / parameter name=keystoreType value=PKCS12 / parameter name=keystorePassword value=testtest / parameter name=keyPassword value=testtest / /server defaultHost attach uriPattern= targetClass=org.restlet.example.tutorial.Part12 / /defaultHost /component 2. Using the PkixSslContextFactory (newly added, with jSSLutils 0.4): component xmlns=http://www.restlet.org/schemas/1.1/Component; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.restlet.org/schemas/1.1/Component; client protocol=FILE / server protocol=HTTPS port=8183 parameter name=sslContextFactory value=com.noelios.restlet.ext.ssl.PkixSslContextFactory / parameter name=keystorePath value=/path/to/keystore.p12 / parameter name=keystoreType value=PKCS12 / parameter name=keystorePassword value=testtest / parameter name=keyPassword value=testtest / parameter name=truststorePath value=/path/to/truststore.jks / parameter name=truststoreType value=JKS / parameter name=truststorePassword value=testtest / parameter name=crlUrl value=file:///path/to/crl.crl / parameter name=wantClientAuthentication value=true / /server defaultHost attach uriPattern= targetClass=org.restlet.example.tutorial.Part12 / /defaultHost /component There can be multiple crlUrl parameters. In addition, there are a couple of other parameters that can be set: - sslServerAlias, which will use a particular alias from the keystore, - disableCrl, which should be set to true if you don't want to use CRLs. Feedback welcome (especially if it doesn't work as intended!) Best wishes, Bruno.
RE: SSL + Virtual Hosts and Issue #489?
Hi Bruno,
Regarding the wiki, you don't seem to be registered. See the instructions
here to become an author:
http://wiki.restlet.org/about/2-restlet.html
Best regards,
Jerome
-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : vendredi 18 juillet 2008 17:48
À : discuss@restlet.tigris.org
Objet : Re: SSL + Virtual Hosts and Issue #489?
Alex Milowski wrote:
On Wed, Jul 16, 2008 at 2:32 AM, Jerome Louvel [EMAIL PROTECTED]
wrote:
Hi Alex,
I have added a paragraph on Confidentiality in the Securing
applications
page covering this topic:
http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-restlet/99-restlet/46-rest
let.html
At some point, it might makes sense to split up this page into several
ones.
Thanks.
I think it would be good to have some ssl-specific information make its
way into the connector documentation as an example.
That is, there is a simple example here:
http://wiki.restlet.org/docs_1.1/g1/13-restlet/27-restlet/37-restlet/38-rest
let.html
Maybe we could have about ssl configuration there as well. Of course, the
parameters are specific to the server helper...
Actually, using the SslContextFactory, the parameters can now be
consistent across the Grizzly, Jetty and Simple HTTPS connectors. We're
currently debating how it should be configured (see issue 489, feel free
to join in): parameters vs. instances.
I reckon that, for the DefaultSslContextFactory, parameters would
definitely make more sense. The current behaviour is to be able to pass
to its init() method a series of parameters that will more or less
follow the previous style of parameters. (It doesn't set any trust
manager, which instead use the values set in the javax.net.ssl.* system
properties as default).
The DefaultSslContextFactory wouldn't help choosing an alias. I guess it
would be feasible to have a fixed alias (in a similar way as I've done
it in jSSLutils with FixedServerAliasKeyManager -- see one of the
previous messages in this thread), but that wouldn't really help for
your initial problem, unless you use a different context per connector.
If you want to be able to use a single SSLContext between your two
sockets, you're going to need a KeyManager that is able to pick the
right alias depending on which socket is used.
In jSSLutils, the FixedServerAliasKeyManager I've implemented picks one
by always returning the same value (the one with which it's been
constructed). What we'd need for would be a way to configure such a
KeyManager so that it would look like this:
class SocketSelectorKeyManager implements X509KeyManager {
private final SomeInformation someInformation;
public SocketSelectorKeyManager(SomeInformation someInformation) {
this.someInformation = someInformation;
}
public String chooseServerAlias(String keyType, Principal[]
issuers, Socket socket) {
String alias = makeSomeDecisionBasedOn(someInformation,
socket.getLocalSocketAddress()); // (or other arguments)
return alias;
}
...
}
What SomeInformation and makeSomeDecisionBasedOn should be like
could depend on many factors. I could try to implement one of these in
jSSLutils, but I'm not sure how you'd like to be able to configure such
a KeyManager. Any preferences?
Regarding the documentation, I'm planning to document the
jSSLutils-specific settings on the jSSLutils website when I get the time
to do so (probably next week). I'll try to document the
DefaultSslContextFactory in the Restlet doc too (although I'm not sure I
have access to the wiki).
Best wishes,
Bruno.
RE: SSL + Virtual Hosts and Issue #489?
Hi Alex, For now, I've added a link from the Server connectors wiki page to the Securing a Restlet application page. Feel free to expand the documentation on the first page, maybe adding a concrete SSL configuration example. We should have some info on SslContextFactory as suggested by Bruno. I'll reply to his mail separately. Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Alex Milowski Envoyé : vendredi 18 juillet 2008 15:59 À : discuss@restlet.tigris.org Objet : Re: SSL + Virtual Hosts and Issue #489? On Wed, Jul 16, 2008 at 2:32 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, I have added a paragraph on Confidentiality in the Securing applications page covering this topic: http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-restlet/99-restlet/46-rest let.html At some point, it might makes sense to split up this page into several ones. Thanks. I think it would be good to have some ssl-specific information make its way into the connector documentation as an example. That is, there is a simple example here: http://wiki.restlet.org/docs_1.1/g1/13-restlet/27-restlet/37-restlet/38-rest let.html Maybe we could have about ssl configuration there as well. Of course, the parameters are specific to the server helper... --Alex Milowski
Re: SSL + Virtual Hosts and Issue #489?
On Wed, Jul 16, 2008 at 2:32 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, I have added a paragraph on Confidentiality in the Securing applications page covering this topic: http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-restlet/99-restlet/46-rest let.html At some point, it might makes sense to split up this page into several ones. Thanks. I think it would be good to have some ssl-specific information make its way into the connector documentation as an example. That is, there is a simple example here: http://wiki.restlet.org/docs_1.1/g1/13-restlet/27-restlet/37-restlet/38-restlet.html Maybe we could have about ssl configuration there as well. Of course, the parameters are specific to the server helper... --Alex Milowski
Re: SSL + Virtual Hosts and Issue #489?
Alex Milowski wrote:
On Wed, Jul 16, 2008 at 2:32 AM, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Alex,
I have added a paragraph on Confidentiality in the Securing applications
page covering this topic:
http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-restlet/99-restlet/46-rest
let.html
At some point, it might makes sense to split up this page into several ones.
Thanks.
I think it would be good to have some ssl-specific information make its
way into the connector documentation as an example.
That is, there is a simple example here:
http://wiki.restlet.org/docs_1.1/g1/13-restlet/27-restlet/37-restlet/38-restlet.html
Maybe we could have about ssl configuration there as well. Of course, the
parameters are specific to the server helper...
Actually, using the SslContextFactory, the parameters can now be
consistent across the Grizzly, Jetty and Simple HTTPS connectors. We're
currently debating how it should be configured (see issue 489, feel free
to join in): parameters vs. instances.
I reckon that, for the DefaultSslContextFactory, parameters would
definitely make more sense. The current behaviour is to be able to pass
to its init() method a series of parameters that will more or less
follow the previous style of parameters. (It doesn't set any trust
manager, which instead use the values set in the javax.net.ssl.* system
properties as default).
The DefaultSslContextFactory wouldn't help choosing an alias. I guess it
would be feasible to have a fixed alias (in a similar way as I've done
it in jSSLutils with FixedServerAliasKeyManager -- see one of the
previous messages in this thread), but that wouldn't really help for
your initial problem, unless you use a different context per connector.
If you want to be able to use a single SSLContext between your two
sockets, you're going to need a KeyManager that is able to pick the
right alias depending on which socket is used.
In jSSLutils, the FixedServerAliasKeyManager I've implemented picks one
by always returning the same value (the one with which it's been
constructed). What we'd need for would be a way to configure such a
KeyManager so that it would look like this:
class SocketSelectorKeyManager implements X509KeyManager {
private final SomeInformation someInformation;
public SocketSelectorKeyManager(SomeInformation someInformation) {
this.someInformation = someInformation;
}
public String chooseServerAlias(String keyType, Principal[]
issuers, Socket socket) {
String alias = makeSomeDecisionBasedOn(someInformation,
socket.getLocalSocketAddress()); // (or other arguments)
return alias;
}
...
}
What SomeInformation and makeSomeDecisionBasedOn should be like
could depend on many factors. I could try to implement one of these in
jSSLutils, but I'm not sure how you'd like to be able to configure such
a KeyManager. Any preferences?
Regarding the documentation, I'm planning to document the
jSSLutils-specific settings on the jSSLutils website when I get the time
to do so (probably next week). I'll try to document the
DefaultSslContextFactory in the Restlet doc too (although I'm not sure I
have access to the wiki).
Best wishes,
Bruno.
RE: SSL + Virtual Hosts and Issue #489?
Hi Alex, I have added a paragraph on Confidentiality in the Securing applications page covering this topic: http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-restlet/99-restlet/46-rest let.html At some point, it might makes sense to split up this page into several ones. Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Alex Milowski Envoyé : mardi 15 juillet 2008 17:14 À : discuss@restlet.tigris.org Objet : Re: SSL + Virtual Hosts and Issue #489? On Sat, Jul 12, 2008 at 5:51 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex and Bruno, My understanding is that Alex wants this: - a single server socket accepting all HTTP requests - several SSL certificates selected depending on the matching virtual host I think this can't be done because in order to determine the virtual host, you need to have read and parsed the HTTP request headers to get the Host one. You can only do that if you already use the certificate to read the incoming SSL stream. So, it seems that the only solution is to have two listening server sockets and then two Restlet server connectors. Bruno's solution would let you share the same certificate store by selecting the alias based on the actual socket used, but you still need two sockets. If you want to use HTTPS's default port, that means that you need two separate IP addresses, at least virtual IP addresses. Let me know if I missed something. That makes sense to me. I seem to remember having to do this with apache once or twice. This should certainly be documented somewhere as we go forward. Is there an SSL tips page on the wiki? --Alex Milowski
Re: SSL + Virtual Hosts and Issue #489?
On Sat, Jul 12, 2008 at 5:51 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex and Bruno, My understanding is that Alex wants this: - a single server socket accepting all HTTP requests - several SSL certificates selected depending on the matching virtual host I think this can't be done because in order to determine the virtual host, you need to have read and parsed the HTTP request headers to get the Host one. You can only do that if you already use the certificate to read the incoming SSL stream. So, it seems that the only solution is to have two listening server sockets and then two Restlet server connectors. Bruno's solution would let you share the same certificate store by selecting the alias based on the actual socket used, but you still need two sockets. If you want to use HTTPS's default port, that means that you need two separate IP addresses, at least virtual IP addresses. Let me know if I missed something. That makes sense to me. I seem to remember having to do this with apache once or twice. This should certainly be documented somewhere as we go forward. Is there an SSL tips page on the wiki? --Alex Milowski
RE: SSL + Virtual Hosts and Issue #489?
Hi Alex and Bruno, My understanding is that Alex wants this: - a single server socket accepting all HTTP requests - several SSL certificates selected depending on the matching virtual host I think this can't be done because in order to determine the virtual host, you need to have read and parsed the HTTP request headers to get the Host one. You can only do that if you already use the certificate to read the incoming SSL stream. So, it seems that the only solution is to have two listening server sockets and then two Restlet server connectors. Bruno's solution would let you share the same certificate store by selecting the alias based on the actual socket used, but you still need two sockets. If you want to use HTTPS's default port, that means that you need two separate IP addresses, at least virtual IP addresses. Let me know if I missed something. Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot Envoyé : jeudi 10 juillet 2008 13:58 À : discuss@restlet.tigris.org Objet : Re: SSL + Virtual Hosts and Issue #489? Hi all, Bruno Harbulot wrote: 1. We assume there's going to be a single SSLContext common to all servers of the component created via an SslContextFactory (it's set up in the Context of the Component). In theory, it should be possible to set up the SSLContext to use a custom X509KeyManager [1] that implements chooseServerAlias(String keyType, Principal issuers, Socket socket) to choose the appropriate alias depending on the listening socket that is used. Unfortunately, I've tried, and the socket passed to that method is temporary socket that has almost the same characteristics as the actual one, but not all, especially not the local address, which is what we would need. I've just talked about it with the OpenJDK security team [2], but I wouldn't expect a fix in the mainstream JVMs any time soon. Sorry, what I've said was wrong. It can work. There is a second call during the SSL handshake during accept, as discussed in this thread [2]. Therefore, it would be possible to choose an alias based on the actual socket and its local address. Essentially, it's now a matter of providing a way to configure this: chooseServerAlias(String keyType, Principal issuers, Socket socket) Best wishes, Bruno. [1] http://java.sun.com/j2se/1.5.0/docs/api/javax/net/ssl/X509KeyManager.html [2] http://mail.openjdk.java.net/pipermail/security-dev/2008-July/000225.html
Re: SSL + Virtual Hosts and Issue #489?
Hi all, Bruno Harbulot wrote: 1. We assume there's going to be a single SSLContext common to all servers of the component created via an SslContextFactory (it's set up in the Context of the Component). In theory, it should be possible to set up the SSLContext to use a custom X509KeyManager [1] that implements chooseServerAlias(String keyType, Principal issuers, Socket socket) to choose the appropriate alias depending on the listening socket that is used. Unfortunately, I've tried, and the socket passed to that method is temporary socket that has almost the same characteristics as the actual one, but not all, especially not the local address, which is what we would need. I've just talked about it with the OpenJDK security team [2], but I wouldn't expect a fix in the mainstream JVMs any time soon. Sorry, what I've said was wrong. It can work. There is a second call during the SSL handshake during accept, as discussed in this thread [2]. Therefore, it would be possible to choose an alias based on the actual socket and its local address. Essentially, it's now a matter of providing a way to configure this: chooseServerAlias(String keyType, Principal issuers, Socket socket) Best wishes, Bruno. [1] http://java.sun.com/j2se/1.5.0/docs/api/javax/net/ssl/X509KeyManager.html [2] http://mail.openjdk.java.net/pipermail/security-dev/2008-July/000225.html
Re: SSL + Virtual Hosts and Issue #489?
Hi Alex, Alex Milowski wrote: On Thu, Jul 3, 2008 at 2:36 PM, Bruno Harbulot [EMAIL PROTECTED] wrote: There can only be one certificate per IP address (unless using a different port), thus one certificate per connector. (An exception to this would be to use something like what GnuTLS does [1], but I've never seen it used in practice. I'm not sure at all how browsers and other clients support that sort of negotiation.) Assuming you'd want to do this on a Connector rather than on a VirtualHost, this would still have to be implemented in the KeyManager (and thus in the SSLContext). I'll try to make things progress on the Jetty side and/or find another solution soon. I'm not sure when the Restlet 1.1 RC1 is due for, but I haven't had much spare time for this recently. What I'd like to be able to do is have a certificate (i.e. alias in a keystore) be associated with a Virtual host so that if I have two virtual hosts on one server I can associate the different SSL certificates with each host's connection. Now, I can work around the IP address limitations by using additional addresses on the server. Is this a Restlet limitation, a Jetty limitation, or a Java SSL implemenation limitation? In the latest revision in the subversion tree, it's now possible to set an an SSLContext, via the sslContextFactory context parameter. Thus, it's also possible to customise the KeyManagers (whether-or-not using jSSLutils), which should make it possible to achieve what you're after. Let's assume that host1.example.org is 10.0.0.1 and host2.example.com is 10.0.0.2 and that you have added a couple of servers. There are two possible situations: 1. We assume there's going to be a single SSLContext common to all servers of the component created via an SslContextFactory (it's set up in the Context of the Component). In theory, it should be possible to set up the SSLContext to use a custom X509KeyManager [1] that implements chooseServerAlias(String keyType, Principal issuers, Socket socket) to choose the appropriate alias depending on the listening socket that is used. Unfortunately, I've tried, and the socket passed to that method is temporary socket that has almost the same characteristics as the actual one, but not all, especially not the local address, which is what we would need. I've just talked about it with the OpenJDK security team [2], but I wouldn't expect a fix in the mainstream JVMs any time soon. 2. We can set up two different Contexts for the two servers, using something along these lines: Component component = new Component(); Server server1 = new Server(Protocol.HTTPS, host1.example.org, 8443, null); Server server2 = new Server(Protocol.HTTPS, host2.example.com, 8443, null); component.getServers().add(server1); component.getServers().add(server2); SslContextFactory sslContextFactory1 = ... /* an SslContextFactory that will return an SSLContext with an X509KeyManager choosing the alias for host1.example.org */ SslContextFactory sslContextFactory2 = ... /* an SslContextFactory that will return an SSLContext with an X509KeyManager choosing the alias for host2.example.com */ server1.getContext().getAttributes().put(sslContextFactory, sslContextFactory1); server2.getContext().getAttributes().put(sslContextFactory, sslContextFactory2); // (I then add a couple of virtual hosts, one for each name.) I've tried this, and it works. Best wishes, Bruno. [1] http://java.sun.com/j2se/1.5.0/docs/api/javax/net/ssl/X509KeyManager.html [2] http://mail.openjdk.java.net/pipermail/security-dev/2008-July/000225.html
Re: SSL + Virtual Hosts and Issue #489?
Bruno Harbulot wrote: 2. We can set up two different Contexts for the two servers, using something along these lines: Component component = new Component(); Server server1 = new Server(Protocol.HTTPS, host1.example.org, 8443, null); Server server2 = new Server(Protocol.HTTPS, host2.example.com, 8443, null); component.getServers().add(server1); component.getServers().add(server2); SslContextFactory sslContextFactory1 = ... /* an SslContextFactory that will return an SSLContext with an X509KeyManager choosing the alias for host1.example.org */ SslContextFactory sslContextFactory2 = ... /* an SslContextFactory that will return an SSLContext with an X509KeyManager choosing the alias for host2.example.com */ server1.getContext().getAttributes().put(sslContextFactory, sslContextFactory1); server2.getContext().getAttributes().put(sslContextFactory, sslContextFactory2); // (I then add a couple of virtual hosts, one for each name.) I've tried this, and it works. To be more specific on setting up the sslContextFactory, if you're willing to try jSSLutils from the subversion repository (0.4-SNAPSHOT, rev 30), you should be able to use something like this: jsslutils.sslcontext.X509SSLContextFactory sslContextFactory1 = new X509SSLContextFactory(keyStore, keypassword, trustStore); sslContextFactory1.setKeyManagerWrapper(new FixedServerAliasKeyManager.Wrapper(host1.example.org)); server1.getContext().getAttributes().put(sslContextFactory, new JsslutilsSslContextFactory(sslContextFactory1)); Feedback welcome of course. Best wishes, Bruno.
Re: SSL + Virtual Hosts and Issue #489?
On Thu, Jul 3, 2008 at 2:36 PM, Bruno Harbulot [EMAIL PROTECTED] wrote: There can only be one certificate per IP address (unless using a different port), thus one certificate per connector. (An exception to this would be to use something like what GnuTLS does [1], but I've never seen it used in practice. I'm not sure at all how browsers and other clients support that sort of negotiation.) Assuming you'd want to do this on a Connector rather than on a VirtualHost, this would still have to be implemented in the KeyManager (and thus in the SSLContext). I'll try to make things progress on the Jetty side and/or find another solution soon. I'm not sure when the Restlet 1.1 RC1 is due for, but I haven't had much spare time for this recently. What I'd like to be able to do is have a certificate (i.e. alias in a keystore) be associated with a Virtual host so that if I have two virtual hosts on one server I can associate the different SSL certificates with each host's connection. Now, I can work around the IP address limitations by using additional addresses on the server. Is this a Restlet limitation, a Jetty limitation, or a Java SSL implemenation limitation? --Alex Milowski
RE: SSL + Virtual Hosts and Issue #489?
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 À : discuss@restlet.tigris.org 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
Re: SSL + Virtual Hosts and Issue #489?
On Wed, Jul 2, 2008 at 7:45 AM, Bruno Harbulot [EMAIL PROTECTED] wrote: Hi Alex, 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. No particular reason. In fact, the lesson I learned here was not to keep them in the same keystore. 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. OK. Eventually I'm going to need this... :) 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. Why can't we set properties on the VirtualHost instance as to what alias and what keystore should be used for SSL transport? --Alex Milowski
Re: SSL + Virtual Hosts and Issue #489?
Hi Alex, Alex Milowski wrote: On Wed, Jul 2, 2008 at 7:45 AM, Bruno Harbulot [EMAIL PROTECTED] wrote: Hi Alex, 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. No particular reason. In fact, the lesson I learned here was not to keep them in the same keystore. [...] 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. OK. Eventually I'm going to need this... :) I'm not sure you would actually need this if you can keep a single identity (private key + certificate + perhaps chain of CA certificates) per keystore. However, I too would be interested in seeing this, especially when Apple fix their KeychainStore implementation (I'm not sure when this may be). Why can't we set properties on the VirtualHost instance as to what alias and what keystore should be used for SSL transport? There can only be one certificate per IP address (unless using a different port), thus one certificate per connector. (An exception to this would be to use something like what GnuTLS does [1], but I've never seen it used in practice. I'm not sure at all how browsers and other clients support that sort of negotiation.) Assuming you'd want to do this on a Connector rather than on a VirtualHost, this would still have to be implemented in the KeyManager (and thus in the SSLContext). I'll try to make things progress on the Jetty side and/or find another solution soon. I'm not sure when the Restlet 1.1 RC1 is due for, but I haven't had much spare time for this recently. Cheers, Bruno. [1] http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/
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
