Skip to content

[Bug]: Beats Elasticsearch output disables TLS verification and hardcodes the CA path #513

Description

@afeefghannam89

In all three Beats 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), and the fixed path is wrong standalone, where the CA lives under beats_ca_dir (e.g. /opt/ca). The output.logstash block in the same files already uses {{ beats_tls_cacert }}.

Introduce shared Beats SSL settings used by all Beats TLS connections — the Elasticsearch output and the Kibana setup (#514):

  • beats_ssl_verification_mode (default full, secure by default). Users can deliberately drop to certificate for SAN mismatches (keeps CA verification, skips the hostname check); none only as an explicit opt-out.
  • CA resolution in three branches:
    • full stack → beats_tls_cacert (the stack CA),
    • standalone with beats_ssl_certificate_authorities set → that CA (private / externally-managed backend, CA distributed on the Beats hosts),
    • unset → omit the line → OS system store (public / cloud CAs).

Replaces the hardcoded none + fixed path. If full then fails in a full stack, it reveals a SAN gap in the generated ES certificate that should be fixed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugExisting behaviour is wrong or brokencomponent:beatsroles/beats - shared, or several beats at once

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions