Hi Isart,
thanks.
In order to contribute, you need to sign the OCA [1]. After that, I can
accept (or work with) your change. It can be attached to an issue as a
patch file, or as link to github pull request, gist or basically
anything which can describe code changes.
Thanks!
Pavel
[1]
http://www.oracle.com/technetwork/community/oca-486395.html
On 17/10/14 12:19, Isart Canyameres wrote:
> Hi Pavel,
>
> Thank you for your answer.
>
> I've created some requests to the jira site:
> https://java.net/jira/browse/TYRUS-388
> https://java.net/jira/browse/TYRUS-389
>
> I'm planning to submit a patch fixing the first one in the following
> hours. Is there any protocol for contributing I must be aware of?
>
> I'm not confident enough to fix the second one, so I'd left that to
> you whenever you have the time.
>
> Regards,
> Isart
>
>
> El 15/10/14 a les 15:43, Pavel Bucek ha escrit:
>> Hi Isart,
>>
>> you can influence the protocol by calling method
>> SslContextConfigurator.setSecurityProtocol(...) [1] with "TLSv1.2"
>> as a parameter (when dealing with Tyrus client - ClientManager -
>> SSL configuration).
>>
>> Answer to your second question is no; standalone server does not
>> currently support SSL configuraiton, you'll need to modify the
>> sources and somehow let the ServerContainerFactory to know about
>> where to find it, or invoke that directly. The first post you
>> linked says what needs to be done. There might be additional work
>> required for Grizzly (you would need to do something similar as we
>> currently do for Grizzly client - transform Tyrus Ssl*Configurator
>> classes to Grizzly alternatives).
>>
>> Feel free to create new enhancement request at [2] (or maybe
>> consider contributing if you can).
>>
>> Thanks and regards, Pavel
>>
>> [1]
>> https://tyrus.java.net/apidocs/1.8.3/org/glassfish/tyrus/client/SslContextConfigurator.html#setSecurityProtocol(java.lang.String)
>>
>> [2] https://java.net/jira/browse/TYRUS
>>
>>
>> On 15/10/14 15:15, Isart Canyameres wrote:
>>> Hi again, I noticed that web browsers issue a ClientHello with
>>> every supported protocol (included TLSv1) as part of the
>>> negotiation process:
>>>
>>> *** ClientHello, TLSv1.2 *** ClientHello, TLSv1.1 ***
>>> ClientHello, TLSv1 *** ClientHello, SSLv3
>>>
>>> Being that the case, the error I'm experimenting can't be caused
>>> by TLS protocol version.
>>>
>>> Thus, instead of knowing how to configure SSL to support TLSv1,
>>> TLSv1.1 and TLSv1.2, the important question for me now is how to
>>> specify SSL configuration to the server. Is it enough to
>>> configure desired keystore using System Properties?
>>>
>>> Thank you again, Isart
>>>
>>> El 15/10/14 a les 14:57, Isart Canyameres ha escrit:
>>>> Hello,
>>>>
>>>> I'm using a standalone server to expose some WSS endpoints.
>>>>
>>>> Looking at the archives, I found following explanation and
>>>> successfully crafted suggested hack in order to enable WSS in
>>>> the standalone server:
>>>> https://java.net/projects/tyrus/lists/users/archive/2014-02/message/1
>>>>
>>>>
>>>>
> That done, I though about configuring SSL properties by passing
>>>> an SslContextConfigurator to the server just as if it was a
>>>> client:
>>>> https://tyrus.java.net/documentation/1.8.3/user-guide.html#d0e1128
>>>>
>>>>
> However, reviewing
>>>> org.glassfish.tyrus.container.grizzly.server.GrizzlyServerContainer
>>>>
>>>>
> source code I've been unable to find the place where it may read such
>>>> SslContextConfigurator. Am I looking at the right place?
>>>>
>>>>
>>>> Although it may be ignoring given SslContextConfigurator, by
>>>> configuring System Properties with desired keystore and its
>>>> password, the server is able to successfully stablish a wss
>>>> session with correctly configured
>>>> org.glassfish.tyrus.client.ClientManager.
>>>>
>>>> However SSL handshake fails when trying to stablish a session
>>>> using websocket implementations of common browsers. It reports
>>>> javax.net.ssl.SSLHandshakeException: no cipher suites in
>>>> common
>>>>
>>>> Looking at log output, one can identify that ClientManager
>>>> uses TLSv1, while browsers native websocket implementation
>>>> issue ClientHello messages specifying TLSv1.2 or TLSv1.1
>>>> (depending on the browser).
>>>>
>>>> Is it possible to configure the server to use these versions?
>>>>
>>>> Many thanks,
>>>>
>>>> Isart
>>>>