Hi Bruno,
[...]
> Yes, this seems sensible.
> So, I think I'll keep keystore* for the server-side (for
> compatibility),
> add an optional trustore* for the server-side (falling back on the
> server keystore*), add an optional clientKeystore* for the
> client-side
> (falling back on keystore*), add an optional
> clientTruststore* (falling
> back on clientKeystore* and truststore*, I haven't really thought
> through which order would be best...)
This sounds perfect to me.
> > OK. To be honest, I wasn't aware of this subtelety :)
> > Would it be hard to provide support for configuring these additional
> > keystore types?
>
> One way consists of configuring the PKCS#11 provider in the
> java.security properties, which will add a new (named) provider.
> With a keystoreProvider property, it should then just be a matter of
> allowing either the InputStream or the provider name to be null,
[...]
> This would allow both existing keystore, PKCS#11 and Apple
> KeychainStore
> to be configurable from the same sort kind of properties. I'm
> not sure
> if all connectors would support this, but this seems
> reasonably easy to
> implement. In fact, that's more or less what the current Simple
> HttpsServerHelper does.
Sounds good!
> Is there a guideline in Restlet regarding which coding style
> is better between "( ) ? : " and "if() {} else {}"?
We use the former in constructors and places where the test is really simple
(for NPE checks for examples). We use the second form in other cases.
> The other way would be to configure the PKCS#11 provider dynamically,
> which would require a few more properties, more re-factoring, more
> special cases to handle...
Maybe we can consider this in a second step. Feel free to enter separate
RFEs if you want to keep track of this.
> Yes, indeed. However, I've already run into other related
> problems for
> trying to use the same keystore for the client and the server.
>
> If a keystore contains both a server and a client set of credentials
> (key+certificate), it seems that the server connectors don't
> necessarily
> pick up the right one. I made up a TestCA which signed a certificate
> with CN=localhost (for the server) and another with
> CN=testclient to be
> used by the client and bundled them in the same keystore. The server
> helpers (and what they rely one) were using 'testclient' as a server
> certificate. To be fair my test certificates don't have any usage
> constraints, so maybe the underlying servers would have
> looked through
> the keystores to find only suitable certificates, but I
> couldn't really
> find where to specify the name of the alias to be used. There
> might be a
> wider issue to look into regarding SSL connections: serving several
> certificates if multiple connectors on different IP addresses and
> multiple virtual hosts, certificate with alternate subject names,
> behaviour with TLS, ... This can become complex quite
> rapidly, and would
> probably take a long time to address (and would also very certainly
> affect Jetty and Grizzly).
> In this context, separating client and server keystores seems
> easier :-)
I understand, thanks for your interest and concern on this subject. Let's
plan to progressively improve Restlet support for SSL. Again, feel free to
enter RFEs as you like.
Best regards,
Jerome
