🚨 Filebeat Error: 'x509: certificate is valid for ..., not ...' — Cause, Fix, and Troubleshooting Guide

Overview

Filebeat verifies that the hostname in its output URL matches a name in the server certificate’s Subject Alternative Name (SAN) list. When the name you connect to is not in the certificate, TLS verification fails:

Failed to connect to backoff(elasticsearch(https://10.0.3.14:9200)): Get "https://10.0.3.14:9200": x509: certificate is valid for es01.internal, es01, not 10.0.3.14

This is a hostname/SAN mismatch, distinct from an untrusted CA (x509: certificate signed by unknown authority). The CA is trusted and the handshake gets far enough to inspect the certificate — but the name Filebeat used (often an IP, or a load-balancer name) is not covered by the SANs. Filebeat aborts the connection; no events publish until the name matches or verification is adjusted.

Symptoms

• x509: certificate is valid for <names>, not <host-you-used> in the output connect error.
• Connecting by hostname works but by IP fails, or vice versa.
• Appears after switching to an IP, a VIP, or a new DNS name for the cluster.
• filebeat test output reports the TLS verification failure with the SAN list.

Common Root Causes

• Connecting by IP while the cert only lists DNS names.
• Load-balancer / VIP name not present in the certificate SANs.
• Renamed node whose cert was not reissued with the new name.
• Wrong host in output.elasticsearch.hosts vs the cert’s names.
• Cert issued for localhost/short name but accessed via FQDN.

How to diagnose

Read the certificate’s SANs directly and compare to the host you use:

openssl s_client -connect es01.internal:9200 -servername es01.internal </dev/null 2>/dev/null | \
  openssl x509 -noout -text | grep -A1 'Subject Alternative Name'
grep -A3 'output.elasticsearch' /etc/filebeat/filebeat.yml

Confirm the failing name is (or is not) in the SAN list:

filebeat test output

Fixes

The correct fix is to connect using a name that is in the certificate. Point the output at the SAN-covered hostname (and make it resolvable):

output.elasticsearch:
  hosts: ["https://es01.internal:9200"]   # a name present in the cert SANs
  ssl.certificate_authorities: ["/etc/filebeat/certs/ca.pem"]
  ssl.verification_mode: "full"

If you must reach the cluster by IP or a new VIP, reissue the server certificate with those added to the SANs — do not silently disable verification in production. Only as a controlled, temporary measure you can relax to certificate (not hostname) verification:

  ssl.verification_mode: "certificate"   # verifies chain but NOT hostname — use sparingly

Restart Filebeat and re-run filebeat test output to confirm the handshake succeeds.

What to watch out for

• This is a SAN mismatch, not an untrusted CA — a different fix than adding the CA.
• verification_mode: none disables all checks and is unsafe; prefer reissuing the cert.
• Modern TLS ignores the legacy CN — the name must be in the SAN list.
• Behind a load balancer, the cert must include the LB/VIP name clients actually use.

Related

• Filebeat Error Guide: ‘x509: certificate signed by unknown authority’
• Filebeat Error Guide: ‘connection refused’
• Filebeat Error Guide: ‘dial tcp: i/o timeout’