Transport SSL Verification: Full vs Certificate Mode for Dynamic Node Scaling

Question

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.

Full Mode: Requires strict SAN alignment to prevent man-in-the-middle attacks.
  Certificate Mode: Reduces configuration overhead but relaxes identity verification.

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?

Tasadduq Burney · Answer

Recommended Verification Mode

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.

Technical Comparison and Trade-offs

The primary difference lies in whether the identity of the node is tied to its network address or its cryptographic origin.

Full Verification Mode

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:

Operational Overhead: Every new node requires a unique certificate generated with the correct DNS or IP SANs before it can join.
Scaling Latency: Provisioning time increases as the automation must wait for a CA to issue a host-specific certificate.

Certificate Verification Mode

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.

Security Trade-offs in a Private VPC

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:

Network Security Groups: Restricting transport port access (typically 9300) strictly to the cluster's security group.
Private CA Control: Ensuring the CA is not accessible to general users or other services within the VPC.

Implementation Steps

To implement certificate mode for dynamic scaling, apply the following configuration to your elasticsearch.yml across all nodes:

xpack.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.p12

Verification Command

You 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.