[Apologies, I'm reposting this after the first attempt bounced back from
the list (my fault).]
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. 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.
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.
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().
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>)
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,
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
>>
>