[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487327#comment-17487327
]
Jacob Barrett commented on GEODE-10015:
---------------------------------------
This issue was introduced in
[55921a4d7b66a51279e71d1a665dc797fcc8ca6f|https://github.com/apache/geode/commit/55921a4d7b66a51279e71d1a665dc797fcc8ca6f].
When {{SocketCreator}} would configuration the SNI entries it used to convert
IP addresses into canonical host names. This was removed to better support
managed environments with strict usage of bind addresses. Restoring this
behavior might introduce other issues in these scenarios.
The IP address seems to be coming the RMI registry. The solution will require
fixing how those entries are created so they use the bind address of the JXM
service.
> gfsh does not send hostname in SNI header
> -----------------------------------------
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
> Affects Versions: 1.15.0, 1.16.0
> Reporter: Jacob Barrett
> Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=********
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST <main> tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
