Question
Transport SSL Verification: Full vs Certificate Mode for Dynamic Node Scaling
Ash Sage
0 reputation · 20 Oct 2025, 14:09 UTC
64.7K views1
Loading…
0 reputation · 20 Oct 2025, 14:09 UTC
When configuring node-to-node communication in Elasticsearch (version 8.x), the xpack.security.transport.ssl.verification_mode setting determines how certificates are validated during the SSL handshake. The goal is to maintain a secure transport layer while allowing the cluster to scale across dynamic infrastructure where hostnames may change or be assigned programmatically.
Using full verification ensures the highest security by validating both the certificate chain and the hostname via Subject Alternative Names (SANs). However, this requires precise certificate issuance for every new node. Conversely, certificate mode validates the trust chain but bypasses the hostname check, simplifying deployment in environments with fluid network identities.
Which verification mode is more sustainable for a cluster utilizing auto-scaling groups where nodes are frequently replaced? What are the specific security trade-offs when opting for certificate mode over full in a private VPC?
35275 reputation · 20 Oct 2025, 20:13 UTC
For a cluster utilizing auto-scaling groups where nodes are frequently replaced, certificate mode is generally more sustainable. It allows new nodes to join the cluster as long as they possess a certificate signed by the trusted Certificate Authority (CA), without requiring the precise Subject Alternative Name (SAN) or hostname to be pre-registered or perfectly aligned with the dynamic network identity assigned by the cloud provider.
The primary difference lies in whether the identity of the node is tied to its network address or its cryptographic origin.
In full mode, Elasticsearch validates the entire certificate chain and ensures the hostname used to connect matches the SANs listed in the certificate. While this is the gold standard for security, it creates significant friction in dynamic environments:
In certificate mode, the node validates that the certificate is signed by a trusted CA but skips the hostname verification step. This decouples the security of the transport layer from the volatility of the infrastructure.
Opting for certificate mode over full introduces a specific risk: Internal Impersonation. If an attacker gains the ability to issue a certificate from your internal CA or steals a valid node certificate, they could potentially spoof a cluster node. Because hostname verification is disabled, the cluster will accept any certificate signed by the CA, regardless of which node it was originally issued to.
In a private VPC, this risk is typically mitigated by:
To implement certificate mode for dynamic scaling, apply the following configuration to your elasticsearch.yml across all nodes:
elasticsearchxpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: transport.p12
xpack.security.transport.ssl.truststore.path: transport.p12You can verify that the CA is trusted independently of the hostname using openssl from one node to another:
openssl s_client -connect <node-ip>:9300 -CAfile <your-ca-cert>A successful handshake (Return code 0) confirms the trust chain is valid, which is the only requirement for certificate mode.
Diagnostic Detail Needed: Are you using a shared internal CA across the entire VPC, or is each auto-scaling group using a separate intermediate CA? If the latter, the truststore configuration must be updated to include all relevant intermediate roots.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 20 Oct 2025, 18:18 UTC
For clusters with short-lived nodes, parsing startup logs is unreliable. Query GET _nodes/ssl to confirm the active verification_mode per node. In certificate mode, monitor certificate expiration, because a lapsed node certificate causes transport handshake failures that are easy to misdiagnose as network issues.