This mode leaves the node in a semi-configured state. You need to manually copy the master’s public CA key into /var/lib/icinga2/certs/ca.crt on the client before starting Icinga 2.
OK, I set up the node, I copy ca.crt, and I try to start the agent, which fails. `icinga2 daemon -C` informs me the certificate is missing, which is expected:
[2026-03-26 19:28:50 +0100] critical/config: Error: Cannot get certificate from cert path: ‘/var/lib/icinga2/certs//xxx.crt’.
Location: in /etc/icinga2/features-enabled/api.conf: 5:1-5:24
/etc/icinga2/features-enabled/api.conf(3): */
/etc/icinga2/features-enabled/api.conf(4):
/etc/icinga2/features-enabled/api.conf(5): object ApiListener “api” {
^^^^^^^^^^^^^^^^^^^^^^^^
/etc/icinga2/features-enabled/api.conf(6): accept_config = true
/etc/icinga2/features-enabled/api.conf(7): accept_commands = true
[2026-03-26 19:28:50 +0100] critical/config: 1 error
[2026-03-26 19:28:50 +0100] critical/cli: Config validation failed. Re-run with ‘icinga2 daemon -C’ after fixing the config.
Please help, I really would like this to work. What are the steps needed in order to “leave the node in a semi-configured state”, while being able to start the agent so it can be contacted by its parent to have the CSR signed?
create some tmp folder with rw access for user nagios (Debian / Ubuntu)
for RH/SUSE use user icinga instead of nagios!
mkdir /tmp/certs
chmod 777 /tmp/certs/
this can / should be done on the client machine, but since there is no cert revocation and the master can create new certificates with the same common name anyway…
our nodename here is jack all lowercase
sudo -u nagios icinga2 pki new-cert --cn jack --key /tmp/certs/jack.key --csr /tmp/certs/jack.csr
[2026-04-01 10:14:19 +0200] warning/Application: Failed adjust resource limit for number of processes (RLIMIT_NPROC) with error "Operation not permitted"
[2026-04-01 10:14:19 +0200] warning/Application: Failed adjust resource limit for number of processes (RLIMIT_NPROC) with error "Operation not permitted"
information/base: Writing private key to '/tmp/certs/jack.key'.
information/base: Writing certificate signing request to '/tmp/certs/jack.csr'.
we have a private key and signing request for cn jack
ls
jack.csr jack.key
you can move your signing request to the master or if it was created there continue:
sign the request with the local icinga ca
sudo -u nagios icinga2 pki sign-csr --csr /tmp/certs/jack.csr --cert /tmp/certs/jack.crt
[2026-04-01 10:15:26 +0200] warning/Application: Failed adjust resource limit for number of processes (RLIMIT_NPROC) with error "Operation not permitted"
[2026-04-01 10:15:26 +0200] warning/Application: Failed adjust resource limit for number of processes (RLIMIT_NPROC) with error "Operation not permitted"
information/pki: Writing certificate to file '/tmp/certs/jack.crt'.
ls -la
total 28
drwxrwxrwx 2 root root 4096 Apr 1 10:15 .
drwxrwxrwt 28 root root 12288 Apr 1 10:15 ..
-rw-rw-r-- 1 nagios nagios 1732 Apr 1 10:15 jack.crt
-rw-rw-r-- 1 nagios nagios 1622 Apr 1 10:14 jack.csr
-rw------- 1 nagios nagios 3243 Apr 1 10:14 jack.key
copy the ca.cert to the same folder
cp /var/lib/icinga2/ca/ca.crt /tmp/certs/
ls
ca.crt jack.crt jack.csr jack.key
move it back to the agent with the nodename jack
client file location is /var/lib/icinga2/certs/
things that might gone wrong on your side:
nodename not set correctly (this can be different from your hostname)
invalid names for cert/key it must be .crt, .key
invalid permissions:
root@icinga:/var/lib/icinga2/certs# ls -la
total 24
drwx------ 2 nagios nagios 4096 Jun 2 2025 .
drwxr-x--- 5 nagios nagios 4096 Apr 1 10:35 ..
-rw-r--r-- 1 nagios nagios 1720 Jun 2 2025 ca.crt
-rw-r--r-- 1 nagios nagios 1761 Jun 2 2025 jack.crt
-rw-r--r-- 1 nagios nagios 1651 Jun 2 2025 jack.csr
-rw------- 1 nagios nagios 3243 Jun 2 2025 jack.key
the master does not connect to the agent → so now signing at all
The commands above do not make use of icinga2 communication but it might also be enough to
create the csr (new-cert) in /var/lib/icinga2/certs/ and add the the ca.crt to the directory.
If the master connects to the agent the csr might be in the to sign list on the master icinga2 ca list and can be signed with icinga2 ca sign
I think the/my whole misunderstanding is caused by the sentence above missing “after running icinga2 node setup without using the --parent_host argument”.
Running icinga2 node setup without using the --parent_host argument will leave the node in a semi-configured state. I.e., you will need to manually copy the master’s public CA key into /var/lib/icinga2/certs/ca.crt on the client before starting Icinga 2. After which the TLS communication can be established.
To complete the certificate signing, the icinga2 ca list and icinga2 ca sign commands must be used on the Icinga CA server to complete the certificate signing process if no ticket was provided using the --ticket argument.
Could an insider take care of updating the documentation?
Plus, if someone can explain to me what is the equivalent icinga2 pki command generated by the icinga node setup command when run without --parent_host, I would be very grateful as it will help me better/fully understand the topic.