JinwooHwang opened a new pull request, #7988: URL: https://github.com/apache/geode/pull/7988
## 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: ```bash ./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 - [x] All new tests pass - [x] Code follows Geode style guidelines (spotless check passed) - [x] Comprehensive test coverage for positive and negative scenarios - [x] Documentation in test class JavaDoc - [x] No breaking changes to existing APIs - [x] 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.** <!-- Thank you for submitting a contribution to Apache Geode. --> <!-- In order to streamline review of your contribution we ask that you ensure you've taken the following steps. --> ### For all changes, please confirm: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [x] Is your initial contribution a single, squashed commit? - [x] Does `gradlew build` run cleanly? - [x] 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](http://www.apache.org/legal/resolved.html#category-a)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
