Error installing Elastic-Agent v7.10.0

Elastic Security
,
1

Hi,

I am trying ELK 7.10.0 and it's beats. I have successfully installed the Elastic-Agent 7.10.0 in two machines, running Win 10 and Win 10 Pro, but I am unable to install the same agent on a machine running Windows Server 2012 R2. When I try to install the Elastic-Agent I get this error:

2020-12-09T09:31:56.448-0500    DEBUG   kibana/client.go:170    Request method: POST, path: /api/fleet/agents/enroll
Error: fail to enroll: fail to execute request to Kibana: Post "https://192.168.1.170:5601/api/fleet/agents/enroll?": x5
09: certificate is valid for 127.0.0.1, 192.168.1.170, not 192.168.1.170
Error: enroll command failed with exit code: 1

This error does not make any sense to me, since it says the certificate is valid for machine with IP 192.168.1.170, not 192.168.1.170 (same machine and same IP).

On the other machines I did not get this error. Installation ran smoothly.

I already tried the manual installation of the CA certificate before running the Elastic-Agent installation script, but the issue persist.

Please help!

Thank you

2

Hi,

Is there any update about this report?

Thank you

3

@ManuelF This seems to be an issue with golang and Windows, I have filled a bug on Elastic side so we can track it. This will most likely require a new golang release that fixes the issue, before we can get the fix into Elastic Agent.

Possible workaround would be to use a hostname/domain to generate the certificate and communicate with the server using the name instead of IP address.

https://github.com/elastic/beats/issues/23172

4

Hi @blaker and thank you for your interest. I hope the future version can correct this issue. In the meantime the workaround that I ended up using was installing the agent with the "insecure" flag.

.\elastic-agent.exe install -f -i --kibana-url=https://192.168.1.170:5601 --enrollment-token=Y21ybktYWUJWalhhdftdSETMKSYysyYRRpry1VfRHZUV2VHUUZXZkRYUkRPUQ==

The agent was installed, but I have a constant warning in ES logs regarding the connection from that machine. This does not prevent the machine from checking in with Security and Fleet:

[2020-12-16T11:09:29,167][WARN ][o.e.h.AbstractHttpServerTransport] [IDSMini] caught exception while handling client http traffic, closing connection Netty4HttpChannel{localAddress=/192.168.1.170:9200, remoteAddress=/192.168.1.233:56491}
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471) ~[netty-codec-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) ~[netty-codec-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:615) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:578) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-common-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.49.Final.jar:4.1.49.Final]
        at java.lang.Thread.run(Thread.java:832) [?:?]
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:356) ~[?:?]
        at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293) ~[?:?]
        at sun.security.ssl.TransportContext.dispatch(TransportContext.java:202) ~[?:?]
        at sun.security.ssl.SSLTransport.decode(SSLTransport.java:171) ~[?:?]
        at sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736) ~[?:?]
        at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691) ~[?:?]
        at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506) ~[?:?]
        at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482) ~[?:?]
        at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:637) ~[?:?]
        at io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:282) ~[netty-handler-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1372) ~[netty-handler-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1267) ~[netty-handler-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1314) ~[netty-handler-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:501) ~[netty-codec-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:440) ~[netty-codec-4.1.49.Final.jar:4.1.49.Final]
        ... 16 more
5

@ManuelF What does the logs on the client-side look like? You might need to tell Fleet in Kibana to also be insecure. If you enroll with --insecure that will only affect the Elastic Agent communication to Kibana. It is not pushed to the connection to elasticsearch on that host.