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
