Hi,
Sorry, that's probably due to a patch I submitted a few weeks ago and
that was put in the trunk a couple of days ago.
The aim was to consolidate the SSL settings to have them in one place,
but it seems that there was a line missing unfortunately.
Here is a patch:
diff --git
a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
index 6ac6b93..36c7c80 100644
--- a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
+++ b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
@@ -218,6 +218,7 @@ public class SslUtils {
if (result == null) {
result = new DefaultSslContextFactory();
+ result.init(helper.getHelpedParameters());
}
return result;
I've tried it with the Jetty connector and it fixes the problem. It
doesn't seem to work so well with the Simple connector, I'm looking into it.
Best wishes,
Bruno.
On 25/03/2010 03:09, David Fogel wrote:
> Hi all-
>
> We recently updated our restlet libraries to the current trunk
> (specifically SVN revision 6394, which I imagine is roughly equivalent
> to the recent 2.0 RC1 release). We were previously working with a
> build from SVN 5929, from roughly late December. Now we're dealing
> with the fallout. For some reason this often seems to involve
> problems that are hard to resolve, or have subtle or hard to reproduce
> causes. Probably because of the fast pace of improvements in restlet
> development....
>
> Our previous problem, which I posted earlier had to do with the
> built-in Client connector waiting/suspended on a latch that never
> returns. We are temporarily avoiding that by using the HttpClient 4
> extension, which doesn't have this problem for us, but we'd prefer I
> think to use the built-in ones.
>
> The next thing we discovered was broken is HTTPS access for our web
> app. We now get a "The connection was reset" message in the browser
> (in this case it is firefox), when we try to GET a resource at the
> HTTPS port, and no request is logged by restlet. This had been
> working fine for use with the december build.
>
> Our configuration for the Component protocols is (roughly) as follows:
>
> Component c = new Component();
> c.getServers().add(Protocol.HTTP, 8080);
> Series<Parameter> params = c.getServers().add(Protocol.HTTPS,
> 8443).getContext().getParameters();
> params.add("keystorePath",
> "/an/absolute/path/to/the/keystore/localhost.jks");
> params.add("keystorePassword", "not actually our password");
> params.add("keyPassword", "another password");
>
> I'm not sure if it makes a difference, but we're using the
> simpleframework server connectors. I tried simpleversion 4.1.17 (which
> was working before and now doesn't) as well as the slightly newer
> 4.1.19 build.
>
> So, did something break in recent versions? or were we doing
> something wrong in the first place that just happened to work?
>
> I will also note that the documentation is VERY CONFUSING regarding
> configuring HTTPS/SSL in the userguide. There is only one example,
> and that example specifically uses the org.restlet.ext.ssl extension
> along with a SSLContextFactory set to be
> "org.restlet.ext.ssl.PkixSslContextFactory". I think that an example
> which explains the option of using the DefaultSslContextFactory would
> be appropriate, along with some explanation about which situations are
> better handled by the extension. Given that configuring one's server
> for HTTPS must be an extremely common task, it seems like there should
> be more about this- as it stands there seems to be more docs for
> setting up client cert authentication etc, which is probably less
> common.
>
> Thanks,
> -Dave Fogel
>
> ------------------------------------------------------
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2464621
>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2464831
