Bug 1301970
| Summary: | Some secure-socket-protocol properties are not ready for list of protocols | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Operations Network | Reporter: | Filip Brychta <fbrychta> |
| Component: | Communications Subsystem | Assignee: | Simeon Pinder <spinder> |
| Status: | CLOSED ERRATA | QA Contact: | Filip Brychta <fbrychta> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | JON 3.3.6 | CC: | dsteigne, fbrychta, loleary, mfoley, spinder, stianlund+bugzilla |
| Target Milestone: | ER01 | Keywords: | Reopened, Triaged |
| Target Release: | JON 3.3.7 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-08-31 16:59:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Filip Brychta
2016-01-26 13:12:04 UTC
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 |