Enable TLS for Elasticsearch

The fix/etc/elasticsearch/elasticsearch.yml

xpack.security.http.ssl:
  enabled: true
  keystore.path: certs/http.p12

xpack.security.transport.ssl:
  enabled: true
  keystore.path: certs/transport.p12
  truststore.path: certs/transport.p12
  verification_mode: certificate

On 8.x and 9.x, auto-configuration writes exactly this on first start. The work here is usually not undoing it and getting clients to trust the CA.

Why it matters

Elasticsearch has two TLS layers, and they protect different things:

• Transport TLS (9300) encrypts and authenticates traffic between nodes — replication, cluster state, the actual documents moving around. Without it, a multi-node cluster gossips your entire dataset across the network in plaintext, and — worse — any host that can reach 9300 can attempt to join the cluster and be handed data.
• HTTP TLS (9200) encrypts the client-to-cluster API, including the authentication credentials on every request.

Without either, the network sees everything. And Elasticsearch’s own authentication is undermined by plaintext HTTP: the credentials it checks are sent in the clear on the way in.

Transport TLS is not optional on a multi-node cluster

This is the part that isn’t a hardening nicety — it’s a requirement.

With security enabled, Elasticsearch will not form a multi-node cluster without transport TLS. The nodes must authenticate to each other, and certificate-based transport authentication is how. A cluster with security on and transport TLS off either refuses to start or the nodes never join.

So on a real cluster you are not choosing whether to enable transport TLS — you’re choosing whether to enable it correctly. verification_mode: certificate (the auto-config default) checks that the presented certificate is signed by your CA; full additionally checks the hostname. certificate is the pragmatic choice because node IPs change; full is stricter if your node names are stable.

8.x/9.x did this for you — don’t undo it

The single most common TLS “problem” on modern Elasticsearch is a client that won’t connect because it doesn’t trust the auto-generated CA, and the “fix” someone applies is to disable TLS or security entirely.

The auto-generated CA is at a known path:

/etc/elasticsearch/certs/http_ca.crt

Point clients at it rather than turning the encryption off:

curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic https://localhost:9200/

For applications, distribute that CA certificate and configure the client to trust it. That’s the correct fix — the certificate being self-signed is not a reason to disable TLS, it’s a reason to install the CA.

7.x is manual

On 7.x, none of this is automatic. You generate certificates with elasticsearch-certutil and configure both xpack.security.transport.ssl and xpack.security.http.ssl by hand. It’s more work, it’s well documented, and it’s another reason to be on 8.x or 9.x — the auto-configuration removed the step people most often skipped.

Verify it worked

Confirm both layers are on:

curl -sk -u elastic https://localhost:9200/_nodes/_local/settings?filter_path='**.ssl.enabled'

Prove HTTP TLS works and plaintext doesn’t:

curl -s http://localhost:9200/ -o /dev/null -w 'plaintext: %{http_code}\n'    # expect failure/000
curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic \
  https://localhost:9200/ -o /dev/null -w 'tls: %{http_code}\n'               # expect 200

Inspect the presented certificate independently of the client:

openssl s_client -connect localhost:9200 </dev/null 2>/dev/null | openssl x509 -noout -subject -enddate

Check the transport port is doing TLS too — a plaintext transport handshake should get nowhere:

openssl s_client -connect localhost:9300 </dev/null 2>&1 | grep -E 'Verify|Cipher|no peer'

And confirm certificate expiry now, not later:

curl -sk -u elastic https://localhost:9200/_ssl/certificates?filter_path='*.expiry,*.path' 2>/dev/null

That last endpoint lists every certificate the node loaded and when each expires — the cheapest way to avoid the outage below.

Before you apply this

Certificate expiry takes the whole cluster down, and not gracefully — nodes refuse to talk to each other and clients refuse to connect. The auto-generated certificates have finite lifetimes, and a cluster that “suddenly stopped forming” after months of working is often an expired transport CA.

The _ssl/certificates endpoint above is your early-warning system. Put a check on it, because unlike a web server where an expired cert is one visible error, here it’s a cluster-wide failure with a confusing signature.

Rotating certificates on a running cluster is delicate. Nodes must trust the new CA before the old certificates are replaced, which means a rolling update with both CAs trusted during the transition. Doing it in the wrong order partitions the cluster. Plan it; don’t improvise it under an expiry deadline — which is the argument for watching expiry rather than reacting to it.

Disabling TLS to “fix” a client is the trap this page exists to prevent. If a client can’t connect, install the CA (http_ca.crt) into its trust store. Turning off verification_mode, or setting it to none, or disabling TLS, each gives up exactly the protection you configured — and on the transport layer, verification_mode: none means any host can join your cluster and be handed your data.

Related

• Enable security — security and TLS are configured together.
• Bind to a private interface — the transport port TLS protects.