🚨 Filebeat Error Guide: 'x509: certificate signed by unknown authority' — Trust the CA

Overview

Filebeat fails the TLS handshake to its Elasticsearch (or Logstash) output when it cannot validate the server certificate against a trusted certificate authority. The publisher backs off and retries, logging:

Failed to connect to backoff(elasticsearch(https://es01:9200)): Get "https://es01:9200": x509: certificate signed by unknown authority

During the TLS handshake, Elasticsearch presents its certificate; Filebeat must chain that certificate up to a CA it trusts. unknown authority means the chain does not terminate in a CA that Filebeat has been given (via ssl.certificate_authorities) or in the host’s system trust store. The connection is refused before any bulk request is sent. This is a security control working as designed — the fix is to give Filebeat the right CA, not to blindly disable verification.

Symptoms

• x509: certificate signed by unknown authority in the Filebeat log during output connect.
• filebeat test output fails at the TLS... line, not the connection... line.
• curl https://es01:9200 (without -k) also fails with an SSL certificate problem, confirming it is not Filebeat-specific.
• No events index; the output stays in a connect/backoff loop.
• Errors start right after a certificate rotation or a move to a self-signed / internal CA.

Common Root Causes

• CA not provided — ssl.certificate_authorities is unset and the server uses an internal or self-signed CA not in the system store.
• Wrong CA file — the configured CA does not match the one that signed the server certificate.
• Incomplete chain — Elasticsearch presents a leaf certificate without its intermediate, so the chain cannot be built.
• Rotated CA — certificates were reissued under a new CA but Filebeat still trusts the old one.
• Self-signed leaf — the node uses a self-signed certificate (its own CA) that must be trusted explicitly.
• Copy/paste corruption — the PEM CA file has missing BEGIN/END lines or Windows line endings.

Diagnostic Workflow

Run the output test to confirm the failure is at the TLS layer:

filebeat test output

Inspect the certificate the server actually presents and its issuer chain:

openssl s_client -connect es01:9200 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject
echo | openssl s_client -connect es01:9200 -showcerts 2>/dev/null \
  | grep -c 'BEGIN CERTIFICATE'    # count certs in the presented chain

Verify curl trusts the same CA Filebeat should use:

curl -v --cacert /etc/filebeat/certs/ca.crt https://es01:9200 -u elastic:$ES_PASS

Confirm the CA file Filebeat is configured with and that it matches the issuer:

grep -A4 'ssl' /etc/filebeat/filebeat.yml
openssl x509 -in /etc/filebeat/certs/ca.crt -noout -subject -issuer -dates

If curl --cacert succeeds but Filebeat fails, the wrong file is referenced in the config.

Example Root Cause Analysis

After migrating Elasticsearch to certificates issued by the Elastic-generated CA (elasticsearch-certutil), every Filebeat host began logging x509: certificate signed by unknown authority. openssl s_client showed the server presented a single leaf certificate issued by CN=Elasticsearch security auto-configuration HTTP CA, and the count of BEGIN CERTIFICATE blocks was 1 — the intermediate/root was not being served, so clients had to trust the CA out of band.

The config referenced an old CA path that no longer matched. Pointing it at the new CA fixed the handshake:

output.elasticsearch:
  hosts: ["https://es01:9200"]
  ssl.certificate_authorities: ["/etc/filebeat/certs/http_ca.crt"]

curl --cacert /etc/filebeat/certs/http_ca.crt https://es01:9200 returned 200, confirming the CA before restart. After systemctl restart filebeat, filebeat test output reported TLS... OK and ingestion resumed. Crucially, the team did not set ssl.verification_mode: none, which would have silenced the error while leaving the connection unverified.

Prevention Best Practices

• Distribute the correct CA to every Filebeat host via configuration management whenever certificates rotate.
• Reference the CA explicitly with ssl.certificate_authorities rather than relying on the system trust store for internal CAs.
• Never use ssl.verification_mode: none in production — it disables authentication and invites man-in-the-middle attacks.
• Automate certificate rotation so the CA, server certs, and client trust update together with a clear expiry runbook.
• Monitor certificate expiry dates and TLS handshake failures so a rotation gap is caught before ingestion stops.

Quick Command Reference

filebeat test output
openssl s_client -connect es01:9200 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject
curl -v --cacert /etc/filebeat/certs/ca.crt https://es01:9200 -u elastic:$ES_PASS
openssl x509 -in /etc/filebeat/certs/ca.crt -noout -subject -dates
grep -A4 ssl /etc/filebeat/filebeat.yml

Conclusion

x509: certificate signed by unknown authority is a trust gap, not a network failure: Filebeat cannot chain the server certificate to a CA it knows. Use openssl s_client to see what the server presents, confirm the CA with curl --cacert, then point ssl.certificate_authorities at the correct file. Resist disabling verification — give Filebeat the right CA and the handshake succeeds securely. More TLS fixes are in the Filebeat guides.