In all three Beats (filebeat/metricbeat/auditbeat) the output.elasticsearch block hardcodes ssl.verification_mode: none and ssl.certificate_authorities: ["/etc/beats/certs/ca.crt"].
none disables server-certificate verification (no MITM protection). The hardcoded path only exists in a full stack, so standalone the CA lives under beats_ca_dir (e.g. /opt/ca), so the path is wrong and TLS breaks. The output.logstash block in the same files already uses {{ beats_tls_cacert }}.
Fix:
Replace the hardcoded CA path with the existing beats_tls_cacert variable (like the Logstash output already does).
Introduce a shared beats_ssl_verification_mode variable (default full), used in all output blocks, instead of the hardcoded value. full is secure-by-default and fixes the bug. The variable lets users deliberately drop to certificate for SAN mismatches (keeps CA verification, skips hostname check)
If full then fails in a full stack, it reveals a SAN gap in the generated ES certificate that should be fixed
In all three Beats (filebeat/metricbeat/auditbeat) the
output.elasticsearchblock hardcodesssl.verification_mode: noneandssl.certificate_authorities: ["/etc/beats/certs/ca.crt"].none disables server-certificate verification (no MITM protection). The hardcoded path only exists in a full stack, so standalone the CA lives under
beats_ca_dir(e.g. /opt/ca), so the path is wrong and TLS breaks. Theoutput.logstashblock in the same files already uses{{ beats_tls_cacert }}.Fix:
Replace the hardcoded CA path with the existing
beats_tls_cacertvariable (like the Logstash output already does).Introduce a shared
beats_ssl_verification_modevariable (default full), used in all output blocks, instead of the hardcoded value. full is secure-by-default and fixes the bug. The variable lets users deliberately drop to certificate for SAN mismatches (keeps CA verification, skips hostname check)If
fullthen fails in a full stack, it reveals a SAN gap in the generated ES certificate that should be fixed