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
