Windows Agent cannot connect to master to fetch certificate

Good morning everybody,

I don’t know why I am running into the following problem at the moment:

I have several windows agents within the same domain, which are already connected to my Icinga master. Now I want to add another agent from the same domain, the connectivity between master and agent is given, I checked it via ping. I configured the new agent on the master in the exact same way as all the other agents (see below) and run the setup on the client in the same way as well, but when trying to fetch the certificate from the master, it always times out. Is there any way to debug this or are there any faulty configurations I am obviously missing here?

This is the relevant part of my zones.conf on the master

object Endpoint ""{
        host = ""

object Zone ""{
        endpoints = [ "" ]
        parent = "master"

This is the agent’s config file on the master:

object Host ""{
        check_command = "hostalive"
        address = ""
        zone = "master"
        vars.client_endpoint = name //follows the convention that host name == endpoint name
        vars.os = "windows"
        vars.nscp_api_password = "abcd1234"


And my setup on the agent’s site of things looks as follows:

Finally, the error I am getting after Checking certificate... is

    Retrieving C.509 certificate for ''.
    Cannot connect to host '' on port '5665'.
Failed to fetch certificate from host.

Any help would be appreciated.


The agent needs to be able to connect on the master host via port 5665. That’s different to sending a ping packet. Can you verify that this route works?


well, thats true of course. I assumed it would work since all identical setups from the same subnet are able to connect to master:5665. Turns out, this particular host can not connect to master:5665, I tested it via the Test-NetConnection cmdlet.

Any hints on what could cause this?

Firewall on the master, packet filter on the network in between, etc. Best is to check with your network team.


It turned out that the agent in question had recently been configured for multihoming and used a different IP for communicating with Icinga now. So it was a firewall issue indeed.

1 Like