GemFire: JMX/RMI Connection Failures with SSLHandshakeException: No Subject Alternative Name (SAN) Found

Products

• Pivotal GemFire
• VMware Tanzu Gemfire
• VMware Tanzu Greenplum / Gemfire
• VMware Tanzu Data Suite
• VMware Tanzu Data Suite
• VMware Tanzu Data Intelligence

Issue/Introduction

Applications connecting to VMware Tanzu GemFire clusters via JMX over RMI fail to establish a secure connection. This typically occurs after a client-side update (such as a Java Buildpack upgrade in Cloud Foundry).

The application logs report the following error:

javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching <hostname> found

Cause

The failure is driven by two primary factors:

1. Identity Mismatch: GemFire is configured (via  jmx-manager-hostname-for-clients) to advertise its node-specific, ephemeral hostnames. However, the SSL certificate used by the cluster is typically issued for a stable cluster alias.

2. Strict Validation: Modern Java Runtimes (JRE 11, 17, and 21+) enforce strict Endpoint Identification for RMI over SSL by default. If the advertised hostname does not appear in the certificate's Subject Alternative Name (SAN) field, the connection is rejected.

Resolution

Option 1: Align Configuration with Certificate (Recommended)

Update the GemFire cluster to advertise the identity present in the SSL certificate.

1. Identify the hostname listed in the certificate's SAN (or Common Name).

2. Update the gemfire.properties for all Locators/Managers:

   jmx-manager-hostname-for-clients=<stable-alias-on-certificate>

    

   
   

    

Option 2: Client-Side Security Bypass (Workaround)

If server-side configuration or DNS changes are not feasible, disable strict endpoint verification on the client application. Add the following properties to the application's JAVA_OPTS or JAVA_TOOL_OPTIONS:

-Djdk.rmi.ssl.client.enableEndpointIdentification=false
-Dcom.sun.jndi.rmi.object.disableEndpointIdentification=true

Option 3: Wildcard Certificate

Reissue the GemFire cluster SSL certificate to include a wildcard SAN (e.g., *.yourdomain.com) that covers the ephemeral node hostnames. This maintains high security while allowing for dynamic infrastructure scaling.