[jboss-jira] [JBoss JIRA] (WFLY-10795) Non-Elytron SSL configuration won't establish secure channel between worker and balancer

Non-Elytron SSL configuration won't establish secure channel between worker and balancer ---------------------------------------------------------------------------------------- Key: WFLY-10795 URL: https://issues.jboss.org/browse/WFLY-10795 Project: WildFly Issue Type: Bug Components: mod_cluster Affects Versions: No Release Environment: Latest snapshot from ci.wildfly.org Reporter: Jan Kašík Assignee: Radoslav Husar Priority: Blocker Fix For: 14.0.0.CR1 Attachments: confs.zip When running scenario, where connection between worker and balancer is secured with SSL, worker fails to register on balancer. Worker obviously tries to send INFO commands, though it sends it as a 'plain text' to a secured channel. I enabled SSL debugging, and such unsecured-secured communication causes this error: {code} 09:42:20,456 INFO [stdout] (default I/O-4) Using SSLEngineImpl. 09:42:20,458 INFO [stdout] (default I/O-4) Allow unsafe renegotiation: false 09:42:20,458 INFO [stdout] (default I/O-4) Allow legacy hello messages: true 09:42:20,458 INFO [stdout] (default I/O-4) Is initial handshake: true 09:42:20,459 INFO [stdout] (default I/O-4) Is secure renegotiation: false 09:42:20,459 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1 09:42:20,479 INFO [stdout] (default I/O-4) default I/O-4, fatal error: 80: problem unwrapping net record 09:42:20,480 INFO [stdout] (default I/O-4) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection? 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, SEND TLSv1.2 ALERT: fatal, description = internal_error 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, WRITE: TLSv1.2 Alert, length = 2 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, called closeInbound() 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack? 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, called closeOutbound() 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, closeOutboundInternal() {code} What bothers me, that there are no other errors (bad certificate, CLI error...) in log regarding this. Apart from: {code} 09:45:42,653 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p14-t16) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 6 from wildfly-14.0.0.Beta2-SNAPSHOT-2 at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167) at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87) at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Suppressed: org.infinispan.util.logging.TraceException at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75) at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525) at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508) at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:321) at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:87) at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:731) at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175) at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:37) at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:227) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47) ... 1 more {code} Configuration using non-Elytron configuration was possible before, hence this is a regression.