-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
False
-
None
-
False
-
-
-
-
-
-
-
Currently the IP address of the server used for the Server Name Indication (SNI) during the handshake. In setups with multiple virtual severs on the same IP the handshake might fail.
3. Server Name Indication
TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting. It may be desirable for clients to provide this information to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address…
and
… "HostName" contains the fully qualified DNS hostname of the server, as understood by the client…
and
… Literal IPv4 and IPv6 addresses are not permitted in "HostName”…
Source: https://datatracker.ietf.org/doc/html/rfc6066#page-6
In our setup we use a single Apache httpd to load balance several virtual servers with different DNS records, so when the client uses the IP address of the Apache load balancer during the handshake, the Apache server doesn’t know which virtual server the client is attempting to connect to and the connection is dropped by Apache during the handshake.
So far we have worked around the issue by patching the HttpConnectionPool to use the hostname instead IP when creating connections. This of course breaks the HostPool in setups where multiple IPs serve a single DNS, but in our case that's not an issue.
- clones
-
WEJBHTTP-74 The http ejb client should use the servers hostname for the TLS SNI extension during handshake
- Closed
- is incorporated by
-
JBEAP-24182 (7.4.z) Upgrade wildfly-http-ejb-client from 1.1.13.SP1-redhat-00001 to 1.1.16.Final-redhat-00002
- Closed