Hello,
Whilst looking into Issue 376
<http://restlet.tigris.org/issues/show_bug.cgi?id=376>, I've been trying
to implement a test that uses HTTPS, since I can't find one in the
current test suite. There are a few problems I came across, mainly
related to Issue 281 <http://restlet.tigris.org/issues/show_bug.cgi?id=281>.
1. I can't find which properties need to be used for setting the
keystores and truststores used by the clients. Did I miss something?
I've had to use -Djavax.net.ssl.keyStore, and similar VM parameters.
2. As Chuck Hinson pointed out as part of Issue 281, keystore and
truststore should be separate.
3. The implementation that uses the keystore seem to rely on the fact
that these keystores are always files (at least in the Jetty and Grizzly
helpers, the Simple helper can handle a null keystorePath). However,
this is not always true. Some keystores are not file-based: PKCS#11
tokens and the Apple KeychainStore.
4. There doesn't seem to be a provider parameter for a given keystore.
This could be useful, if someone would like to use
KeyStore.getInstance(type,provider), in particular for PKCS#11.
I'd be interested in seeing these issues fixed, and I could have a go at
it. The way I'm thinking of doing it would be to create more parameters:
serverKeystorePath, serverKeystoreProvider, serverKeystoreType,
serverKeystorePassword, serverKeyPassword, serverTruststorePath,
serverTruststoreProvider, serverTruststoreType,
serverTruststorePassword, serverCertAlgorithm + another set of these for
client*.
I could see some more complex scenarios where it would be useful to have
a CallbackHandler to input the password (especially on the client side),
but... one thing at a time.
Does this make sense? Should I try to address these problems? Any
suggestions?
Best wishes,
Bruno.
- SSL and KeyStores Bruno Harbulot
-
