GEODE-10562: Testcases for Hybrid CA TLS Configuration Test Suite

[JinwooHwang]

Overview

This PR introduces comprehensive test coverage for the Hybrid CA TLS Configuration, which addresses the upcoming public CA clientAuth EKU sunset problem in Apache Geode.

Problem Statement

Public Certificate Authorities are phasing out support for the clientAuth Extended Key Usage (EKU) in publicly-issued certificates. This creates significant challenges for Geode deployments:

1. Mutual TLS with public CAs requires both server and client certificates with appropriate EKUs
2. Public CAs will no longer issue certificates with clientAuth EKU
3. Existing clusters using mutual TLS with public CA certificates face certificate renewal issues
4. Organizations need a migration path that allows continued use of public CA certificates

Solution: Hybrid CA Configuration

The Hybrid CA approach allows organizations to:

• Use public CA certificates for servers (e.g., Let's Encrypt, DigiCert)
• Use private/enterprise CA certificates for clients
• Maintain full mutual TLS with certificate-based authentication
• Avoid the public CA clientAuth EKU limitation

Architecture

Server Configuration:

• Certificate from public CA with serverAuth EKU only
• Truststore includes private CA (to validate client certificates)

Client Configuration:

• Certificate from private/enterprise CA with clientAuth EKU
• Truststore includes public CA (to validate server certificates)

Peer-to-Peer Communication:

• All cluster members (locators, servers) use public CA certificates
• Certificate validation enforces cryptographic membership

Changes in This PR

1. Test Infrastructure (HybridCATestFixture.java)

New test fixture providing:

• Separate public and private CA generation
• Public CA certificate creation (simulating Let's Encrypt, DigiCert, etc.)
• Private/enterprise CA certificate creation for clients
• Proper truststore and keystore configuration for hybrid scenarios
• Helper methods for creating locator, server, and client certificate stores
• Support for both client-server and peer-to-peer configurations

2. Positive Test Suite (HybridCASSLDUnitTest.java)

Comprehensive validation of hybrid CA scenarios:

• Client-server connections with hybrid CA certificates
• Multiple concurrent clients with private CA certificates
• Peer-to-peer cluster communication with public CA certificates
• Mutual TLS enforcement (both server and client certificate validation)
• Certificate chain validation and trust verification
• Data operations across client-server and P2P topologies

Test Methods:

• testClientServerWithHybridCA - Basic client-server connection
• testMultipleClientsWithHybridCA - Concurrent client connections
• testP2PClusterWithPublicCAAndClientServerWithHybridCA - Full cluster topology

3. Negative Test Suite (HybridCASSLNegativeTest.java)

Security validation ensuring proper rejection of invalid configurations:

• Clients without valid private CA certificates rejected
• Servers with missing public CA rejected by clients
• Certificate chain validation failures detected
• Untrusted CA certificates properly rejected
• Missing EKU requirements detected
• Mixed/misconfigured trust relationships fail appropriately

Test Methods:

• testClientWithoutPrivateCAFails - Client missing private CA certificate
• testClientWithPublicCACertificateFails - Client using wrong CA
• testServerWithMissingPublicCARejected - Server trust validation
• Additional negative scenarios validating security boundaries

4. Certificate Builder Enhancement (CertificateBuilder.java)

Updates to support hybrid CA scenarios:

• Enhanced EKU specification for different certificate types
• Proper subjectAltName generation for server certificates
• Support for custom CA certificate chains
• Hostname/IP validation requirements

Test Coverage Summary

Test Class	Test Methods	Coverage
HybridCASSLDUnitTest	3	Positive scenarios
HybridCASSLNegativeTest	4+	Security validation
Total	7+	Comprehensive

Key Findings

Proven Capabilities

1. Hybrid CA Works: Servers with public CA certificates can authenticate clients with private CA certificates
2. Mutual TLS Maintained: Full certificate-based authentication preserved
3. P2P Compatible: Peer-to-peer clusters function with public CA certificates
4. Trust Boundaries Clear: Separate trust domains properly isolated
5. Security Enforced: All negative cases properly rejected

Technical Requirements

Server Certificates (Public CA):

• Must include serverAuth EKU
• Must include subjectAltName with hostname/IP
• Signed by public CA trusted by clients

Client Certificates (Private CA):

• Must include clientAuth EKU
• Signed by private CA trusted by servers

Server Truststore:

• Must include public CA (for peer-to-peer validation)
• Must include private CA (for client validation)

Client Truststore:

• Must include public CA (for server validation)

Security Considerations

Advantages:

• Cryptographic membership enforcement maintained at handshake level
• No changes to authentication/authorization model
• Public CA certificates remain viable for servers
• Private CA provides full control over client certificates

Requirements:

• Private CA must be properly managed and secured
• Certificate rotation processes must handle both CAs
• Monitoring should track certificate expiration for both domains

Migration Path

Existing clusters can migrate to hybrid CA configuration by:

1. Generate private CA for client certificates
2. Update server truststores to include private CA
3. Issue new client certificates from private CA with clientAuth EKU
4. Update client configurations with new certificates
5. Continue using public CA for server certificates (serverAuth EKU only)
6. Rotate certificates as needed without public CA clientAuth dependency

Files Changed

A  geode-core/src/distributedTest/java/org/apache/geode/cache/ssl/HybridCASSLDUnitTest.java
A  geode-core/src/distributedTest/java/org/apache/geode/cache/ssl/HybridCASSLNegativeTest.java
M  geode-junit/src/main/java/org/apache/geode/cache/ssl/CertificateBuilder.java
A  geode-junit/src/main/java/org/apache/geode/cache/ssl/HybridCATestFixture.java

Total: 3 new files, 1 modification

Testing

All tests pass successfully:

./gradlew :geode-core:distributedTest --tests "HybridCASSL*" --max-workers=1
./gradlew spA  # Spotless formatting check

Related Documentation

This work supports the TLS migration guide and addresses:

• Public CA clientAuth EKU sunset mitigation
• Hybrid TLS architecture patterns
• Certificate management best practices
• Security model preservation with mixed CA environments

Related Issues

• GEODE-10562: Hybrid CA TLS Configuration Tests
• Related to GEODE-10563: Server-Only TLS with Application-Layer Authentication

Comparison with Alternative Approaches

Approach 1: Mutual TLS

• Requires clientAuth EKU from CAs

Approach 2: Hybrid CA (GEODE-10562)

• Maintains mutual TLS and cryptographic enforcement
• Public CA for servers (serverAuth only)
• Private CA for clients (clientAuth)
• Best for organizations requiring certificate-based authentication

Approach 3: Server-Only TLS (GEODE-10563)

• Eliminates client certificates entirely
• Application-layer authentication instead
• Best for organizations prioritizing operational simplicity

Checklist

• All new tests pass
• Code follows Geode style guidelines (spotless check passed)
• Comprehensive test coverage for positive and negative scenarios
• Documentation in test class JavaDoc
• No breaking changes to existing APIs
• Security validation thorough

---

This PR provides the test foundation proving that Hybrid CA TLS Configuration is a viable solution for addressing the public CA clientAuth EKU sunset while maintaining cryptographic membership enforcement.

For all changes, please confirm:

• Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
• Has your PR been rebased against the latest commit within the target branch (typically develop)?
• Is your initial contribution a single, squashed commit?
• Does gradlew build run cleanly?
• Have you written or updated unit tests to verify your changes?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?