Question
Cassandra Internode TLS: DNS Mismatch When require_endpoint_verification is True
Kavi Echo
0 reputation · 14 Feb 2025, 19:34 UTC
25.3K views
Loading…
0 reputation · 14 Feb 2025, 19:34 UTC
Diagnose SSL handshake failures that arise when Cassandra nodes connect using IP addresses while the peer’s TLS certificate lists only DNS names.
The cluster runs with require_endpoint_verification=true to enforce hostname checks, but nodes are configured with listen_address or broadcast_address as static IPs. This mismatch triggers javax.net.ssl.SSLHandshakeException during inter‑node communication.
Operators must decide whether to keep strict verification (risking operational disruption) or relax it (exposing the cluster to man‑in‑the‑middle attacks if a CA‑signed certificate is compromised).
require_endpoint_verification enabled?require_endpoint_verification affect the cluster’s security posture in a mixed IP/DNS environment?ssl_endpoint_identification_algorithm) to allow hostname verification against a custom mapping without disabling the feature?32275 reputation · 15 Feb 2025, 01:19 UTC
When require_endpoint_verification=true Cassandra performs JSSE hostname verification against the address used for internode traffic (listen_address or broadcast_address). If that address is an IP and the peer’s certificate contains only DNS names in its SAN/CN, the verification fails with SSLHandshakeException.
cassandrarequire_endpoint_verification removes hostname checks, allowing any valid cert to be accepted, which opens a man‑in‑the‑middle risk if a CA‑signed certificate is compromised.ssl_endpoint_identification_algorithm option only accepts standard JSSE algorithms (e.g., "HTTPS", "LDAP") or an empty string; it does not support a custom IP‑to‑hostname map. Setting it to empty disables identification, equivalent to require_endpoint_verification=false.listen_address and broadcast_address on each node to the hostname that exists in the certificate’s SAN/CN.IPAddress SAN matching the node’s listen_address/broadcast_address. Reload the keystore/truststore and restart the node.system.log that SSL handshake messages appear without SSLHandshakeException. Optionally enable -Djavax.net.debug=ssl,handshake to see the hostname being checked.Can you change listen_address/broadcast_address to use the DNS name already present in the certificate, or would you prefer to add an IPAddress SAN to the certificate? This determines whether you adjust node configuration or re‑issue certs.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.