You can specify SSL options with any output that supports SSL, like Elasticsearch, Logstash, or Kafka.
Example output config with SSL enabled:
output.elasticsearch.hosts: ["https://192.168.1.42:9200"] output.elasticsearch.ssl.certificate_authorities: ["/etc/pki/root/ca.pem"] output.elasticsearch.ssl.certificate: "/etc/pki/client/cert.pem" output.elasticsearch.ssl.key: "/etc/pki/client/cert.key"
Also see Secure communication with Logstash.
You can specify the following options in the
ssl section of the
apm-server.yml config file:
enabled setting can be used to disable the ssl configuration by setting
false. The default value is
SSL settings are disabled if either
enabled is set to
false or the
ssl section is missing.
The list of root certificates for server verifications. If
certificate_authorities is empty or not set, the trusted certificate authorities of the host system are used.
The path to the certificate for SSL client authentication. If the certificate is not specified, client authentication is not available. The connection might fail if the server requests client authentication. If the SSL server does not require client authentication, the certificate will be loaded, but not requested or used by the server.
When this option is configured, the
key option is also required.
The client certificate key used for client authentication. This option is required if
certificate is specified.
The passphrase used to decrypt an encrypted key stored in the configured
List of allowed SSL/TLS versions. If SSL/TLS server decides for protocol versions
not configured, the connection will be dropped during or after the handshake. The
setting is a list of allowed protocol versions:
TLSv1 for TLS version 1.0,
The default value is
[TLSv1.1, TLSv1.2, TLSv1.3].
This option controls whether the client verifies server certificates and host
names. Valid values are
verification_mode is set
none, all server host names and certificates are accepted. In this mode,
TLS-based connections are susceptible to man-in-the-middle attacks. Use this
option for testing only.
The default is
The list of cipher suites to use. The first entry has the highest priority. If this option is omitted, the Go crypto library’s default suites are used (recommended). Note that TLS 1.3 cipher suites are not individually configurable in Go, so they are not included in this list.
The following cipher suites are available:
- ECDHE-ECDSA-AES-128-CBC-SHA256 (TLS 1.2 only, disabled by default)
- ECDHE-ECDSA-AES-128-GCM-SHA256 (TLS 1.2 only)
- ECDHE-ECDSA-AES-256-GCM-SHA384 (TLS 1.2 only)
- ECDHE-ECDSA-CHACHA20-POLY1305 (TLS 1.2 only)
- ECDHE-ECDSA-RC4-128-SHA (disabled by default - RC4 not recommended)
- ECDHE-RSA-AES-128-CBC-SHA256 (TLS 1.2 only, disabled by default)
- ECDHE-RSA-AES-128-GCM-SHA256 (TLS 1.2 only)
- ECDHE-RSA-AES-256-GCM-SHA384 (TLS 1.2 only)
- ECDHE-RSA-CHACHA20-POLY1205 (TLS 1.2 only)
- ECDHE-RSA-RC4-128-SHA (disabled by default- RC4 not recommended)
- RSA-AES-128-CBC-SHA256 (TLS 1.2 only, disabled by default)
- RSA-AES-128-GCM-SHA256 (TLS 1.2 only)
- RSA-AES-256-GCM-SHA384 (TLS 1.2 only)
- RSA-RC4-128-SHA (disabled by default - RC4 not recommended)
Here is a list of acronyms used in defining the cipher suites:
- 3DES: Cipher suites using triple DES
- AES-128/256: Cipher suites using AES with 128/256-bit keys.
- CBC: Cipher using Cipher Block Chaining as block cipher mode.
- ECDHE: Cipher suites using Elliptic Curve Diffie-Hellman (DH) ephemeral key exchange.
- ECDSA: Cipher suites using Elliptic Curve Digital Signature Algorithm for authentication.
- GCM: Galois/Counter mode is used for symmetric key cryptography.
- RC4: Cipher suites using RC4.
- RSA: Cipher suites using RSA.
- SHA, SHA256, SHA384: Cipher suites using SHA-1, SHA-256 or SHA-384.
The list of curve types for ECDHE (Elliptic Curve Diffie-Hellman ephemeral key exchange).
The following elliptic curve types are available:
This configures what types of TLS renegotiation are supported. The valid options
freely. The default value is never.
never- Disables renegotiation.
once- Allows a remote server to request renegotiation once per connection.
freely- Allows a remote server to repeatedly request renegotiation.
This configure a certificate pin can that ca be used to ensure that a specific certificate is used to as part of the verified chain.
The pin is a base64 encoded string of the SHA-256 of the certificate.
This check is not a replacement for the normal SSL validation but it add additional validation.
If this option is used with
verification_mode set to
none, the check will always fail because
it will not receive any verified chains.