Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logstash 5.0.0-alpha5 - Can no longer connect to beats input #5756

Closed
ceeeekay opened this issue Aug 11, 2016 · 10 comments
Closed

Logstash 5.0.0-alpha5 - Can no longer connect to beats input #5756

ceeeekay opened this issue Aug 11, 2016 · 10 comments

Comments

@ceeeekay
Copy link

ceeeekay commented Aug 11, 2016

Upgrading from Logstash 5.0.0-alpha4 to Logstash 5.0.0-alpha5, filebeat clients can no longer connect to the beats input.

2016/08/11 00:06:24.596939 single.go:140: INFO Connecting error publishing events (retrying): read tcp 10.2.15.11:57029->10.2.15.21:10514: read: connection reset by peer

Example configs:

input {
  beats {
    port            => 10514
    ssl             => true
    ssl_certificate => "/etc/logstash/ssl/certs/dev-beats-ca.pem"
    ssl_key         => "/etc/logstash/ssl/private_keys/dev-beats-key.pem"
    type            => "beats"
  }
}

output {
  stdout {
    codec => rubydebug
  }
}
filebeat:
  spool_size: 1
  registry_file: /var/lib/filebeat/registry
  config_dir: /etc/filebeat/conf.d/
output:
  logstash:
    enabled: true
    hosts: ["10.2.15.21:10514"]
    tls:
      disabled: false
      certificate_authorities: ["/etc/filebeat/dev-beats-ca.pem"]
      insecure: false

Prospectors are in the conf.d directory above, but aren't relevant here.

According to netstat the service is definitely listening on tcp/10514, and these configs were previously working with alpha4.

There is no mention of the error that I can see running Logstash with debug logging.

Fresh install of Logstash (dpkg purge, rm) does not change the behaviour.

@ceeeekay
Copy link
Author

Sorry, forgot the system stuff:

Ubuntu 14.04.4
logstash 1:5.0.0~alpha5-1
logstash-input-beats (3.1.0.beta4)
filebeat 5.0.0-alpha5 and 1.2.3

@ph
Copy link
Contributor

ph commented Aug 11, 2016

@ceeeekay thanks for reporting this, beats input was completely rewritten from scratch in Java between the 2 alphas

So theses report are critical to us!

I have a few questions:

  • I presume this is a test environment, could you test without your certificates?
  • no errors on the Logstash side at all?

@ceeeekay
Copy link
Author

Hi @ph

I can connect fine with SSL disabled.

I can also reproduce the fault elsewhere with SSL enabled. I've checked the alt names and expiry on the cert and they're all fine (and this was working prior to upgrading to alpha5).

I don't know if this is useful info but even trying to telnet to the beats port on an affected machine results in the connection being closed immediately, still with no errors logged in LS:

# telnet localhost 10514
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

@ph
Copy link
Contributor

ph commented Aug 16, 2016

@ceeeekay I did not get luck into reproducing this error but I want to get to the end of this.

it is possible to provide this:

  • The command line you used to generate the certificate
  • A certificate/private key to reproduce the issue

This would help me a lot.

Thanks

@ceeeekay
Copy link
Author

ceeeekay commented Aug 17, 2016

Hi @ph

I've tried to go back to the beginning and create a new SSL key so I can give you the exact steps to reproduce, however I can't even get alpha5 to start with this new key, although it works fine with 2.3.4 (logstash-input-beats 2.2.9).

The error displayed by LS alpha5 is:
An unexpected error occurred! {:error=>#<NoMethodError: undefined method stop' for nil:NilClass>, :backtrace=>["/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-beats-3.1.0.beta4-java/lib/logstash/inputs/beats.rb:173:in stop'", "/usr/share/logstash/logstash-core/lib/logstash/inputs/base.rb:88:in do_stop'", "org/jruby/RubyArray.java:1613:in each'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:366:in shutdown'", "/usr/share/logstash/logstash-core/lib/logstash/agent.rb:252:in stop_pipeline'", "/usr/share/logstash/logstash-core/lib/logstash/agent.rb:261:in shutdown_pipelines'", "org/jruby/RubyHash.java:1342:in each'", "/usr/share/logstash/logstash-core/lib/logstash/agent.rb:261:in shutdown_pipelines'", "/usr/share/logstash/logstash-core/lib/logstash/agent.rb:123:in shutdown'", "/usr/share/logstash/logstash-core/lib/logstash/runner.rb:237:in execute'", "/usr/share/logstash/vendor/bundle/jruby/1.9/gems/clamp-0.6.5/lib/clamp/command.rb:67:in run'", "/usr/share/logstash/logstash-core/lib/logstash/runner.rb:157:in run'", "/usr/share/logstash/vendor/bundle/jruby/1.9/gems/clamp-0.6.5/lib/clamp/command.rb:132:in run'", "/usr/share/logstash/lib/bootstrap/environment.rb:66:in (root)'"], :level=>:fatal}`

We're using alt names as we're sending to multiple LS nodes.

Here's the ssl command used to generate the key & cert:
openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout dev-beats-key.pem -out dev-beats-ca.pem

And these changes at the bottom of openssl.cnf:

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = dev-ingress1
DNS.2 = dev-ingress2

Are you able to reproduce this latest error?

@ceeeekay
Copy link
Author

ceeeekay commented Aug 17, 2016

Hi again @ph

I've spotted an error with the openssl config above and found it wasn't referring to the v3_req section, which was causing the startup error with alpha5 - although I'm not sure why that was upsetting it.

I now have a cert/key pair which Logstash is happy to start with, however I'm still getting the original connection reset issue with them.

Happy to provide these to you as they were only generated for this test.

-----BEGIN CERTIFICATE-----
MIID/TCCAuWgAwIBAgIJAIoUtq6Z64sTMA0GCSqGSIb3DQEBCwUAMHoxCzAJBgNV
BAYTAlhYMQ0wCwYDVQQIDAR0ZXN0MQ0wCwYDVQQHDAR0ZXN0MQ0wCwYDVQQKDAR0
ZXN0MQ0wCwYDVQQLDAR0ZXN0MRIwEAYDVQQDDAlsb2NhbGhvc3QxGzAZBgkqhkiG
9w0BCQEWDHRlc3RAdGVzdC54eDAeFw0xNjA4MTcwMTM3NTdaFw0yNjA4MTUwMTM3
NTdaMHoxCzAJBgNVBAYTAlhYMQ0wCwYDVQQIDAR0ZXN0MQ0wCwYDVQQHDAR0ZXN0
MQ0wCwYDVQQKDAR0ZXN0MQ0wCwYDVQQLDAR0ZXN0MRIwEAYDVQQDDAlsb2NhbGhv
c3QxGzAZBgkqhkiG9w0BCQEWDHRlc3RAdGVzdC54eDCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAOG/o1rxpQW/UJnsdkTWxoqGAn/Hdhuw4ZTx3sRRGRjk
k0tm/VEFjqc3O6KY6Di7LQ0PnwX3/zg3n/y9007dDZ1JIz/U9SNRMwEfrqzPoq/8
7v0APnTxAx+vmV175DwqSPqTGyEq1Q3wmZjSCU6G8b+tgbNpCytwGo+Kj+7fCE1Y
IyvtJNMdl5hv47ChL+Rxre1ilkZ5x0TLnn8nUOIdRQmT2uuwyJe2rp+aQ/IwlDHL
48vF7D2jNrq/Wkbr3oOqMZye9MB4oBfRCZ25CYPTnz5xWiQZ7znIWycrUeHz/s6A
kbnIoE8Cu1iTs+CzfbjPQXwA9+glgkmnthOp3QSmP98CAwEAAaOBhTCBgjALBgNV
HQ8EBAMCBeAwJQYDVR0RBB4wHIIJbG9jYWxob3N0gg9zb21lLW90aGVyLWhvc3Qw
HQYDVR0OBBYEFITBLZluTu+wnBoMuaquT23rt2WaMB8GA1UdIwQYMBaAFITBLZlu
Tu+wnBoMuaquT23rt2WaMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
AIAozWgjEus/Lz/iIdC1MGtsp5Fe9DPb40xE7YAnCeWntp3rpOS6nxFlMhs7lAzQ
iRwa7hEz0WG9Y2zOZN2bGxxhaZhcfcg622FkQrxSDyCCWEvYmQHmvPXeeVCsm0ug
KHmzNf8RkUvojmEi55AuiqIWiP0T+1+cUhxEwzQSTYsyjoOZciSGD0KJrjQTIXo8
gh3rTtasZqyMwHQAINbyMKOIQoJc8qgxWy2b0u5qIf0l0stkAoW+ZAwsMEe/Hbpv
1IXRfFYBFw4qYasRwUCiJwUw2f5YasszXirMZNGM3Kmcii2/UT+wzTmyCTfHd0QR
nOPIvvPsUyzZmP2HfLRzmv0=
-----END CERTIFICATE-----

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDhv6Na8aUFv1CZ
7HZE1saKhgJ/x3YbsOGU8d7EURkY5JNLZv1RBY6nNzuimOg4uy0ND58F9/84N5/8
vdNO3Q2dSSM/1PUjUTMBH66sz6Kv/O79AD508QMfr5lde+Q8Kkj6kxshKtUN8JmY
0glOhvG/rYGzaQsrcBqPio/u3whNWCMr7STTHZeYb+OwoS/kca3tYpZGecdEy55/
J1DiHUUJk9rrsMiXtq6fmkPyMJQxy+PLxew9oza6v1pG696DqjGcnvTAeKAX0Qmd
uQmD058+cVokGe85yFsnK1Hh8/7OgJG5yKBPArtYk7Pgs324z0F8APfoJYJJp7YT
qd0Epj/fAgMBAAECggEAM+1kAxBgmEDYpn9o+Q66XrTSsFfOSDJYwW0dg+Tvs/Uo
GIkZLeDsXnRrCEzJ5frQMxfryXCxSVoqN/XmPFbGwe5H6G/w723HILQL9v5P+tFg
m9vJghbKVCiNS56q8lf7r3/VFr0Ggw1cF3YA5ApQY3niwsUf558CzQ/fad/txfRY
kGIMWJ7R8xGuG2iCSMT3133XKOhSZLvhviQnx08Gakcz25Gxmu/jA24g6fL+L8D/
15s6geJp4/nz91UZN9KBzo2VO9g7D3r3BolI78ljWEdDOcG8WqcKWOr9P8ooszaL
55O/YSYqobUdaETmW3pfiY5AvCbpNwjxT2M60XhMWQKBgQDzIMKuEvxcKTK7jsR8
Ksp+RnTIgH6gSnoMUMOZzN6d1zFQTixOMJXSGJ8eSmCUIswFSk8leJi0zxl2YZs2
2lyOpm2FOcHjo16rbIAKZK4qg3Q8YMMIlZmhou/hDDnQrGfX2BCDry1Uq6XRbbn4
wbejuQq2QfEB925UlHQ/d2/RRQKBgQDts1NpVy4Cfx+FRpVMihDexvHm/tydK349
7y9lTtVNj9voZHdmM2kaSNemPXUT3RZCCuEQNsCSn7mocBJoTcJgHtc/yIKe6VlG
/JdFcSD0HcLk7L3cBWnSOcdIXwA4vY915tHSq6kdyryM9NiQa+W5PUBKvp0nUhpD
sDWpstv00wKBgQC250NuH3xYfOncrdflLW/utWRv3jLktYLBtxSfpL8o8VX4+wZb
wDNFvh4edIfZiaAArtmB8Aq5oz+djmptRrLw4gVsf3n8nc+/mL1ulDVuaDxOm+C9
mYXdUq2xmTf5Y2ovuC0cU/H/S65QMoMAwAM+GRwU5uC/wPvwh0o44MpvHQKBgCRr
GjeEhOcbBQBNbSh56tXHE17542EtPb1NfSx/ZIzqop27btO4wrylNm0g82QktnlN
42exi9WrJS3aZeeXKlXBw+bg2KpyRBxtLNwV1h+ww6CBaSFhrvHnqlG7RHRtDqLY
x4MIi/OlkTfjd57A+URlTwlkpP1WRfHi+IXUgoDDAoGASX8IJQoqycE63XoO8wuY
pYikb2yhnd9YWQ2gKSeKHBkAqeGYukiS9RIf72FnjzjELQl4wvgadKuI29aa7Zwx
TotarvHU1JKGFA1FVxYE4RlPQt8uaw4jw0kgIsZ2WruadA5v/apYsEFA8xCybp4T
oSZlxLbGDPNlM9IegtpIIAc=
-----END PRIVATE KEY-----

Cheers.

@ph
Copy link
Contributor

ph commented Aug 19, 2016

I am working on making theses errors more expliticit, expect a new version soon :)
Thanks for keeping the thread up to date.

@ph
Copy link
Contributor

ph commented Aug 22, 2016

OK with have with this certificate a NullPointerException in the SSLSimpleBuilder class.

Exception in thread "main" java.lang.NullPointerException
    at org.logstash.netty.PrivateKeyConverter.generatePkcs8(PrivateKeyConverter.java:43)
    at org.logstash.netty.PrivateKeyConverter.convert(PrivateKeyConverter.java:39)
    at org.logstash.beats.Runner.main(Runner.java:39)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

@ph
Copy link
Contributor

ph commented Aug 22, 2016


```
     * Returns the name of the primary encoding format of this key,
     * or null if this key does not support encoding.
```

The main problem is the PemReader cannot correctly read the provided files.

@ph
Copy link
Contributor

ph commented Aug 22, 2016

Actually there is 3 errors in this scenario.

  1. the ssl error are not correctly send back to the user.
  2. The PKCS8 handling was only taking care of PemKeyPair and not PrivateKeyInfo
  3. After fixing the 2 issues above we still get found no certificates in input stream, path is OK, c
    content is there. (Even if the crt is currently expired it should find it)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants