Hi Dan,
The idea is to pass an instance of an SslContextFactory as an attribute
(or a class name as a parameter) of the Context.
In the 1.1 branch on the server side, the SSLContext is set up as follows:
1. If there is a *instance* of SslContextFactory in the
"sslContextFactory" *attribute* of the server's context, this is what's
used to make the SSLContext.
2. Else, if there is the *name* of a class that implements
SslContextFactory in the "sslContextFactory" *parameter* of the server's
context, this is what is used to make the SSLContext.
This is what's described on the wiki page you mentioned:
parameters.add("sslContextFactory",
"com.noelios.restlet.ext.ssl.PkixSslContextFactory");
3. Else, it tries the various parameters given in the connector
("keystorePath", "keystorePassword", ...), the default values being
those passed via the javax.net.ssl.* system properties.
The idea with this patch (which is in the 2.x branch) is to do the same
on the client side. It is only supported with the java.net connector
(not the Apache HTTP client library yet).
If you want to do something a bit specific with your own API, you'd need
to provide your own implementation of SslContextFactory (or use one that
uses the jsslutils wrapper perhaps) and pass it into the
"sslContextFactory" attribute of the client's context (again, that only
works in the 2.x branch).
Alternatively, if you're using the 1.1 branch, you can use the
workaround described in this comment
<http://restlet.tigris.org/issues/show_bug.cgi?id=586#desc4>, using the
Apache HTTP client connector. I must say this is not a clean way to
achieve this goal.
Best wishes,
Bruno.
Dan S wrote:
> I am sorry I don't fully understand your suggestion. The org.restlet.Client
> takes a org.restlet.Context object yet
> com.noelios.restlet.util.SslContextFactory does not extend
> org.restlet.Context. The createSslContext() method of the
> com.noelios.restlet.util.SslContextFactory class returns a
> javax.net.ssl.SSLContext object which also does not extend
> org.restlet.Context. Please clarify, thanks!
>
>> Hi Dan,
>>
>> You can't really do this with a ChallengeScheme/ChallengeResponse or
>> something similar, since it the certificates are passed at the SSL/TLS
>> layer, which is under HTTP.
>>
>> If you don't want to use the system properties, you can use your own
>> SslContextFactory passed as an argument to the client connector.
>>
>> Best wishes,
>>
>> Bruno.
>>
>> Dan S wrote:
>>> I noticed the example on
>>> http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html
>>> which configures one way SSL between the server and client by setting the
>>> system properties javax.net.ssl.trustStore, javax.net.ssl.trustStoreType,
>>> javax.net.ssl.trustStore.Password
>>> for the client.
>>> I have a requirement to set up two way SSL and not to use the
>>> aforementioned system properties. I am trying to piece together from the
>>> API how to do this.
>>> I realize I have to use the org.restlet.data.ChallengeResponse. I was
>>> thinking of using the constructor
>>> ChallengeResponse(ChallengeScheme scheme, String identifier,
>>> Series<Parameter> parameters). I just wasn't about a few things. For the
>>> ChallengeScheme can I use ChallengeScheme.CUSTOM?
>>> What do I use for the identifier argument?
>>> For Series<Parameter> argument do I just load them much the same way they
>>> are loaded on
>>> http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html
>>> (just replacing with the context for the Client and adding the trustore
>>> properties)?
>>> Is there anything else I might need?
>>>
>>> ------------------------------------------------------
>>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2396050
>>>
>
> ------------------------------------------------------
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2396138
>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2396507
