SSL for FIlebeat -> Logstash (remote error: tls: handshake failure)

(Will Foster) #1

Hi Folks,

I've been working on upgrading my Ansible playbooks for ELK/EFK to the latest 5.2.x versions and I'm having problems with TLS/SSL connections from filebeat --> logstash. For the purpose of this post I am setting up everything manually until it all works.

Everything works as it should with non-encrypted connections but I get the following error sending from filebeat (5.2.1) to my logstash server (5.2.1). This is all on latest CentOS 7.3.

FILEBEAT SIDE

Here is the error I'm getting in filebeat:

2017-02-16T15:48:50Z DBG  End of file reached: /var/log/messages; Backoff now.
2017-02-16T15:48:52Z DBG  End of file reached: /var/log/boot.log; Backoff now.
2017-02-16T15:48:52Z DBG  End of file reached: /var/log/wpa_supplicant.log; Backoff now.
2017-02-16T15:48:52Z DBG  Flushing spooler because of timeout. Events flushed: 0
2017-02-16T15:48:56Z DBG  connect
2017-02-16T15:48:56Z ERR Connecting error publishing events (retrying): remote error: tls: handshake failure
2017-02-16T15:48:56Z DBG  send fail

Here is my filebeat configuration:

filebeat:
  prospectors:
    -
      paths:
        - /var/log/*.log
        - /var/log/messages
        - /var/log/foreman/*.log
        - /var/log/foreman-proxy/*.log
        - /var/log/nova/*.log
        - /var/log/neutron/*.log
        - /var/log/cinder/*.log
        - /var/log/keystone/*.log
        - /var/log/horizon/*.log
        - /var/log/glance/*.log
        - /var/log/mariadb/*.log
        - /var/log/rabbitmq/*.log
        - /var/log/mongodb/*.log
        - /var/log/ceilometer/*.log
        - /var/log/ceph/*.log
        - /var/log/heat/*.log
        - /var/log/openvswitch/*.log
        - /var/log/pcsd/*.log
        - /var/log/puppet/*.log
        - /var/log/redis/*.log
        - /var/log/glusterfs/*.log
        - /var/log/swift/*.log

      input_type: log

     document_type: syslog

output:

  logstash:
    hosts: ["192.168.122.81:5044"]
    bulk_max_size: 1024


    ssl:
      certificate_authorities: "/etc/filebeat/filebeat-forwarder.crt"
      certificate_key: "/etc/filebeat/filebeat-forwarder.key"

      supported_protocols: [TLSv1.0, TLSv1.1, TLSv1.2, SSLv3]

      min_version: 1.0
      max_version: 1.2

shipper:
logging:
  files:
  selectors: ["*"]
  level: debug

LOGSTASH SIDE

Here is the configuration on the logstash side

input {
  tcp {
    port => 5000
    type => syslog
  }
  udp {
    port => 5000
    type => syslog
  }
}

filter {
  if [type] == "syslog" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
      add_field => [ "received_at", "%{@timestamp}" ]
      add_field => [ "received_from", "%{host}" ]
    }
    date {
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    }
  }
}

output {
  elasticsearch { hosts => ["localhost:9200"] }
  stdout { codec => rubydebug }
}

input {
  beats {
    port => 5044
    ssl => true
    ssl_certificate_authorities => ["/etc/pki/tls/certs/ca-bundle.crt"]
    ssl_certificate => ["/usr/share/logstash/filebeat-forwarder.crt"]
    ssl_key => ["/usr/share/logstash/filebeat-forwarder.key"]
    ssl_verify_mode => "none"
  }
}

SSL Information:

Above in my logstash.conf I have tried both /etc/pki/tls/certs/ca-bundle.crt (after adding the generated certificate to it) and the original filebeat-forwarder.crt for the ssl_certificate_authorities directive with the same result of remote error: tls: handshake failure

I am creating my SSL certificates with AltSANS support via Ansible, and prior 2.x versions worked without an issue (changing the tls to ssl per the 5.x version changes).

For posterity here's the Ansible code that generates them, and md5sum on both locations says it's the same file.

- name: Create client forwarder SSL certificate
  command: openssl req -subj '/CN={{ ansible_fqdn }}/' -config /etc/pki/tls/openssl_extras.cnf \
    -x509 -days 3650 -batch -nodes -newkey rsa:2048 -keyout /usr/share/logstash/filebeat-forwarder.key \
    -out /usr/share/logstash/filebeat-forwarder.crt
  ignore_errors: true
  when: filebeat_forwarder_ssl_exists != 0

I am specifying the same filebeat-forwarder.crt certificate for any mention of both certificate or CA on both sides and the permissions on all the certificates are liberal (tried 644 and 755). They are located inside accessible locations like logstash $HOME or filebeat $HOME.

I've tried secure=false on the filebeat side and I am using ssl_verify_mode => "none" on the logstash side as well but it doesn't seem to make a difference.

I've also tried adding the filebeat-forwarder.crt to my /etc/pki/tls/certs/ca-bundle.crt on the logstash side.

Any ideas what I am missing? Thank you.

(Will Foster) #2

Here is the output of openssl x509 -in /usr/share/logstash/filebeat-forwarder.crt -text -noout you can see AltSAN support for the logstash server (192.168.122.81) so this seems to look ok (and what was what I used in prior 2.x versions).

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 10759014160140594636 (0x954fb25ffc93edcc)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=TG, ST=Togo, L=Lome, O=Private company, CN=*
        Validity
            Not Before: Feb 16 00:31:59 2017 GMT
            Not After : Feb 14 00:31:59 2027 GMT
        Subject: C=TG, ST=Togo, L=Lome, O=Private company, CN=*
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:f8:6a:84:f0:58:03:74:50:13:cc:e7:9e:af:
                    29:c1:52:05:c1:e4:12:32:d3:e3:f1:b1:d7:d3:8d:
                    a0:4c:48:95:92:b3:c0:91:e6:1a:88:1d:4f:8b:ed:
                    07:a5:d6:f1:fc:55:0a:c6:df:11:de:09:52:7e:d5:
                    41:c2:da:23:e0:17:fe:91:42:77:96:c6:ca:f4:fc:
                    b3:f2:7d:0f:b2:9a:69:65:93:b2:60:4f:f4:fb:a4:
                    0e:0e:52:5e:e0:e3:3d:3a:40:5a:d4:d6:f1:d6:d6:
                    19:7b:7a:d3:76:9a:4e:06:f9:94:68:06:72:05:92:
                    0d:0d:3b:73:b4:75:0c:dd:6d:92:1f:11:1d:64:0c:
                    20:e7:8f:43:87:d6:6f:53:c5:c4:0b:0a:e5:e6:c8:
                    35:0f:d9:6e:aa:1c:3f:39:4c:bf:e2:a5:8f:89:c0:
                    29:93:64:67:af:d8:52:b6:34:b4:f0:5e:91:e8:4a:
                    79:13:ce:6a:50:c7:a0:e6:aa:0a:03:62:ae:5b:69:
                    17:02:fa:97:32:40:4e:5e:2f:be:9e:ad:47:f4:ec:
                    f7:43:66:b3:9a:62:ba:cc:9e:2c:d0:90:49:2e:32:
                    6e:2a:1f:a3:d3:6c:32:28:1c:f4:12:f5:0b:74:a6:
                    a2:3d:ce:f7:f7:91:74:95:70:30:1b:39:53:ad:21:
                    bb:79
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                5D:5C:D7:4B:B3:B1:78:32:24:7F:C2:C1:5F:BD:AC:59:2E:51:9B:97
            X509v3 Authority Key Identifier: 
                keyid:5D:5C:D7:4B:B3:B1:78:32:24:7F:C2:C1:5F:BD:AC:59:2E:51:9B:97

            X509v3 Basic Constraints: 
                CA:TRUE
            X509v3 Subject Alternative Name: 
                DNS:*, DNS:*.*, DNS:*.*.*, DNS:*.*.*.*, DNS:*.*.*.*.*, DNS:*.*.*.*.*.*, DNS:*.*.*.*.*.*.*, IP Address:192.168.122.81
    Signature Algorithm: sha1WithRSAEncryption
         4f:3c:d1:b2:43:98:68:9d:2a:1b:80:22:b0:84:9a:d9:6c:4f:
         fa:57:05:3e:d0:5f:30:45:2f:43:01:39:2a:41:b9:c1:46:0a:
         b3:0b:67:44:37:c2:4a:03:2a:cb:97:a2:c7:78:91:41:86:32:
         fa:50:85:71:2c:13:e5:da:ed:f7:d7:0a:10:83:5a:9f:e7:ee:
         38:c0:8f:09:bf:fc:c1:e9:72:91:02:86:be:92:52:6f:89:0b:
         c6:8a:61:11:67:4d:4f:1e:93:84:08:93:df:1f:04:04:88:57:
         2e:9f:de:04:0c:f2:50:75:04:c6:ef:66:e1:ad:e2:16:41:a7:
         04:e1:fc:d4:81:ee:53:f8:50:01:33:93:13:a5:81:95:64:fc:
         a3:b3:a5:75:3e:76:07:57:08:4b:a5:c2:17:fc:9c:60:5a:35:
         39:b1:b0:2f:24:d8:10:fa:d2:c6:3f:65:94:f0:1a:a5:6e:e8:
         cd:c8:68:ba:a5:ad:af:7d:b1:2b:e0:2a:7d:36:39:58:c0:b0:
         d8:38:70:b7:b4:87:45:e4:b7:79:c5:da:2a:5b:9a:6c:4c:e9:
         88:7d:e9:b6:5a:15:4b:8e:c8:28:4b:e3:61:2e:d0:22:0e:47:
         b4:14:b0:35:72:df:7a:02:65:b6:4c:9e:6b:bb:b2:74:a4:c9:
         d8:2d:59:a1
(Andrew Kroh) #3

certificate_authorities is supposed to be list. I'm surprised that it even loaded your configuration file.

certificate_key isn't an option.

Please review the options: https://www.elastic.co/guide/en/beats/filebeat/current/configuration-output-ssl.html

1 Like
(Will Foster) #4

Ah yes, it's strange it loaded. I think not using a list was part of it for certificate_authorities

It is working now, I also had to add key: and certificate: as well but it's sending logs now.

ssl:
  certificate_authorities: [/etc/filebeat/filebeat-forwarder.crt]
  certificate: "/etc/pki/tls/certs/filebeat-forwarder.crt"
  key: "/etc/filebeat/filebeat-forwarder.key"

All good now!

2017-02-16T16:56:56Z DBG  Publish: {
  "@timestamp": "2017-02-16T16:56:56.784Z",
  "beat": {
    "hostname": "host-02",
    "name": "host-02",
    "version": "5.2.1"
  },
  "input_type": "log",
  "message": "Feb 16 15:48:58 Updated: libgcc-4.8.5-11.el7.x86_64",
  "offset": 6035,
  "source": "/var/log/yum.log",
  "type": "syslog"

Thank you!

(system) closed #5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.