Description of problem: See bz1277389 To fix the bz1277389 rhq.server.tomcat.security.secure-socket-protocol was set to TLSv1,TLSv1.1,TLSv1.2 When you try to set the same list of protocols to other some secure-socket-protocol properties it will fail. Following properties are in both rhq-server.properties and in agent-configuration.xml: rhq.communications.connector.security.secure-socket-protocol rhq.server.client.security.secure-socket-protocol when you set those to any list e.g. TLSv1,TLSv1.1,TLSv1.2 it will fail with Caused by: java.io.IOException: Error creating server socket factory SSL context: TLSv1,TLSv1.1 SSLContext not available Version-Release number of selected component (if applicable): JON3.3.5.ER01 How reproducible: Always Steps to Reproduce: 1. set rhq.communications.connector.security.secure-socket-protocol or rhq.server.client.security.secure-socket-protocol in rhq-server.properties or agent-configuration.xml to TLSv1,TLSv1.1,TLSv1.2 2. start server 3. start agent using --cleanconfig Actual results: server.log: 02:27:41,791 ERROR [org.rhq.enterprise.communications.command.client.ClientCommandSenderTask] (http-/0.0.0.0:7443-2) {ClientCommandSenderTask.send-failed}Failed to send command [Command: type=[remotepojo]; cmd-in-response=[false]; config=[{rhq.timeout=10000, rhq.send-throttle=true}]; params=[{invocation=NameBasedInvocation[ping], targetInterfaceName=org.rhq.enterprise.communications.Ping}]]. Cause: java.lang.reflect.InvocationTargetException:null -> java.lang.RuntimeException:Unable to create customized SSL socket factory -> java.io.IOException:Error creating socket factory SSL context: TLSv1,TLSv1.1,TLSv1.2 SSLContext not available. Cause: java.lang.reflect.InvocationTargetException agent: Caused by: java.io.IOException: Error creating server socket factory SSL context: TLSv1,TLSv1.1 SSLContext not available Expected results: It should be possible to use a list of protocols to follow behavior of rhq.server.tomcat.security.secure-socket-protocol
I think this was intentional on BZ 1277389 to leave these two settings alone and to TLS value instead of changing protocol names on the other parameters also. The implementation is different on the agent-side and the value is passed to SSLContext to get the protocol. And as you noticed, it does not allow such list to be given as parameter.
@Filip, I'm not sure if that range of settings is actually appropriate for other properties. Larry did a fair amount of work determining that the changes only needed to happen for "rhq.server.tomcat.security.secure-socket-protocol". Putting a needinfo on him to comment further here.
Comment 1 and comment 2 are correct. RHQ uses a different implementation for SSL when using sslsocket. It is based on an out-dated example that utilizes SSLContext. Not only does this not support a list of protocols, it also does not really support a protocol at all. Instead, its protocol is more like a protocol family or highest version preference. When we discussed the fix for BZ 1277389 it originally identified these properties as needing updating as well. However, that would require the underlying socket implementation for sslsocket to be rewritten. The risk involved in such a change was too great for the maintenance stream. Therefore this is not a bug. The only property set that supports the actual protocol list are the Tomcat specific properties. @Filip my recommendation is to update/document the test case and close this BZ as not a bug.
Based on previous comments closing as not a bug
Re-opening for 3.3.6, it appears that unless you explicitly set rhq.communications.connector.security.secure-socket-protocol to TLS on the agent configuration, don't let it use the default, which appears to be TLSv1,TLSv1.1,TLSv1.2 with the 3.3.6 update. You will receive the same error in the description when trying to start the agent: 2016-08-01 13:03:27,818 FATAL [main] (org.rhq.enterprise.agent.AgentMain)- {AgentMain.startup-error}The agent encountered an error during startup and must abort java.io.IOException: Error creating server socket factory SSL context: TLSv1,TLSv1.1,TLSv1.2 SSLContext not available at sun.security.jca.GetInstance.getInstance(GetInstance.java:159) at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) at org.jboss.remoting.security.SSLSocketBuilder.createServerSocketFactorySSLContext(SSLSocketBuilder.java:1197) at org.jboss.remoting.security.SSLSocketBuilder.createCustomServerSocketFactory(SSLSocketBuilder.java:385) at org.jboss.remoting.security.SSLSocketBuilder.createSSLServerSocketFactory(SSLSocketBuilder.java:366) at org.jboss.remoting.security.SSLSocketBuilder.createSSLServerSocketFactory(SSLSocketBuilder.java:345) at org.jboss.remoting.security.SSLServerSocketFactoryService.start(SSLServerSocketFactoryService.java:61) at org.rhq.enterprise.communications.ServiceContainer.initializeSecurityServices(ServiceContainer.java:1393) at org.rhq.enterprise.communications.ServiceContainer.setupServerConnector(ServiceContainer.java:1240) at org.rhq.enterprise.communications.ServiceContainer.start(ServiceContainer.java:596) at org.rhq.enterprise.communications.ServiceContainer.start(ServiceContainer.java:514) at org.rhq.enterprise.agent.AgentMain.startCommServices(AgentMain.java:2542) at org.rhq.enterprise.agent.AgentMain.start(AgentMain.java:715) at org.rhq.enterprise.agent.AgentMain.main(AgentMain.java:461) 2016-08-01 13:03:27,819 INFO [main] (org.rhq.enterprise.agent.AgentMain)- {AgentMain.shutting-down}Agent is being shut down...
Just to avoid confusion the original description of this bz was correctly closed as not a bug - TLSv1,TLSv1.1,TLSv1.2 is NOT expected to work. Reason for reopening is described in comment 5. Workaround for the issue is to set rhq.communications.connector.security.secure-socket-protocol explicitly to TLS which can be done following way: echo "setconfig rhq.communications.connector.security.secure-socket-protocol=TLS" | "${RHQ_AGENT_HOME}/bin/rhq-agent.sh" --nostart
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-1785.html