The Elasticsearch exporter and base collector HTTP client configuration exposes the option we need, but we must confirm our translation of the TLS and proxy parameters are correct or we risk breaking customer deployments where these configurations are frequently used.

Setup (ideally automated) tests of translated configuration options showing:

• Our generated exporter configuration can be configured to trust self-signed certificates and connect to a server that uses them.
• Our generated exporter configuration can be configured to use mTLS with self-signed certificates and connect to a server that uses them.
• Our generated exporter configuration can be configured to use the ca_trusted_fingerprint option and successfully connect to Elasticsearch https://www.elastic.co/docs/reference/beats/filebeat/configuration-ssl#ca_trusted_fingerprint
• The SSL verification modes all behave in an equivalent way https://www.elastic.co/docs/reference/beats/filebeat/configuration-ssl#client-verification-mode
• Certificate key passphrases are supported https://www.elastic.co/docs/reference/beats/filebeat/configuration-ssl#server-key-passphrase
• Our generated exporter configuration can successfully write data through a network proxy configured via the GO proxy environment variables including NOPROXY
• Our generated exporter configuration can successfully write data through a network proxy configured to use any of proxy_url, proxy_disable, and proxy_headers https://www.elastic.co/docs/reference/beats/filebeat/elasticsearch-output#_proxy_disable
• Use of Go proxy environment variables and the proxy_url, proxy_disable, and proxy_headers configurations options together resolve with the same precedence.
• Our generated exporter configuration is compatible with Kerberos authentication https://www.elastic.co/docs/reference/beats/filebeat/elasticsearch-output#_kerberos_2

In general that all settings in https://www.elastic.co/docs/reference/beats/filebeat/elasticsearch-output and https://www.elastic.co/docs/reference/beats/filebeat/configuration-ssl should be explicitly tested to confirm that they behave in an equivalent way. It is not enough that the configuration exists, it has to be have in a compatible way.

See https://www.elastic.co/docs/reference/fleet/secure for additional TLS configuration examples.

We let users type anything they want into the Advanced YAML settings box so even if it isn't explicitly documented, the expectation is that if it works now it will keep working. https://www.elastic.co/docs/reference/fleet/es-output-settings#es-output-settings-yaml-config

Acceptance Critera

Automated tests exist proving that the translated collector configurations for beat receivers have not just matching configurations, but matching behavior. For timeouts the timeouts should be explicitly verified to be the same for example. It is not enough that the timeout parameters are set.