Jinwoo Hwang created GEODE-10562:
------------------------------------
Summary: Testcases — Hybrid Model (Public CA servers, Private CA
clients)
Key: GEODE-10562
URL: https://issues.apache.org/jira/browse/GEODE-10562
Project: Geode
Issue Type: Improvement
Reporter: Jinwoo Hwang
h3. Summary
Create testcases to validate the hybrid TLS model where servers (peer-to-peer)
use certificates issued by a public CA while clients authenticate using
certificates issued by an internal/private CA.
h3. Test environment / prerequisites
- Java runtime matching CI environment
- Test CA artifacts: 1) Public CA chain (root/intermediate), 2) Private CA
(root/intermediate)
- Helper scripts to create keystores and truststores (existing test tooling)
- Nodes available: at least 2 servers (peers), 1 locator, 1 client
- Ensure `ssl-keystore-type=JKS`, `ssl-truststore-type=JKS` and
`ssl-require-authentication=true` are configurable in test node properties
h2. Testcases
||Key||Summary||Preconditions||Steps||Expected Result||Priority||Notes||
|TC-HYB-001|Server trusts BOTH CAs; client uses private-CA certs (happy
path)|Servers have truststore containing both Public CA and Private CA; clients
use keystore signed by Private CA|1. Start two peer servers and a locator with
server truststore containing both CAs. 2. Start client with keystore signed by
Private CA and client auth enabled.|1. Client connects to cluster and performs
data ops (put/get).|Client successfully establishes mTLS connection and data
ops succeed.|P0|Verify server logs show peer and client TLS handshakes succeed;
assert ssl-require-authentication=true enforced|
|TC-HYB-002|Peer-to-peer server handshake uses public CA cert|Servers present
certificates signed by Public CA for peer comms|1. Each server keystore
contains server cert signed by Public CA. 2. Server truststores include Public
CA.|1. Bring up two servers and verify peer connection established.|Peer TLS
handshake succeeds (server-to-server), cluster forms; no client certificates
required for peer link.|P0|Confirm leaf server cert EKU includes serverAuth|
|TC-HYB-003|Client with public-CA certificate is rejected for clientAuth|Client
presents cert signed by Public CA (no private CA chain)|1. Servers trust both
CAs. 2. Client keystore contains cert signed by Public CA only.|1. Attempt
client connect and auth.|Client TLS handshake fails with certificate_unknown or
client auth failure; connection refused.|P1|Confirm rejection stems from
missing expected client EKU or policy requiring private-CA client certs|
|TC-HYB-004|Missing clientAuth EKU on client certificate leads to
failure|Client cert lacks clientAuth EKU even if signed by Private CA|1.
Private-CA-signed client cert missing clientAuth EKU.|1. Attempt client
connect.|TLS handshake fails with certificate_unknown or certificate rejected
due to EKU.|P1|Record JSSE exception message and server logs; include EKU
validation evidence|
|TC-HYB-005|Missing serverAuth EKU on server certificate breaks peer
connections|Server cert lacks serverAuth EKU but signed by Public CA|1. Server
cert missing serverAuth EKU exists in keystore.|1. Start servers.|Peer-to-peer
TLS handshake fails (PKIX or EKU rejection), cluster formation fails or peer
disconnects.|P1|Covers both peer and locator roles; verify explicit EKU
requirement in docs|
|TC-HYB-006|Server truststore missing public CA -> peer failure|Servers
truststore contains only Private CA (missing Public CA)|1. Configure servers to
use truststore with only Private CA.|1. Start servers.|Peer connections fail;
cluster cannot form; logs show PKIX path validation error for public-signed
server certs.|P1|Simulate misconfiguration and confirm documented
troubleshooting steps trigger|
|TC-HYB-007|Server truststore missing private CA -> client auth fails|Servers
truststore contains only Public CA (missing Private CA)|1. Servers truststore
has only Public CA.|1. Start servers. 2. Start client with Private-CA
cert.|Client TLS handshake rejects client cert (certificate_unknown); client
cannot authenticate.|P1|Verifies necessity of both CAs in server truststore for
hybrid model|
|TC-HYB-008|ssl-require-authentication=false allows anonymous client
(regression test)|Servers configured with ssl-require-authentication=false|1.
Set servers `ssl-require-authentication=false` in properties.|1. Start server.
2. Attempt client connect without presenting cert.|Client can connect without
client cert; server accepts connection and allows ops (but
insecure).|P2|Confirm this config disables mandatory clientAuth; flag as
security regression if seen in production configs|
|TC-HYB-009|Rotation: Public CA certificate renewal (servers)|Public CA cert
chain renewed; servers updated accordingly|1. Replace public CA cert in server
keystores/truststores with renewed cert.|1. Restart servers sequentially vs all
at once. 2. Verify peer links and client connections remain functional.|Cluster
remains healthy; peer TLS handshakes succeed; clients using private-CA continue
to authenticate.|P1|Include both rolling and full-restart scenarios; test
public CA rotation impact on server truststores of all nodes|
|TC-HYB-010|Rotation: Private CA certificate renewal (clients)|Private CA cert
rotated; clients updated accordingly|1. Rotate private CA root/intermediate and
issue new client certs.|1. Start servers with truststore containing both CAs
(including new private CA). 2. Start client with rotated cert.|Client
authentication succeeds; data ops succeed.|P1|Test mixed client fleet where
some clients still use old private CA (back-compat checks)|
|TC-HYB-011|SAN mismatch on server cert leads to connection rejection|Server
cert SAN does not include hostname used by peer or client|1. Server cert SAN
intentionally omits hostnames used for connections.|1. Attempt connections to
server using expected hostnames.|JSSE rejects connection due to hostname
verification or SAN mismatch (depending on config).|P2|Record behavior when
hostname verification is enabled vs disabled in Geode settings|
|TC-HYB-012|Multi-tenant: Gateway / WAN / client-to-proxy interactions|Hybrid
certificates across WAN/Gateway proxies|1. Deploy gateway sender/receiver
across data centers with hybrid TLS config.|1. Verify WAN links, gateway
receivers, and client connections across sites.|Peer links for servers use
public CA; client auth across proxies uses private CA as required; WAN
replication continues.|P2|Validate truststore propagation requirements across
DCs|
|TC-HYB-013|Negative: Expired certificates (server and client)|Expired
public/private CA leaf certs present in keystores|1. Use expired certificates
in keystores/truststores.|1. Start services and attempt connections.|TLS
handshakes fail with certificate expired errors; services should log expiry
details.|P2|Verify error messages are actionable for ops teams|
h3. Automation notes
- Each testcase should be automatable via existing Geode dunit or jUnit test
harnesses. Use helper utilities to generate keystores/truststores
programmatically.
- Parameterize cert properties: EKU flags, SAN content, validity dates, chain
order, keystore/truststore formats.
- Validate both JSSE-level exceptions and Geode log entries for accurate root
cause mapping.
h3. Acceptance criteria
- Test passes when it can be run reliably in CI and reproduces expected JSSE
and Geode behavior.
- Test must include assertions for: TLS handshake success/failure, EKU
validation results, and clear log evidence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
