Salut,
[adding users_at_grizzly.dev.java.net]
Bruno Harbulot wrote:
> Hello,
>
> I'm looking at Henry's test case (outside Glassfish) to try to use our
> custom SSLImplementation. The test case works like this (I've tried with
> and without setting the SSLConfig):
>
> GrizzlyWebServer ws = new GrizzlyWebServer(port,"/.../",true);
> // SSLConfig cfg = new SSLConfig();
> // cfg...
> // ...
> // ws.setSSLConfig(cfg);
> ws.start();
>
>
> I know it's a bit different to the Glassfish example, but I wonder if
> there isn't a similar problem.
Most probably yes.
In fact, I think SSLImplementation and
> SSLConfig do more or less the same thing , to the point that they
> conflict with each other. Perhaps making SSLConfig implement an
> interface just made of "SSLContext createSSLContext()" and let people
> configure the relevant class would be enough (and removing/deprecating
> SSLImplementation). This would certainly avoid some of the problems I'm
> describing below.
Agree. The history of why we have both is with v2, we were supporting
blocking I/O and non blocking. Non blocking needed SSLConfig, blocking
I/O not. Can you file an issue in Grizzly under:
https://grizzly.dev.java.net/servlets/ProjectIssues
Note that there is some work already related to SSLConfig
https://grizzly.dev.java.net/issues/show_bug.cgi?id=494
>
>
> 1. Case when an SSLConfig has been set in the GrizzlyWebServer instance
> (test case above, with SSLConfig not commented out):
>
> In GrizzlyWebServer.start(), the SSLContext of the SSLSelectorThread
> (sslST) will be set from that SSLConfig, at the begining, far before
> sslST.listen() is called. However, it's sslST.listen that then calls
> SelectorThreadConfig, via SelectorThread.listen() ->
> SelectorThread.initEndpoint().
>
> It seems that configuring the SSLImplementation by then is too late,
> since the SSLContext has already been set.
Agree.
>
>
> 2. Case when an SSLConfig hasn't been set in the GrizzlyWebServer instance:
>
> In GrizzlyWebServer.start(), a new SSLConfig is created anyway at the
> beginning, again, before sslST.listen() is called.
>
>
>
> Either way, even if I comment out the first part of
> GrizzlyWebServer.start() to let it pass without setting an SSLContext
> (and trying to let the SSLImplementation configuration go through),
> SSLSelectorThread.getSSLImplementation() is never called (there's an NPE
> if there's no SSLContext set), even if it's the default
> JSSEImplementation initialised in GrizzlyWebServer.createSelectorThread().
Hum at least we should not thrown an NPE.
>
>
>
> In my opinion, merging SSLConfig and SSLImplementation into a single
> SSLContext factory class (perhaps similar to the default one I've done
> in jSSLutils [1]), which may be initialised via system properties or via
> other means, would make sense.
> (This might also be useful for
> <https://grizzly.dev.java.net/issues/show_bug.cgi?id=494>)
Ok looks like you are watching grizzly as well :-)
>
> Note that an SSLContext factory doesn't solve the problem of setting
> want/needClientAuth, which would have to be configured separately
> (perhaps via "-Dcom.sun.grizzly.ssl.auth").
>
>
> Best wishes,
Many thanks!!!
A+
-- Jeanfrancois
>
> Bruno.
>
> [1]
> http://code.google.com/p/jsslutils/source/browse/trunk/jsslutils/src/main/java/org/jsslutils/sslcontext/SSLContextFactory.java
>
>
> Henry Story wrote:
>> I think I found the reason for the problem. I added the information to
>>
>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=486
>>
>> I had a bit of fun debugging this, and so I found the following
>> behavior that is a little suspicious. In
>>
>> com.sun.grizzly.http.SelectorThreadConfig
>>
>> When the following piece of code gets called
>>
>> if (System.getProperty(SSL_CONFIGURATION_SSLIMPL) != null) {
>> SSLImplementation sslImplementation = (SSLImplementation)
>> ClassLoaderUtil.load(System.getProperty(SSL_CONFIGURATION_SSLIMPL));
>> if (selectorThread instanceof SSLSelectorThread){
>>
>> ((SSLSelectorThread)selectorThread).setSSLImplementation(sslImplementation);
>>
>> }
>> }
>> The second if () { } is skipped, suggesting that the selectorThread is
>> not an instance of SSLSelectorThread. I printed out the object and it is
>> com.sun.enterprise.v3.services.impl.GrizzlyEmbeddedHttp_at_c63fcb6
>> which ideed does not implement SSLSelectorThread.
>> So the field is never initiatlised.
>> Henry
>>
>> On 26 Mar 2009, at 21:41, Henry Story wrote:
>>
>>> Hi,
>>>
>>> To try out the fix of bug
>>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=486
>>>
>>> I tried building GFv3 b41 from source with Grizzly 1.9.10. After a
>>> lot of simplifying I decided to try without a war, just to see what
>>> would happen if I tried to GET https://localhost:8181/index.html
>>> in the browser.
>>>
>>> So with this
>>>
>>> $ bin/asadmin list-system-properties
>>> com.sun.grizzly.ssl.auth=need
>>>
>>> Grizzly does not ask for any certificate from the client. Yet I guess
>>> it should. (unless it is asking the client for certificates with
>>> signed by specific CAs?)
>>>
>>> If I try the sslImplementation (which I know is picked up because if
>>> I put the wrong class name it throws an error)
>>>
>>> $ bin/asadmin list-system-properties
>>> org.jsslutils.extra.grizzly.clientauth=want
>>> com.sun.grizzly.ssl.auth=need
>>> org.jsslutils.extra.grizzly.acceptAnyCert=true
>>> com.sun.grizzly.ssl.sslImplementation=org.jsslutils.extra.grizzly.JSSLutilsImplementation
>>>
>>>
>>> Then after starting GF
>>>
>>> $ grep -i jss domains/domain1/logs/server.log
>>> [#|2009-03-26T20:49:00.721+0100|FINE|glassfish|org.jsslutils.extra.grizzly|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|org.jsslutils.extra.grizzly.JSSLutilsImplementation
>>> instantiated.|#]
>>> [#|2009-03-26T20:49:01.321+0100|FINE|glassfish|org.jsslutils.extra.grizzly|_ThreadID=21;_ThreadName=Thread-1;ClassName=null;MethodName=null;|org.jsslutils.extra.grizzly.JSSLutilsImplementation
>>> instantiated.|#]
>>> [#|2009-03-26T20:49:01.334+0100|FINE|glassfish|org.jsslutils.extra.grizzly|_ThreadID=22;_ThreadName=Thread-1;ClassName=null;MethodName=null;|org.jsslutils.extra.grizzly.JSSLutilsImplementation
>>> instantiated.|#]
>>>
>>> But again I don't get asked for a client certificate, and more to the
>>> point none of the org.jsslutils.extra.grizzly.JSSLutilsImplementation
>>> methods get called (they are all commented carefully).
>>>
>>> Is the expected behavior that a certificate should be requested in
>>> those cases when requesting
>>>
>>> https://localhost:8181/index.html
>>>
>>> I am trying to find out how to test that the fix is working.
>>>
>>> Also, do you have any tips on how to Bruno's ssl implementation on a
>>> grizzly by itself?
>>>
>>> Henry
>>>
>>> Blog: http://blogs.sun.com/bblfish
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>