The shortest possible answer: TLS is the standard way to encrypt and authenticate network traffic, and Elasticsearch uses it to protect both node-to-node traffic and client-to-cluster traffic.

Let us build the definition slowly. Elasticsearch is a search and analytics engine. Companies use it to search products, explore application logs, count events, and draw charts. It usually runs as a cluster, which is a team of servers, called nodes, that share the work and the data. The nodes talk to each other all day long, and applications talk to the nodes to store and find data.

TLS stands for Transport Layer Security. It is a set of rules that two computers follow to talk safely over a network. It is the same technology that puts the little padlock in your web browser when you visit a bank. It is the successor of an older protocol called SSL, and people still say “SSL” out of habit, which is why Elasticsearch settings contain the word ssl even though modern TLS is what actually runs.

TLS gives three promises. The first is confidentiality: nobody in the middle can read the messages. The second is integrity: nobody in the middle can change a message without being noticed. The third is authentication: each side can check that the other side really is who it claims to be.

A small confusing coincidence

Here is a detail that trips up almost every beginner. The T in TLS stands for “transport,” and Elasticsearch also has something it calls the transport layer. These are two different uses of the same word. In TLS, “transport layer” is a general networking term for the level of the network stack where reliable connections live. In Elasticsearch, the “transport layer” is a specific communication channel that the nodes of a cluster use to talk to each other. TLS can protect the Elasticsearch transport layer, and it can also protect the other channel Elasticsearch has, the HTTP layer. Chapter 4 explains both channels in detail.

What TLS is not

TLS protects data only while it travels. It does not encrypt the files on the disk of a node, which is a different topic called encryption at rest. It does not decide who is allowed to read which index, which is called authorization. It does not replace passwords or API keys for users. It is one important layer in a stack of protections, and Chapter 7 shows exactly where its job ends.

Where you will meet it

You will meet TLS the first time you start a modern Elasticsearch node and see a generated password and a security notice. You will meet it again when Kibana asks for an enrollment token, when a Beats agent complains about an unknown certificate authority, when a load balancer must be configured to reach the cluster, and when a certificate expires and a node refuses to rejoin the cluster. In every case, understanding the few ideas in this guide turns a mysterious error into a simple checklist.

A network is a shared space. Anyone with the right access can listen, copy, or interfere. TLS exists because trusting the network is not safe.

Data inside an Elasticsearch cluster is often valuable and sometimes private: customer records, payment events, health notes, security logs, business secrets. When a node sends a piece of that data to another node, the message travels through switches, routers, virtual networks, and sometimes across data centers or cloud regions. Every hop is a place where something can go wrong.

Four dangers on an open network

• Eavesdropping. Someone who can watch the traffic reads it. This can be an attacker who broke into one machine on the network, a curious insider, or a misconfigured cloud setting that copies traffic to the wrong place.
• Tampering. Someone changes a message on the way, for example altering a search result or a piece of data being copied to another node.
• Impersonation. Someone pretends to be a trusted server or a trusted client. A client might send its password to a fake server that looks like the real one.
• Rogue nodes. Someone starts their own Elasticsearch node, points it at your cluster, and asks to join. If joining is not protected, the cluster may happily copy data onto the stranger’s machine.

The rogue node problem is special

Elasticsearch is designed so that a new node can join a cluster and receive copies of the data called shards. A shard is one slice of an index, and an index is a big labeled cabinet of documents. If any machine on the network could join freely, it could simply ask for the data. Transport layer TLS solves this by requiring each joining node to show a certificate signed by an authority the cluster trusts. A stranger without a proper certificate is turned away at the door, even before passwords or roles are considered.

An illustrative story

Rules and expectations

Beyond attackers, there are also rules. Many industries require encryption of data in transit: payment card standards, health privacy laws, financial regulations, and internal company policies. Auditors ask a simple question: “Is traffic between your servers encrypted?” Elasticsearch with TLS lets you answer yes with evidence.

A short history

In older versions of Elasticsearch, security features were a separate, paid add-on, and many clusters ran wide open. Over time, basic security, including TLS, moved into the free tier, and modern versions turn security on automatically for a newly installed node and generate certificates for you. The design goal shifted from “security is optional” to “security is the default, and you must work to turn it off.”

To follow the rest of this guide you need seven simple ideas: encryption, key, certificate, certificate authority, handshake, transport layer, and HTTP layer.

Two kinds of keys, working together

TLS uses a clever trick called public-key cryptography. Each server has a pair of mathematically linked keys. Whatever the public key locks, only the private key can unlock, and whatever the private key signs, the public key can verify. The public key goes inside the certificate for everyone to see. The private key stays secret on the server. This pairing lets two strangers set up a shared secret over an open network without ever sending the secret itself.

After the handshake, TLS switches to a much faster kind of encryption that uses one shared secret key for both sides, called symmetric encryption. The heavy public-key math is used only at the start, and the fast symmetric lock protects the rest of the conversation.

What a certificate contains

A certificate is a small file of labeled facts. It contains the name of its owner, which for servers is a host name or an address. It contains the owner’s public key, the dates between which it is valid, and the name of the CA that signed it. It ends with the CA’s signature, which cannot be forged without the CA’s private key. When you check a certificate, you are checking that signature, the dates, and the name.

A cluster in one picture

Look at how the pieces fit together. Clients reach the cluster through a load balancer or an API gateway, which spreads their requests over the nodes. The nodes then talk to each other over the transport layer. Both kinds of traffic can be protected by TLS, but they are configured separately.

flowchart LR
    A["Client application"] -->|HTTPS on port 9200| B["Load balancer or API gateway"]
    K["Kibana"] -->|HTTPS on port 9200| C
    B -->|HTTPS| C["Elasticsearch Node 1"]
    C |Transport TLS on port 9300| D["Elasticsearch Node 2"]
    C |Transport TLS on port 9300| E["Elasticsearch Node 3"]
    D |Transport TLS on port 9300| E

Notice the two port numbers. By default, the HTTP layer listens on port 9200 and the transport layer listens on port 9300. A port is like a door number on a building: the same server can offer different services on different doors. Because the two layers have different jobs and different audiences, they get different doors and different security settings.

Elasticsearch has two separate communication channels, and each one needs its own TLS setup. Knowing which is which prevents most configuration mistakes.

The transport layer

The transport layer is the private channel of the cluster. Nodes use it to discover each other, agree on who the master node is, share the cluster state, forward search requests to shards on other nodes, replicate new documents to copies, and move whole shards during recovery and rebalancing. It uses a binary protocol built for speed, not the text-based web protocol. Only Elasticsearch nodes, and a few internal tools, are expected to speak on it.

Because this channel carries the raw data and the control messages of the cluster, protecting it is essential. It is also the channel that decides who may join. For that reason, transport TLS uses mutual authentication by default: each node must show a valid certificate to the other, and each node checks the other’s certificate. Both sides verify each other, like two guards inspecting each other’s badges.

The HTTP layer

The HTTP layer is the public-facing channel. Applications, Kibana, Beats, Logstash, and command-line tools use it to send requests, in the familiar form of web calls, and receive answers in a readable format called JSON. Here, the server proves its identity to the client with a certificate, just like a website does for a browser. The client usually proves who it is with a username and password or an API key, which is a long token issued for a program.

Side-by-side comparison

Why they are configured separately

The two layers have different audiences and different risks. The transport layer should be reachable only from other nodes, so you can use a private certificate authority and tightly restrict the network. The HTTP layer may need to work with many kinds of clients, some of which you do not control, so its certificate may need to satisfy a wider set of trust rules or even a public authority. Keeping the settings separate lets you use different certificates, different lifetimes, and different verification rules for each.

Other doors you may meet

Modern Elasticsearch has a few more communication surfaces. There is a dedicated interface for cross-cluster connections that uses its own TLS settings, which Chapter 14 explains. Kibana has its own web server, whose TLS settings protect the browser connection. Agents and shippers have their own client settings for reaching Elasticsearch. Each of these is a separate TLS conversation with its own certificates and trust decisions.

Before a single byte of real data moves, two computers perform a short ritual to agree on rules, check identities, and build a shared secret.

The handshake is the most important moment in any TLS conversation. It takes a few round trips over the network, usually just milliseconds, and it happens every time a new connection is opened. Understanding it makes almost every TLS error message readable.

sequenceDiagram
    participant C as Client or joining node
    participant S as Server node
    C->>S: Hello with supported versions and cipher suites
    S->>C: Hello with chosen version and the server certificate
    C->>C: Check signature, dates, and name
    S->>C: Request for the client certificate on the transport layer
    C->>S: Client certificate
    S->>S: Check signature and dates of the client certificate
    C->>S: Key exchange to build the shared secret
    S->>C: Handshake finished
    C->>S: Encrypted application data
    S->>C: Encrypted application data

Why the handshake matters for performance

The handshake costs a few network round trips and some computing work. It happens once per connection, not once per message. Elasticsearch nodes keep their transport connections open for a long time and reuse them, so the cost is paid rarely. HTTP clients should do the same by keeping connections alive and reusing them, instead of opening a new connection for each request. Chapter 15 returns to this point.

Newer versions are faster

TLS 1.3, the newest widely used version, shortens the handshake compared with TLS 1.2 and removes some old, weak options. Modern Elasticsearch supports both by default, and prefers the newer one whenever both sides can use it.

Encryption alone is not enough. You must also be sure that you are talking to the right party. Certificates and authorities provide that assurance.

Suppose a stranger hands you a locked box and says, “I am your bank.” Locking the box does not prove the claim. You need a way to check the identity. Certificates solve this with a chain of trust: you trust an authority, the authority vouches for a certificate, and therefore you trust the certificate.

Certificate authorities

A certificate authority is an organization or a tool that signs certificates. Public authorities are trusted by web browsers and operating systems out of the box, which is why you can visit millions of websites without any setup. For a private Elasticsearch cluster, most teams use a private authority instead: a CA that they create themselves and that only their own machines are told to trust. This is simpler, cheaper, and safer for internal traffic, because nobody outside the company can obtain a certificate that your nodes accept.

Trust stores and key stores

Two kinds of storage matter. A keystore holds a machine’s own certificate together with its private key, like a person’s wallet with their own passport and their own signature stamp. A truststore holds the certificates of the authorities that the machine is willing to believe, like a list of governments whose passports are accepted at the border. Elasticsearch settings ask for both, or for a set of separate files in a common text format called PEM.

flowchart TD
    A["Private CA certificate: trusted by every node and client"] --> B["Node 1 certificate"]
    A --> C["Node 2 certificate"]
    A --> D["Node 3 certificate"]
    A --> E["HTTP layer certificate"]
    B --> F["Private key stays on Node 1 only"]
    C --> G["Private key stays on Node 2 only"]

Names inside certificates

A certificate lists the names or addresses that it is valid for, in a field called Subject Alternative Name, or SAN. When a client connects to search.example.com, it expects to find that name, or a matching wildcard, in the certificate. If the client connects using an address like 10.0.4.17, the certificate needs that address in its list. A mismatch produces an error even when the CA is trusted, because the client cannot be sure that it reached the intended server and not an impostor holding a valid certificate for a different name.

Validity periods

Every certificate has a start date and an end date. After the end date, it is no longer accepted. Shorter lifetimes limit the damage of a stolen key, but they require regular renewal. The Elasticsearch certificate tool creates certificates that last about three years by default, and you can choose a different length. Chapter 13 explains how to renew without downtime.

Intermediate authorities

Large organizations often use a small chain: a very protected root authority that rarely comes online, which signs an intermediate authority that does the daily signing. The chain of trust then has three or more links, and the client must have or receive the whole chain. It is just a longer path of vouching, and the same principles apply.

A security feature is only useful when you know its limits. Here is an honest map of where TLS helps and where you need other tools.

Encryption at rest is a separate job

Elasticsearch stores its data in files on disk. TLS does not touch those files. To protect them, teams use disk or volume encryption provided by the operating system or the cloud platform, and they protect snapshot storage with the storage service’s own encryption features. Together with TLS, this covers data both in motion and at rest.

Authentication and authorization sit on top

After TLS has built the safe channel, Elasticsearch still asks who is calling and what they are allowed to do. Authentication proves identity, by password, API key, token, or client certificate. Authorization decides which actions and data that identity may use, through roles. TLS carries these credentials safely, which matters a lot: sending a password over an unencrypted channel is like shouting it across a room.

Client certificates as a second badge

The HTTP layer can also ask clients for certificates, making the connection mutual, as the transport layer does. This is useful for machine-to-machine traffic, where a certificate can act as a strong identity. It is off by default on the HTTP layer, because many clients such as browsers and simple scripts do not have certificates.

Beware of false comfort

A common trap is to believe that a padlock means the whole system is safe. It means only that the channel is private and that the server proved its identity. An application that logs secrets, exposes data to the wrong users, or uses weak passwords is still insecure. Use TLS as a strong foundation, not as the whole house.

When a node starts and tries to join a cluster, TLS is the first gate it must pass. The rules of that gate are set by a few important settings.

A node learns about other nodes from a list of seed hosts, which are addresses that it tries first. It opens a connection to the transport port of a seed host, and the TLS handshake begins. Both sides show certificates and check each other. Only if both checks succeed does the real conversation start, in which the joining node announces itself and the cluster decides to accept it.

flowchart TD
    A["New node starts and contacts a seed host"] --> B["TLS handshake on the transport port"]
    B --> C{"Does each side trust the other certificate?"}
    C -->|Yes| D["Nodes exchange cluster join messages"]
    C -->|No| E["Connection is closed and the join fails"]
    D --> F["Shards may be copied to the new node"]

Client authentication on the transport layer

The setting xpack.security.transport.ssl.client_authentication controls whether the receiving node demands a certificate from the connecting node. On the transport layer, its default is required. That default is what makes rogue nodes hard to add. It is best left as it is.

Verification modes

The setting xpack.security.transport.ssl.verification_mode decides how strictly a certificate is checked. There are three choices, and the difference is about names.

Choosing between full and certificate

Full verification is more secure, because a stolen certificate for one node cannot be used from another machine. It requires each node to have its own certificate with the right names, which means more certificates to create and renew. The certificate mode is easier to run, especially in environments where addresses are dynamic, such as containers. Many clusters run happily in certificate mode with a private authority that is well protected. If your team can automate certificate issuance, choose full.

What is exchanged over the transport channel

Once the connection is protected, everything the cluster needs goes through it: cluster state updates, replication of each new document to its copies, search requests fanning out to shards, results coming back, and whole shards moving during recovery. On a busy cluster this is a large volume of data, so the efficiency of the encryption matters, which Chapter 15 covers.

Modern Elasticsearch makes a first-time installation safe without any manual certificate work. It is worth knowing what happens behind the scenes.

Starting with version 8, when you start a brand-new node for the first time with no special security settings, Elasticsearch turns security on and configures TLS by itself. It creates a private authority and certificates for both the transport layer and the HTTP layer. It prints a password for the built-in elastic user and a token that lets Kibana or another node enroll. It saves the generated files inside a certificates folder in the configuration directory, including the authority certificate that clients need in order to trust the HTTP layer.

flowchart TD
    A["Start the first node for the first time"] --> B["Elasticsearch creates a CA and certificates"]
    B --> C["Console shows a password and an enrollment token"]
    C --> D["Kibana enrolls using the token"]
    C --> E["Another node joins using a new enrollment token"]
    E --> F["The new node receives what it needs and joins the cluster"]

Enrollment tokens

An enrollment token is a short-lived code that carries just enough information for a new component to find the cluster and trust it. When you connect Kibana, you paste the token, and Kibana learns the address and the authority certificate and sets itself up. When you add another node, you give it a token, and the new node is configured to join over a protected connection. Tokens expire after a short time, so an old token lying around in a chat message is not a lasting risk. You can create a fresh token whenever you need one using the tool that comes with Elasticsearch.

When automatic setup applies

Automatic configuration is designed for the first start of a fresh node. It does not run when the node already has data, or when you have already written security settings by hand. That is intentional, so that it never overrides your choices or damages an existing cluster.

Is the automatic setup enough for production?

For learning, testing, and small setups, it is a great start. For serious production clusters, most teams take control of certificates so that they can follow company rules: their own authority, longer or shorter lifetimes, names that match their DNS, automated renewal, and central storage of secrets. The automatic setup also generates certificates that are tied to that first installation, so treat them as a starting point that you can replace, not as a permanent design.

Development mode and production mode

Elasticsearch behaves differently depending on how it is bound to the network. A node that listens only on the local machine is considered to be in development mode and is lenient. A node that listens on a real network address is in production mode, and it runs strict startup checks called bootstrap checks. One of these checks refuses to start a node in production mode with security enabled if transport TLS is not on. This safety net exists to stop people from accidentally exposing an unprotected cluster.

Setting up TLS by hand follows a clear order: plan the names, create the authority, issue certificates, place the files, set the options, and verify.

The usual order of work

File formats

Elasticsearch accepts key material in a few formats. PKCS#12 files, with a .p12 ending, bundle a certificate and its key in one password-protected file and are the default output of the certificate tool. PEM files are plain text, with separate files for certificates and keys, and are popular with tools from other ecosystems. Older JKS files from the Java world are also accepted. Choose one format for your organization and stay consistent, because mixing formats causes confusion during renewals.

The certificate tool

Elasticsearch includes a command-line helper named elasticsearch-certutil. It can create an authority, issue node certificates, produce certificate signing requests to send to a company authority, and run a guided flow for the HTTP layer. It is convenient and correct, but it is only a helper. If your organization already runs an authority with its own rules and audit trail, use that and give Elasticsearch the results.

Secure settings and passwords

Elasticsearch has its own encrypted store for secrets called the keystore (not to be confused with the certificate keystore). Passwords for TLS files belong there, under names such as the keystore secure password and the key passphrase settings. This keeps them out of configuration files that are copied into tickets, backups, and version control.

The HTTP layer is where most people first meet TLS. Every program that talks to the cluster must trust the certificate that the cluster presents.

When TLS is enabled on the HTTP layer, plain web addresses that begin with http stop working, and clients must use https instead. Sending a plain request to a TLS port produces an error, because the server expects the start of a handshake and receives ordinary text. This is the most common first symptom people see after enabling HTTPS.

What every client needs

A client needs three things. First, the right address, using a name that appears in the server certificate. Second, the certificate of the authority that signed the server certificate, so that it can verify the badge. Third, its own credentials, such as a username and password or an API key. Kibana, Beats, Logstash, Elastic Agent, and the official language clients all have settings for the authority certificate.

The authority fingerprint shortcut

Some official clients and agents accept the fingerprint of the authority certificate instead of the whole file. A fingerprint is a short code computed from the certificate, like the serial number of a stamp. The client connects, receives the certificate chain, and checks that the authority’s fingerprint matches the one you provided. This makes first-time setup easier, and the automatic configuration prints the fingerprint for you. For long-term use, storing the actual authority certificate is a bit more transparent.

Kibana has two TLS conversations

Kibana talks to Elasticsearch as a client, so it needs the authority certificate for the HTTP layer. Kibana also serves web pages to people’s browsers, and that connection has its own TLS settings on the Kibana side. Many teams put a load balancer or reverse proxy in front of Kibana to handle the browser side. Remember that these are two separate conversations with two sets of certificates.

Load balancers and API gateways

In most production designs, clients do not reach the nodes directly. They go through a load balancer, which spreads the traffic over the nodes, or an API gateway, which also applies rules like rate limits and authentication. That middle device has to deal with TLS, and there are two main designs.

flowchart LR
    A["Client"] -->|TLS session 1| B["Load balancer or API gateway"]
    B -->|TLS session 2| C["Elasticsearch node"]
    C |Transport TLS| D["Other nodes"]

Names must match what clients type

If clients connect to search.example.com, the certificate they see, whether from the balancer or from the node, must list that name. A cluster with a balancer often needs two sets of names: the public name on the balancer’s certificate, and the node names on the node certificates that the balancer verifies.

Public or private authority for the HTTP layer?

If your clients are all inside your company, a private authority is enough, provided that every client is given its certificate. If external partners or browsers must connect, a certificate from a public authority on the balancer avoids handing your private authority to outsiders. Many teams use a public certificate at the edge and a private one inside.

TLS is not one fixed recipe. There are versions and menus of encryption methods, and old ones have been broken over the years.

Two settings shape what the connection may use. The protocol version is the edition of the TLS rulebook, such as TLS 1.2 or TLS 1.3. The cipher suite is the specific combination of methods used for key agreement, encryption, and integrity checking. During the handshake, the client offers what it supports and the server picks the best match.

Older versions are unsafe

Early versions such as SSL 3.0, TLS 1.0, and TLS 1.1 have known weaknesses and are switched off in modern Elasticsearch. Recent versions of Elasticsearch allow TLS 1.2 and, when the Java runtime supports it, TLS 1.3 by default. The supported_protocols setting under each layer lets you narrow this list, for example to allow only TLS 1.3 in an environment where every client is modern.

Cipher suites in plain words

A cipher suite name is a long string, but it is built from a few parts. One part says how the two sides agree on a secret, another says which fast lock protects the data, and another says how tampering is detected. Good suites use forward secrecy, which means that even if someone steals a server’s private key next year, they still cannot unlock traffic that they recorded last year, because each session used a fresh temporary secret.

The default is usually right

Elasticsearch relies on the Java runtime for its default list of strong cipher suites. For most clusters, the best approach is to leave the cipher list alone and keep the runtime updated. Restrict it only when a security policy demands it, and test before rollout. A cipher list that is too narrow can lock out legitimate clients, which shows up as handshake failures with a message about no shared cipher.

Compliance and special modes

Some organizations must follow standards that limit which algorithms are allowed. Elasticsearch supports a special mode that follows one such standard, called FIPS 140-2, in which only certain key formats and algorithms are permitted. Enabling it changes what file formats and settings you can use, so it needs to be planned from the start. If you work in such an environment, read the documentation for your version carefully before designing the certificates.

Balance security with compatibility

Stricter is not always better if you have older clients that cannot follow. The best approach is to know your clients. List every application, agent, and tool that connects, find their TLS versions, and upgrade the old ones before you tighten the settings. Then choose the strictest configuration that all of them can meet.

Certificates do not last forever. A cluster that runs well for years needs a calm, practiced routine for renewing them before they expire.

The number one cause of TLS outages in real life is not an attack. It is an expired certificate. On the day it runs out, connections that once worked start to fail, and if the cause is not obvious, the team scrambles. A steady lifecycle habit removes this whole class of incident.

The life of a certificate

Renewing node certificates

If the authority stays the same, renewing a node certificate is simple: issue a new one, replace the file, and let Elasticsearch reload it. Because the nodes trust the authority and not one particular certificate, the new certificate is accepted at once. Do this for one node at a time, and check the health of the cluster between steps.

Rotating the authority itself

Replacing the authority is harder, because every node and every client trusts the old one. The trick is a period of overlapping trust. First, add the new authority certificate to every truststore, alongside the old one, so that everyone accepts both. Then issue new node certificates from the new authority and roll them out node by node. Finally, once every node uses the new certificates, remove the old authority from the truststores.

flowchart LR
    A["Stage 1: add the new CA to every truststore"] --> B["Stage 2: issue node certificates from the new CA"]
    B --> C["Stage 3: roll out the new certificates node by node"]
    C --> D["Stage 4: remove the old CA from every truststore"]

Seeing what is about to expire

Elasticsearch has an operation that lists the certificates it is using, with their subjects, paths, and expiry dates. It is a quick way to check every node and to feed a monitoring job. Combine it with an alert so that expiry becomes an item on a calendar, not a surprise.

What happens at expiry

Expiry is checked when a connection is set up. Connections that are already open may continue for a while, which can hide the problem until a node restarts or a connection is dropped. Then the handshake fails, nodes cannot rejoin, and clients see errors. This delayed effect makes it wise to check dates proactively instead of waiting for symptoms.

Automating the routine

The most reliable renewal is one that no human has to remember. Many teams automate issuance and delivery with secret management tools and configuration management, and they set certificate lifetimes short enough to force the automation to work. Where automation is not possible, a calendar reminder with a written procedure is better than nothing.

Beyond the two main layers, several other parts of the Elastic ecosystem use TLS. Each is its own conversation with its own certificates.

Cross-cluster in more detail

When two clusters cooperate, each becomes a client of the other, and each must decide whom to trust. In the older certificate-based model, the two clusters trust each other’s authorities on the transport layer, which gives the remote cluster wide power. In the newer model, the remote cluster exposes a separate, narrow interface protected by TLS and by API keys that list exactly which indices can be reached. This reduces the risk if a remote cluster is compromised. Check the documentation for the versions you run before choosing a model.

Do not forget the smaller connections

A common blind spot is the set of small, quiet connections around the cluster: a script that posts alerts, a scheduled job that pulls reports, an old dashboard tool. If they use plain HTTP against a cluster that has just turned on HTTPS, they simply stop working. Before changing any layer, list every client and plan its update.

Encryption costs some work, but on modern hardware the cost is usually small. The habits that keep it small are simple.

Where the cost comes from

TLS adds work in two places. The handshake uses heavy public-key math and some network round trips, and it happens once per connection. After that, encrypting and decrypting each message with the shared key is much cheaper, and most modern processors have special instructions that make it faster. The result is that a healthy, well-configured cluster usually sees only a modest increase in CPU use. The exact number depends on your hardware, traffic, and message sizes, so measure it in your own environment.

Reuse connections

Nodes keep transport connections open, so the handshake is rare inside the cluster. On the HTTP layer, the biggest saver is to reuse connections. A client that opens a fresh connection for every request pays the handshake each time, which can multiply latency. Use client libraries with connection pooling and keep-alive enabled, and create one long-lived client object instead of a new one per request.

Session resumption

TLS can also remember a recent session so that a returning client can skip parts of the handshake. This helps clients that reconnect often. It is handled by the TLS libraries and needs little configuration from you.

Big data movements

Recovery and rebalancing move whole shards across the transport layer, which can be many gigabytes. Encryption adds CPU load on both ends during such moves. On clusters with many nodes and large shards, watch CPU during recovery, and plan bulk movements outside peak search hours.

Load balancers and scale

If a load balancer terminates TLS for thousands of clients, it needs enough capacity to handle the handshakes. Balancers built for this usually have dedicated hardware support, but capacity still needs planning. In the pass-through design, the nodes take on the handshake work instead, so make sure they have headroom.

Scaling the number of nodes

Every node pair may hold a connection, so the number of connections grows with the cluster size. Each connection is set up once, and certificates are validated at setup. Larger clusters make certificate expiry checks and certificate distribution more important, because there are simply more files to manage. Automation pays for itself here.

Measure, do not guess

To learn the real cost, run a load test with TLS off and on in a test environment and compare CPU, latency, and throughput. The measured difference tells you whether you need to change anything at all. For most clusters, the answer is no, and the security gain far exceeds the cost.

No security feature is free. Here is an honest scorecard so you can decide how to use TLS and where to invest effort.

The central trade-off: convenience against protection

The easiest cluster to run is one with no encryption, no certificates, and no client settings. It is also the easiest to attack. Every step toward stronger TLS, such as full verification and short lifetimes, adds work for the team. The best balance is to make the secure path the automated path, so that strong settings are also the low-effort ones.

The second trade-off: strict names against flexibility

Full verification catches misuse of stolen certificates but demands correct names everywhere, which is difficult in dynamic environments where addresses change. Certificate mode is more flexible and still strong when the authority is well guarded. Choose according to how well your team can automate certificate issuance.

The third trade-off: one authority against many

One shared authority for everything is easy to manage but has a wide blast radius if its key leaks. Separate authorities for the transport layer, the HTTP layer, and each environment are more work but limit damage. Larger organizations usually lean toward separation.

When TLS alone is the wrong answer

If your worry is who can read which data, use roles and privileges. If your worry is stolen disks, use disk encryption. If your worry is knowing who did what, use audit logs. If your worry is a malicious insider with valid credentials, use least privilege, monitoring, and reviews. TLS is the base layer, and each of these builds on it.

A secure and calm TLS setup does not happen by accident. These six habits make it strong and easy to run.

Pattern 2 in action

A team creates a certificate for each of nine nodes with the node’s host name and address listed. They set the transport verification mode to full. One day a laptop of a former administrator turns out to contain a copy of the certificate and key of node four. Because the certificate lists only node four’s names, and the cluster checks names, an attacker cannot use it from another address without also spoofing the network. The team revokes and replaces the certificate for node four alone, without touching the other eight.

Pattern 4 in action

A platform team uses a secret management system that issues node certificates valid for 90 days. A small job renews each certificate at day 60 and places the new files on the node. Elasticsearch reloads the files automatically. A dashboard shows the days left for every certificate in the cluster, and an alert triggers if any falls below 30. Over two years, the team has not had a single certificate incident.

A pattern for documentation

Write a short runbook that answers five questions: where the authority key lives, how to issue a certificate, how to place and reload it, how to check expiry, and who to call. The best time to test the runbook is on a quiet afternoon, not during an outage.

These are the traps that quietly weaken TLS or cause avoidable outages. Each one is common in real projects and easy to avoid once you know it.

Other frequent mistakes

• Putting keystore passwords in the plain configuration file instead of the secure keystore.
• Leaving key files readable by every user on the machine.
• Forgetting to add the load balancer name or a service address to the certificate names.
• Updating certificates on some nodes and not on others, leaving mixed trust.
• Testing only from the node itself, so that missing client trust goes unnoticed.
• Assuming that a padlock means that access control is also in place.

TLS problems are quiet until they are sudden. A few simple checks turn them into visible, calendar-friendly tasks.

Monitoring TLS means watching three things: whether certificates are close to expiring, whether handshakes are failing, and whether the settings are what you think they are. Each has a simple tool.

Reading Elasticsearch logs

When a TLS problem occurs, Elasticsearch writes messages in its regular log. On the transport layer, look for lines about failed handshakes, unknown certificates, or nodes that could not join. On the HTTP layer, look for messages about clients that failed to complete a handshake. The messages often quote a short reason, such as an unknown authority, an expired certificate, or a mismatch of names.

Turning on more detail

For a hard case, you can raise the logging level for the security and TLS parts of Elasticsearch to see more. The Java runtime also has a debug switch, javax.net.debug, which prints the details of each handshake step. Use these only for a short time, because they produce a lot of output and can reveal sensitive details in logs.

Client side evidence

Half of every handshake happens on the client, so the client’s logs matter. Language libraries, Kibana, and shippers usually print the reason for a failure. Compare the client’s message with the server’s message, and you will often see both halves of the story.

A simple dashboard

A useful small dashboard shows the days left on each certificate, the count of TLS-related errors per hour, the number of nodes in the cluster over time, and the number of client connections. Five or six numbers are enough. Link each alert to a runbook page that says what to do.

TLS failures are usually not mysterious. They fall into a handful of patterns, and each has a calm, practical recovery.

Certificate expired

Symptoms: nodes cannot reconnect after a restart, clients report expired certificates, and the cluster may split into smaller groups if some nodes have valid certificates and others do not. Recovery: issue new certificates, place them on the affected nodes, and let Elasticsearch reload them or restart if needed. Then review the alert setup so that it does not happen again.

Authority rotated without overlap

Symptoms: after a change, nodes reject each other with unknown authority errors. Recovery: put both the old and the new authority in every truststore, restore the cluster, and then continue the rotation in the proper order. This is the reason why Chapter 13 stresses overlapping trust.

Names do not match

Symptoms: clients or nodes complain that no name in the certificate matches the address used. Recovery: reissue the certificate with the right names and addresses, or change the address the client uses to one that is listed. Also review whether a balancer or a service alias is missing from the list.

Clock problems

Certificates are valid between two dates, and the check uses the machine’s clock. A node with a clock set far in the past or the future can reject good certificates, complaining that they are not yet valid or already expired. Keep clocks synchronized with a time service.

Keystore password mismatch

Symptoms: a node refuses to start or fails to reload its certificates, with a message about not being able to open the keystore or recover the key. Recovery: confirm that the password in the secure keystore matches the file, and that the file is not corrupted. Keep a record of which password belongs to which file, in your secret manager.

The cluster is split or degraded

When some nodes cannot talk to others because of certificates, the cluster may lose its master, refuse writes, or mark shards as unassigned. The first goal is to restore trust between nodes so that they see each other. After that, the cluster recovers on its own by rebuilding missing shard copies. Avoid deleting data or forcing shard allocation in a panic, because the data is usually fine and only communication is blocked.

Locked out after enabling

Sometimes a team enables HTTPS and finds that no client can connect. The usual causes are clients still using plain addresses, missing authority certificates on clients, or a balancer that has not been updated. A well-prepared rollout plan includes a rollback, such as keeping the old configuration ready and a snapshot taken beforehand.

Recovery habits that help

• Keep copies of certificates and configuration in a secure, versioned place.
• Take a snapshot before changes that touch the cluster’s communication.
• Change one node at a time whenever the procedure allows it, and check cluster health between steps.
• Write down the exact steps used to fix each incident, and add them to the runbook.

When an error appears, match the message to its meaning. This table covers the messages that people meet most often.

A calm way to debug

Here are four common situations, with rough numbers, showing TLS at work. The companies are imaginary, but the patterns are the ones teams meet every day.

A worked example: one year in the life of a certificate plan

TLS is a simple idea with a big payoff: locked boxes, badge checks, and tamper seals for every conversation in your cluster. Here is everything to remember.

Keep in mind that setting names, defaults, and tools can change between Elasticsearch versions, so confirm exact details against the documentation of the release you run. With that habit, and the ideas in this guide, you can keep every conversation in your cluster private, verified, and calm.