ElasticAgent enrolled with Fleet server - Connection failure Elastic Defend

Dear all,

I've installed Elasticsearch, kibana and a Fleet server on a Ubuntu machine for Security testing. The main goal is to install the elastic agent with the Defend integration for XDR on a Windows machine.

The installation of Elastic, Kibana and Fleet were successful, but when I tried to install the agent, it seems not working for a "connection failure" (based in the agent from Fleet section on Kibana portal.

Trying to troubleshoot I found this information running the elastic-agent test output command:

Elasticsearch server: https://<IP_address>:9200
Status: SSL peer certificate or SSH remote key was not OK [SSL certificate problem: unable to get local issuer certificate]
Help: Host needs to trust server cert or server cert needs to be added to Elasticsearch/Fleet config

When I enrolled the elastic agent I've used the --insecure flag because I have SSL certificate selfsigned, what I'm missing?

Thanks.

Hello and welcome,

How did you install it? Did you change the defaul installation path?

Hi,

no, is the default one, but at the same time others integration are not sending logs:

  1. For the installation I've installed first elasticsearch, then kibana on the same host, creating the different ssl certificate (self-signed) and I can connect and elastic can reach Kibana as well.
  2. The installation of the fleet server is healty, but I cannot see any logs coming from system integration. The path where Kibana and ES are installed are the default (/etc/..., /usr/share/....)

When I try to check the winlog from System integration is empty....

So, no integrations are sending any log?

What does output looks like? In the Fleet UI go to Settings and share a screenshot.

Hi,

I can post only a screenshot for post :smiley: , btw this is what I see, no one are sending logs but are configured only 2 agent:

  • Ubuntu-siem-2 (healthy) is the Fleet server, where is implemented System integration (is healthy, but I don't see any log)
  • cb-web-01: windows server 2016 with System + Defend (no one are sending logs)

Are those hosts able to reach the Elasticsearch IP?

If they are able to reach the destination ip you will need to check the logs of the agents for any errors.

They will be in the default folder on a path like this: Agent/data/elastic-agent-someHash/logs

Hi,

the fleet-server gives healthy status, instead of windows machine.
I've checked the logs and for the windows machine, the "system" folder under logs is empty, the only files that I have for logs are base don this error:

{"log.level":"error","@timestamp":"2024-10-22T12:53:56.139Z","message":"Error dialing x509: certificate signed by unknown authority","component":{"binary":"filebeat","dataset":"elastic_agent.filebeat","id":"filestream-monitoring","type":"filestream"},"log":{"source":"filestream-monitoring"},"log.logger":"esclientleg","service.name":"filebeat","network":"tcp","address":"172.16.205.11:9200","log.origin":{"file.line":39,"file.name":"transport/logging.go","function":"github.com/elastic/elastic-agent-libs/transport/httpcommon.(*HTTPTransportSettings).RoundTripper.LoggingDialer.func2"},"ecs.version":"1.6.0","ecs.version":"1.6.0"}

I've used the --insecure for the installation of the agent :thinking: for bypass this point....

Edit:

I tried to reinstall the Elastic-agent with the fleet enroll and passing again the --insecure flag, but nothing changed:

in the logs is present the same error and from the portal the incoming data still pending:

Command used:

.\elastic-agent.exe install --url=https://<IP_ADDRESS>:8220 --enrollment-token=<ENROLLMENT_TOKEN> --insecure

Should I add something related to certificate for connect to elasticsearch?
Any suggestions?

Since you needed to use --insecure, I wonder if you also need to disable certificate validation for the output connection. --insecure controls validation of the connection from Agent/Beats/Endpoint to Fleet Server, the output configuration controls the connection to Elasticsearch.

What I mean is to go to Fleet -> Settings then Edit the configuration for the Elasticsearch output your Agent's are using. In the Advanced YAML configuration see if the below verification_mode YAML solves your problem. If it does, then of course make a decision for yourself if that's acceptable long term or it has just proven you will be in good shape once you update your certificate.

ssl:
  verification_mode: none