To give you a bit more details, just in case you manage to see a bit
more what's happening on your side, the patch that was put in the trunk
today (r6407) was clearly due to the fact I had omitted a very important
line: the one that passes the parameters to the factory:
if (result == null) {
result = new DefaultSslContextFactory();
+ result.init(helper.getHelpedParameters());
}
Once that was fixed, the SSLContexts appear to be initialised as
expected (I've even run this with the debugger within Eclipse).
The other patch that affected the SSLContext was r6391. It was
essentially moving the code duplicated in the DefaultSslContextFactory
and in the default connectors into the DefaultSslContextFactory anyway:
@@ -267,37 +269,7 @@ public class HttpsServerHelper extends
SimpleServerHelper {
// Initialize the SSL context
final SslContextFactory sslContextFactory = SslUtils
.getSslContextFactory(this);
- SSLContext sslContext;
- /*
- * If an SslContextFactory has been set up, its settings take
priority
- * over the other parameters (which are otherwise used to build and
- * initialize an SSLContext).
- */
- if (sslContextFactory == null) {
- final KeyStore keyStore =
KeyStore.getInstance(getKeystoreType());
- final FileInputStream fis = getKeystorePath() == null ? null
- : new FileInputStream(getKeystorePath());
- final char[] password = getKeystorePassword() == null ? null
- : getKeystorePassword().toCharArray();
- keyStore.load(fis, password);
- if (fis != null) {
- fis.close();
- }
-
- final KeyManagerFactory keyManagerFactory = KeyManagerFactory
- .getInstance(getCertAlgorithm());
- keyManagerFactory.init(keyStore,
getKeyPassword().toCharArray());
-
- final TrustManagerFactory trustManagerFactory =
TrustManagerFactory
- .getInstance(getCertAlgorithm());
- trustManagerFactory.init(keyStore);
-
- sslContext = SSLContext.getInstance(getSslProtocol());
- sslContext.init(keyManagerFactory.getKeyManagers(),
- trustManagerFactory.getTrustManagers(), null);
- } else {
- sslContext = sslContextFactory.createSslContext();
- }
+ SSLContext sslContext = sslContextFactory.createSslContext();
Considering that the SslContextFactory seems to behave as expected, I'm
not quite sure the problem comes from there.
While I wasn't noticing the problem on my Linux box, I'm noticing a
similar problem on my Mac: the connection just hangs when connecting to
my test app when using the Simple connector (not with Jetty/Grizzly).
I think the only difference then, from the previous code, is that the
previous code used to initialise the trustmanager with the same keystore
as the keymanager.
In fact, this solves the problem, partly. If I use the same settings for
the trust manager in this test app, it now works on my Mac:
params.add("truststorePath", "...");
params.add("truststorePassword", "testtest");
This shouldn't be required. I've had a brief look at the SimpleFramework
code itself, but I can't spot anything obvious.
If you could try to set the truststore like your keystore, perhaps it
would fix your problem in the short term.
Best wishes,
Bruno.
On 25/03/2010 18:44, David Fogel wrote:
> I'll try Jetty to see if it works, although I'd prefer in the long
> term to use Simple. the only thing is that this is a bit more
> burdensome to try for our environment, because we have an OSGi-based
> stack, and I have to rebuild any new extension with a new manifest
> entry to make it a bundle fragment instead of a bundle (which is how
> we deploy restlet extensions, which strategy I've suggested before).
>
> -Dave
>
> ------------------------------------------------------
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2465073
>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2465161
