Gemfire: Q&A on TLS certificates

Products

• VMware Tanzu Gemfire

Issue/Introduction

This article addresses common questions regarding TLS/SSL certificate management, dynamic updates, and best practices for Peer-to-Peer (P2P) and Client-Server communications in VMware Tanzu GemFire, including in AWS EC2 environments.

Environment

All supported Gemfire versions

Resolution

 

 

Q1: Is a restart required to rotate certificates on Locators and Servers?

A: No. GemFire automatically hot-reloads certificate and key files on disk when they are updated.

Q2: For P2P TLS, do we use one shared certificate or one per server?

A: One per server. Add the issuing Certificate Authority(CA) to the truststore. Sharing private keys across hosts is a security risk; distinct host certificates with CA validation prevent cluster-wide exposure.

Q3: How do we configure Client-Server TLS?

A: Trust the Certificate Authority(CA) on the client. Import the issuing CA into the client truststore rather than sharing certificates/keys.

Q4: Does setting ssl-endpoint-identification-enabled=true validate Subject Alternative Names (SANs) or Common Names (CNs)?

A: SANs first. Java checks SAN entries if present; it only falls back to the CN if no SAN exists.

AWS EC2 Note: Dynamic IPs break IP-based SANs. Use AWS internal DNS names (e.g., ip-10-x-x-x.ec2.internal) or Route 53 private hostnames in your SANs instead.