[
https://issues.apache.org/jira/browse/GEODE-10562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinwoo Hwang updated GEODE-10562:
---------------------------------
Affects Version/s: 2.0.0
> 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
> Affects Versions: 2.0.0
> Reporter: Jinwoo Hwang
> Assignee: Jinwoo Hwang
> Priority: Major
>
> 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)
