How to configure Filebeat for TLS

Encrypting the Filebeat publishing path prevents log data, passwords, and API keys from crossing the network in clear text. TLS on the Elasticsearch output also exposes certificate, hostname, and trust-chain problems before they become silent shipping gaps.

For the common Filebeat to Elasticsearch path, Filebeat reads the output.elasticsearch block in /etc/filebeat/filebeat.yml, opens an HTTPS connection to the configured host, and validates the server certificate before it publishes any event. Current Filebeat releases still support a copied CA file with ssl.certificate_authorities or a trusted CA fingerprint with ssl.ca_trusted_fingerprint, and filebeat test output shows the certificate-verification and TLS-handshake result without sending a log line.

Current self-managed Elasticsearch installs usually start with security and HTTPS enabled, so Filebeat needs both a publisher credential and a trusted HTTP CA before the connection can succeed. These steps use the CA-file path because it is the clearest long-term option when multiple Filebeat hosts need the same trust chain; when the cluster still uses the autogenerated Elasticsearch HTTP CA, a trusted fingerprint can replace the copied CA file instead.

Steps to configure Filebeat for TLS:

Create a directory for the trusted CA and any optional client certificate files.
```
$ sudo install -d -m 750 /etc/filebeat/certs
```
Install the Elasticsearch HTTP CA certificate on the Filebeat host.
```
$ sudo install -m 644 /tmp/http-ca.crt /etc/filebeat/certs/http-ca.crt
```
Package-based Elasticsearch installs usually generate this CA as /etc/elasticsearch/certs/http_ca.crt on the Elasticsearch node. Copy the CA file, not the node private key or server certificate.

Related: How to configure Elasticsearch for TLS
Configure the Elasticsearch output to use HTTPS and trust the copied CA.
```
output.elasticsearch:
  hosts: ["https://node-01-secure:9200"]
  username: "filebeat_writer"
  password: "replace-with-filebeat-writer-password"
  ssl.certificate_authorities: ["/etc/filebeat/certs/http-ca.crt"]
  # ssl.certificate: "/etc/filebeat/certs/filebeat.crt"
  # ssl.key: "/etc/filebeat/certs/filebeat.key"
```
Only one output.* block can be enabled at a time, or Filebeat fails to start with conflicting publisher settings.

The host in hosts must match a DNS name or IP address in the Elasticsearch HTTP certificate subjectAltName extension, or the TLS handshake fails with an x509 name error.

Uncomment ssl.certificate and ssl.key only when Elasticsearch or a proxy in front of it requires client certificate authentication.

Store the password or API key in the Filebeat keystore instead of cleartext YAML on long-lived hosts.

Current Elastic quick-start examples also support ssl.ca_trusted_fingerprint when the cluster still uses the autogenerated HTTP CA and distributing the CA file is inconvenient. Use one trust method consistently for the same CA.

Current Filebeat releases still default to ssl.verification_mode: full. Lower that setting only for controlled troubleshooting because weaker modes remove hostname checks or disable certificate validation entirely.

Related: How to create a Filebeat keystore
Related: How to add a secret to a Filebeat keystore
Related: How to use an Elasticsearch API key with Filebeat output
Test the Filebeat configuration for syntax and permission problems before touching the running service.
```
$ sudo filebeat test config -c /etc/filebeat/filebeat.yml
Config OK
```
Related: How to test a Filebeat configuration
Test the saved output settings before restarting the service.
```
$ sudo filebeat test output -c /etc/filebeat/filebeat.yml
elasticsearch: https://node-01-secure:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.65.254
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 9.3.2
```
This current 9.3.2 check confirms the saved HTTPS host, certificate chain, and credentials are all usable by Filebeat without publishing an event.

Unknown CA failures usually mention certificate signed by unknown authority, while hostname mismatches usually mention the requested host name not appearing in the certificate.

Related: How to test Filebeat output connectivity
Restart the Filebeat service to apply the TLS settings.
```
$ sudo systemctl restart filebeat
```
Related: How to manage the Filebeat service with systemctl in Linux
Confirm the running Filebeat service establishes the HTTPS publisher connection after the restart.
```
$ sudo journalctl -u filebeat.service --since "5 min ago" --no-pager --lines=20
Apr 02 20:58:48 host filebeat[2148]: {"log.level":"info","@timestamp":"2026-04-02T12:58:48.756Z","log.logger":"publisher_pipeline_output","message":"Connection to backoff(elasticsearch(https://node-01-secure:9200)) established","service.name":"filebeat","ecs.version":"1.6.0"}
```
The journal line proves the running service, not only the one-shot test command, reconnected to the HTTPS Elasticsearch output.

If the journal shows 401 or 403, the TLS handshake succeeded and the remaining problem is credentials or privileges rather than certificate trust.

Related: How to manage the Filebeat service with systemctl in Linux