Hello Icinga Community,
does anybody know if there is a way to make a node setup for a agent without a connection from the agent to the master? We would like to only allow the connection from the master to the agent node what works pretty well for the monitoring but I can not find a way to make the node setup without a connection from the agent node to the master cluster once?
Best regards,
Alicia
You can create the certificates manually on the master (in a directory which is writable for the icinga user)
icinga2 pki new-cert --cn server.foo.bar --key server.foo.bar.key --csr server.foo.bar.csr
icinga2 pki sign-csr --csr server.foo.bar.csr --cert server.foo.bar.crt
and then copy the certificate and the key into /var/lib/icinga2/certs on the agent node
The ca.crt from /var/lib/icinga2/ca may be needed as well.
Make sure that the cn in the certificate matches the fqdn of the machine and the certs are readable for icinga2.
After that, write a proper constants.conf and zones.conf and you are all set.
Hi,
since Icinga 2.8 you don’t need access to the server anymore to use the node wizard. The only thing you need is the ca.crt on your Client.
Read this for more information: https://icinga.com/2017/11/13/how-to-icinga-2-ca-proxy/
Thank you both for the replies 
Ok, that way is a lot of individual work but I will try it, if there is no integrated way with the icinga2 node setup
Yes that was my hope. So we tried it today with that:
icinga2 node setup \
--cn $CN \
--endpoint $ENDPOINT \
--endpoint $ENDPOINT2 \
--zone $CN \
--parent_zone master \
--parent_host $MASTER \
--trustedcert /var/lib/icinga2/certs/trusted-parent.crt \
--accept-commands --accept-config \
--disable-confd
but we got the following error:
information/cli: Verifying parent host connection information: host 'master1.domain.com', port '5665'.
information/cli: Using the following CN (defaults to FQDN): 'agent-server.domain.com'.
information/cli: Backup file '/var/lib/icinga2/certs//agent-server.domain.com.key.orig' already exists. Skipping backup.
information/cli: Backup file '/var/lib/icinga2/certs//agent-server.domain.com.crt.orig' already exists. Skipping backup.
information/base: Writing private key to '/var/lib/icinga2/certs//agent-server.domain.com.key'.
information/base: Writing X509 certificate to '/var/lib/icinga2/certs//agent-server.domain.com.crt'.
information/cli: Verifying trusted certificate file '/var/lib/icinga2/certs/trusted-parent.crt'.
information/cli: Requesting a signed certificate from the parent Icinga node.
critical/cli: Cannot connect to host 'master1.domain.com' on port '5665'
critical/cli: Failed to fetch signed certificate from parent Icinga node 'master1.domain.com, 5665'. Please try again.
So for me it looks like the server would need to conntect the master once to request the signed certificate?
try it with manually with node wizard on the agent and see if that works. I’am pretty sure your parameters are wrong, as you need to tell the setup that you want to use the CAProxy Feature somehow… I’am only using the Agent on Windowsservers with the powershell framework/module, so the parameters are different.
If you omit the --parent_host parameter, the CLI command will not attempt to connect to the parent endpoint for sending the signing request. Instead, you are asked to put the public ca.crt manually into /var/lib/icinga2/certs. The same method exists within the node wizard CLI command.
Excerpt from the CLI command code:
/* If no parent connection was made, the user must supply the ca.crt before restarting Icinga 2.*/
if (!connectToParent) {
Log(LogWarning, "cli")
<< "No connection to the parent node was specified.\n\n"
<< "Please copy the public CA certificate from your master/satellite\n"
<< "into '" << ca << "' before starting Icinga 2.\n";
} else {
Log(LogInformation, "cli", "Make sure to restart Icinga 2.");
}
The --endpoint parameter takes care of adding the Endpoint name and host attribute, this isn’t done via --parent_host parameter in this specific case.
seems like I don’t need the CAProxy because I don’t work with a satellite.
Thanks 
that worked for the node setup I also could sign the fingerprint, but now I get some errors on the master:
information/ApiListener: Reconnecting to endpoint 'agent-server.domain.com' via host 'xxx.xxx.xxx.xxx' and port '5665'
warning/ApiListener: Certificate validation failed for endpoint 'agent-server.domain.com': code 18: self signed certificate
information/ApiListener: New client connection for identity 'agent-server.domain.com' to [xxx.xxx.xxx.xxx]:5665 (certificate validation failed: code 18: self signed certificate)
information/ApiListener: Finished reconnecting to endpoint 'agent-server.domain.com' via host 'xxx.xxx.xxx.xxx' and port '5665'
information/JsonRpcConnection: Received certificate request for CN 'agent-server.domain.com' not signed by our CA.
information/JsonRpcConnection: Sending certificate response for CN 'agent-server.domain.com' to endpoint 'agent-server.domain.com'.
warning/JsonRpcConnection: API client disconnected for identity 'agent-server.domain.com'
with a icinga2 ca list --all I can see the signed Fingerprint, seems like I have to wait for the server admin to look in his log…
What’s going on on the agent side? Always keep both logs opened.
Not so easy if you have no rights to the agent server 
but after a second restart of the icinga2 service on Agent now it works maybe the Agent needs a restart after signing the fingerprint?
But great that it now works, thank you all for your help!
@dnsmichi Do you know what icinga2 version is needed on a agent to use this way?
AFAIK 2.9 added the connection-less mode to node setup, and normally a restart is not necessary with reloading the TLS certificates in memory. But if it helps, why not.
I wouldn’t recommend to use agents older than 2.11 anyways, granted that the master is uptodate with 2.11.2.
I would recommend my collegues to use a OS which is new enough to install icinga2 in 2.11 … but that isn’t something I can change
Hi, i have the same problem that the restart is required, good to know that it exists on Linux too:
Its a problem, because if someone installs the agent via autodeploy and he has no access to Icinga, he needs to wait until the csr is signed and then he needs to restart the service. So we always have the problem, that two teams need to wait on each other.
I will open an issue for that.
I’m dealing with the same problem right now. For security reasons only the master can connect to the agent but the connection from agent to master is blocked by the firewall. So the agent can’t fetch a certificate from the master.
The agent node is running on Windows Server 2016. We don’t have satellites, just a master and several agent nodes.
I’ve tried the following based on that topic:
1. Manually created the certificate on the master and signed it
icinga2 pki new-cert --cn server.foo.bar --key server.foo.bar.key --csr server.foo.bar.csr
icinga2 pki sign-csr --csr server.foo.bar.csr --cert server.foo.bar.crt
Output files:
server.foo.bar.csr
server.foo.bar.crt
server.foo.bar.key
2. Copied those files on the agent node in C://ProgramData/icinga2/var/lib/icinga2/certs
3. From the master copied /var/lib/icinga2/ca.crt into the same folder on agent node
4. Restart icinga service on agent node
Done.
But the service is not listening on port 5665.
I know using the wizard you can activate TCP Listener and choose on which port to listen for connections from the master and also tick boxes to accept commands+config from master.
For example a telnet on port 5665 is not working (connection refused) but checking tcp dump on the FW shows that the master talks to the agent regularly
10:18:06.754847 IP master.node.31481 > agent.node.5665: S 1204321524:1204321524(0) win 64240 <mss 1460,sackOK,timestamp 2249854973 0,nop,wscale 7>
10:15:49.455990 IP agent.node.5665 > master.node.59786: R 0:0(0) ack 4132253520 win 0
I’m quite new to icinga and still learning a lot. It would be very appreciated if someone can push me in the right direction.
Thank you very much and kind regards
Kevin
Hello @visablehamburg
Do you have the api feature enabled? Could you please verify it with the following command?
C:\> cd C:\Program Files\ICINGA2\sbin
C:\Program Files\ICINGA2\sbin> .\icinga2.exe feature list
In case you still don’t have it enabled, you can enable it with this command and restart icinga2.
C:\Program Files\ICINGA2\sbin> .\icinga2.exe feature enable api
Hi Yonas, thanks for the quick reply. the api feature wasn’t enabled, so I did and restarted icinga2. The following features are enabled now: api, mainlog, notifications
It’s still not working. Do I miss any other api settings?
So what exactly is the error you’re getting now? Unfortunately, it’s hard to say what you’re missing now without seeing the actual error. Could you please share the relevant log entries from both Icinga endpoints here.
EDIT:
Since this topic is quite old, I would suggest you to create a new one and have this topic linked there…