Hey,
I enabled encrypted HTTP client connections via TLS, following this guide:
https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-tls.html#tls-http.
However, now I cannot connect to the Elasticsearch-node anymore and there are no logs indicating an error.
Thus, my question: Do I need client certificates or can I just use: https://my-domain.com:9200
Thanks.
Best regards,
Florian
What do you mean then "you can't connect" ? What do you try, what happens and what would you expect instead ?
Usually not, but that depends on how you have configured elasticsearch, so we cant really know. Can you share your configuration with us ?
To your first question:
In the end I simply want to send data from a custom beat to elasticsearch that is hosted in Microsoft Azure. This connection should be encrypted.
As a first step I enabled encrypted HTTP connection in elasticsearch. Via Postman I now tried to check, if i can still reach elasticsearch. However, elasticsearch does not respond to a simple HTTPS request.
Before that, when HTTPS is not enabled, I got the following respond to a HTTP request:
{
"name": "heartbeats",
"cluster_name": "my-application",
"cluster_uuid": "mHkVAtwcSXWNHIL0Xm-zZQ",
"version": {
"number": "7.3.1",
"build_flavor": "default",
"build_type": "deb",
"build_hash": "4749ba6",
"build_date": "2019-08-19T20:19:25.651794Z",
"build_snapshot": false,
"lucene_version": "8.1.0",
"minimum_wire_compatibility_version": "6.8.0",
"minimum_index_compatibility_version": "6.0.0-beta1"
},
"tagline": "You Know, for Search"
}
I expected the same respond when connecting to elasticsearch via HTTPS.
However, this is the respond after I enabled ssl encryption:
Could not get any response
There was an error connecting to .
Why this might have happened:
- The server couldn't send a response:
Ensure that the backend is working properly- Self-signed SSL certificates are being blocked:
Fix this by turning off 'SSL certificate verification' in Settings > General- Proxy configured incorrectly
Ensure that proxy is configured correctly in Settings > Proxy- Request timeout:
Change request timeout in Settings > General
To your second question:
These are the contents of my elasticsearch.yml file
cluster.name: my-application
node.name: heartbeats
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 127.0.0.1
http.host: 10.0.0.5
http.port: 9200
cluster.initial_master_nodes: ["heartbeats"]
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.http.ssl.truststore.path: certs/elastic-certificates.p12
Please don't post images of text as they are hard to read, may not display correctly for everyone, and are not searchable.
Instead, paste the text and format it with </> icon or pairs of triple backticks (```), and check the preview window to make sure it's properly formatted before posting it. This makes it more likely that your question will receive a useful answer.
It would be great if you could update your post to solve this.
Postman says:
Self signed SSL certificates are being blocked
and you use self signed SSL certificates. So please follow the instructions that Postman has
I did that already. I still get no response.
let's leave postman out of the equation for a while so that we don't end up troubleshooting another software.
What is the IP address or the hostname that your elasticsearch node is accessible at ?
Do a
curl -k -u username:password -X GET https://IP_ADDRESS
-k is so that curl would not try to validate your certificate
username:password use for example the elastic user and its password assuming you also went through and did this: https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-security.html too.
Sry, I dont want to publish that here. I'll just refer to as my-address.com
After doing the curl request I get the following respond:
curl: (7) Failed to connect to my-address.com port 9200: Timed out
What might be interesting is, when I request http://my-address.com:9200 instead of https://my-address.com:9200, the following log is being generated:
io.netty.handler.codec.DecoderException: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: ...
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:472) ~[netty-codec-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:278) ~[netty-codec-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1408) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:682) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:582) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:536) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:906) [netty-common-4.1.36.Final.jar:4.1.36.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.36.Final.jar:4.1.36.Final]
at java.lang.Thread.run(Thread.java:835) [?:?]
So I mean, the node is listening and registers, if you try to connect non-encrypted.
Sure, I didn't actually want to know. It was just a question so that I can then ask you to hit the same IP/hostname with curl 
This is elasticsearch saying that someone attempted to connect to it over http, while it expected a connection over https . By the way, that is just your request HEX encoded so it contains the hostname your ES instance is listening on, so you might want to sanitize your post above.
Since the same port is used for http and https, if it is listening , it is listening It wouldn't stop listening depending on the incoming connection. It would throw an error if it can't handle it.
I happened to notice that the example from the logs you share above is from a request with postman also. Are you running postman and curl from the same machine? Can you also make a request with curl to plain http ? Does it also reach Elasticsearch ?
curl -k -u username:password -X GET http://hostname:9200
Hey, sorry for the delay.
Now when I curl -k -X GET https://hostname:9200 I receive:
{
"name": "heartbeats",
"cluster_name": "my-application",
"cluster_uuid": "mHkVAtwcSXWNHIL0Xm-zZQ",
"version": {
"number": "7.3.1",
"build_flavor": "default",
"build_type": "deb",
"build_hash": "4749ba6",
"build_date": "2019-08-19T20:19:25.651794Z",
"build_snapshot": false,
"lucene_version": "8.1.0",
"minimum_wire_compatibility_version": "6.8.0",
"minimum_index_compatibility_version": "6.0.0-beta1"
},
"tagline": "You Know, for Search"
}
So, exactly what I want.
When I curl -k -X GET http://hostname.com:9200, I receive:
curl: (52) Empty reply from server
It still reaches Elasticsearch, as I get the same log message as with Postman.
[2019-09-04T09:16:17,994][WARN ][o.e.h.AbstractHttpServerTransport] [heartbeats] caught exception w$io.netty.handler.codec.DecoderException: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS$ at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:472) ~[$ at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:278) ~$ at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerC$ at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerC$ at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerCon$ at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.j$ at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerC$ at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerC$ at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930)$ at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.ja$ at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:682) [netty-trans$ at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:582) [netty$ at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:536) [netty-tran$ at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496) [netty-transport-4.1.36.Fin$ at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:$ at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-$ at java.lang.Thread.run(Thread.java:835) [?:?]
Caused by: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1206) ~[netty-handle$ at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1274) ~[netty-handler-4.1.36.Fina$ at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessage$ at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:441) ~[$ ... 16 more
Although I am able to get a reply when accessing https://hostname:9200 with curl, my custombeat still cannot connect to Elasticsearch.
From the beat output:
connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
This is my beat yml-file:
heartbeat:
period: 10s
output.elasticsearch:
hosts: ["https://hostname:9200"]
index: "heartbeats"
protocol: "https"
setup.template.name: "heartbeat"
setup.template.pattern: "heartbeat-*"
setup.ilm.enabled: false
processors:
- add_host_metadata: ~
- add_cloud_metadata: ~
Hi,
So it seems it's working fine. You have enabled TLS on the HTTP layer and you can connect over https
curl -k -X GET https://hostname:9200
but can't connect over http as expected ,and Elasticsearch complains that it is expecting communications over SSL but you send requests over plain http:
[2019-09-04T09:16:17,994][WARN ][o.e.h.AbstractHttpServerTransport] [heartbeats] caught exception w$io.netty.handler.codec.DecoderException: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS$ at
This is all expected and normal given your configuration.
I would expect there is something more in the beats logs or in the Elasticsearch logs that would explain why beats can't connect. Unless this is a network issue and the machine you run beat on, can't even reach the machine where Elasticsearch runs.
You are right, there are some more Elasticsearch logs:
[2019-09-04T09:48:09,690][WARN ][o.e.h.AbstractHttpServerTransport] [heartbeats] caught exception while handling client http traffic, closing connection Netty4HttpCh$io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:472) ~[netty-codec-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:278) ~[netty-codec-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1408) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:682) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:582) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:536) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:906) [netty-common-4.1.36.Final.jar:4.1.36.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.36.Final.jar:4.1.36.Final]
at java.lang.Thread.run(Thread.java:835) [?:?]
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at sun.security.ssl.Alert.createSSLException(Alert.java:131) ~[?:?]
at sun.security.ssl.Alert.createSSLException(Alert.java:117) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:307) ~[?:?]
at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:285) ~[?:?]
at sun.security.ssl.TransportContext.dispatch(TransportContext.java:180) ~[?:?]
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) ~[?:?]
at sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) ~[?:?]
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) ~[?:?]
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) ~[?:?]
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:433) ~[?:?]
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:634) ~[?:?]
at io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:295) ~[netty-handler-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1332) ~[netty-handler-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1227) ~[netty-handler-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1274) ~[netty-handler-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:502) ~[netty-codec-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:441) ~[netty-codec-4.1.36.Final.jar:4.1.36.Final]
... 16 more
Seems like Elasticsearch expects a certificate.
See the docs for configuring SSL in heartbeat in https://www.elastic.co/guide/en/beats/heartbeat/current/elasticsearch-output.html . You need to enable heartbeat to trust the certificate that Elasticsearch presents for TLS.
Assuming you have followed our docs as you mentioned and that the configuration you have shared above is still valid and you use
xpack.security.http.ssl.keystore.path: certs/elastic-certificates.p12
, you need to export the CA certificate from there with
openssl pkcs12 -in elastic-certificates.p12 -cacerts -nokeys | sed '/-----BEGIN CERTIFICATE-----/,$!d'> ca.crt
Now you can use this ca.crt in your Beats configuration i.e.
ssl.certificate_authorities: ["/path/to/ca.crt"]
Hope this helps
It still does not work. I get the exact same log message.
So i added
ssl.certificate: "/path/to/cert"
ssl.key: "/path/to/key"
using
openssl pkcs12 -in elastic-certificates.p12 -clcerts -nokeys > client.crt
and
openssl pkcs12 -in elastic-certificates.p12 -nocerts -nodes > client.key
I still get the same log message. However, the beat output now says:
x509: certificate is valid for instance, not hostname
You dont need ssl.key and ssl.certificate, these are for TLS client auth and your Elasticsearch instance is not configured for this. Please remove these.
It still does not work. I get the exact same log message
It's really hard for us to help out when you are not explicit. Its always better to copy paste error message and logs than describing them.
Can you share the output plugin configuration and the logs ( after you added ssl.cerificate_authorities )
The securing communication with elasticsearch part of the documentation might also be helpful for your understanding
This happens after I added ssl.cerificate_authorities:
Output plugin configuration
output.elasticsearch:
hosts: ["https://hostname:9200"]
index: "heartbeats"
ssl.cerificate_authorities: ['C:\Users\my-name\go\src\github.com\your-github-name\heartbeat\ca.crt']
protocol: "https"
Elasticsearch log output:
[2019-09-04T13:09:18,680][WARN ][o.e.h.AbstractHttpServerTransport] [heartbeats] caught exception while handling client http traffic, closing connection Netty4HttpChannel{localAddress=0.0.0.0/0.0.0.0:9200, remoteAddress=/my_address:1$io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:472) ~[netty-codec-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:278) ~[netty-codec-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1408) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:682) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:582) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:536) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496) [netty-transport-4.1.36.Final.jar:4.1.36.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:906) [netty-common-4.1.36.Final.jar:4.1.36.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.36.Final.jar:4.1.36.Final]
at java.lang.Thread.run(Thread.java:835) [?:?]
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at sun.security.ssl.Alert.createSSLException(Alert.java:131) ~[?:?]
at sun.security.ssl.Alert.createSSLException(Alert.java:117) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:307) ~[?:?]
at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:285) ~[?:?]
at sun.security.ssl.TransportContext.dispatch(TransportContext.java:180) ~[?:?]
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) ~[?:?]
at sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) ~[?:?]
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) ~[?:?]
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) ~[?:?]
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:433) ~[?:?]
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:634) ~[?:?]
at io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:295) ~[netty-handler-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1332) ~[netty-handler-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1227) ~[netty-handler-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1274) ~[netty-handler-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:502) ~[netty-codec-4.1.36.Final.jar:4.1.36.Final]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:441) ~[netty-codec-4.1.36.Final.jar:4.1.36.Final]
... 16 more
Beat output:
x509: certificate is valid for instance, not hostname
Can you please read the note in the end of the beats documentation page that I shared with you in my previous post ?
Thank you. That helped.
After creating the certificates for a specific domain, like:
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 --dns hostname.com
it works.
Awesome, glad to hear that!
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.