"icinga2 node setup" without contacting the master

This forum was archived to /woltlab and is now in read-only mode.
  • Hi guys,

    i'm trying to setup an icinga-client by icinga2 node setup with following cmd:

    1. icinga2 node setup --ticket <TICKET_SALT> \
    2. --endpoint <MASTER_FQDN> \
    3. --zone <CLIENT_FQDN> \
    4. --master_host <MASTER_HOST> \
    5. --trustedcert /etc/icinga2/pki/trusted-master.crt \
    6. --accept-commands --accept-config

    Because the master (internal-Network) is not accessible from the Client (DMZ), I've already created the certs on the master and stored on the client in /etc/icinga2/pki/:

    1. # ls -1 /etc/icinga2/pki/
    2. <CLIENT_FQDN>.crt
    3. <CLIENT_FQDN>.key
    4. ca.crt
    5. trusted-master.crt

    The icinga2 node setup fails, see the response:

    As you can see, the CLI tries to recreate the client-cert with the masters CA.

    Is it possible to use icinga2 node setup without contacting the master-server? Or do I have to setup the config manually (wich is very error-prone)?

    Any further suggestions for this scenario?

    Thanks for your help! :)

  • You'll have to deploy it manually. It is not that hard, since you'll only need certain things.

    • Certificates (client public and private key, ca.crt)
    • zones.conf with the zones and endpoint relationship as you know it from the distributed monitoring docs
    • enabled api feature, and in addition accept_config and accept_commands set to true

    That's mainly the things the cli command does. Probably the manual certificate generation on the master and transfer to the client is the trickiest one.

  • How would I manually create the client public and private key? Do I do this on the actual master server and sign with the master's ca.crt? I am in the same boat as I have a client that can connect to the satellite but cannot reach the master, so I cannot sign using only the satellite.

  • Yep. https://docs.icinga.com/icinga…vanced-hints-certificates

    Or you have Puppet or so in place which already provides its own CA. The puppet-icinga2 module allows you to make that process with certificate deploying also more easy.

  • Well, here is how I am trying to do this.

    I have client1.com, sat1.com and master.com

    Now I have connected other clients that can ping the master, so I am able to generate authentication that way normally using the node wizard. My problem is I have clients that can only reach a satellite, cannot ping or connect to the master at all.

    So what I did was this:

    For the master key, which I assume will be ca.crt and not master.com.key, I end up created the trusted-master.crt on the client.

    Then I do these steps...

    icinga2 pki new-cert --cn client1.com \

    --key /etc/icinga2/pki/client1.com.key \

    --cert /etc/icinga2/pki/client1.com.crt

    icinga2 pki save-cert --key /etc/icinga2/pki/client1.com.key \
    --cert /etc/icinga2/pki/client1.com.crt \
    --trustedcert /etc/icinga2/pki/trusted-master.crt \
    --host [Satellite IP or Master IP???]

    icinga2 node setup --ticket 654f367624f49004415e63822a1c988bd65390a4 \
    --endpoint client1.com,[client-IP],5665 \
    --zone client1.com \
    --master_host [Satellite or Master IP???] \
    --trustedcert /etc/icinga2/pki/trusted-master.crt \
    --accept-commands --accept-config

    Unfortunately it does not work as I get certificate validation failed from the satellite. But I have other nodes connected to that satellite that at the same time can connect to the master, since I did validation normally with the node wizard.

  • That won't work since the satellite does not have the CA's private key which is required for signing a certificate request by the client. I doubt that you would want to share the CA from the master with satellite nodes. You could temporarily do that, let the satellite behave as csr-autosigning master and then remove the ca's private key for good.

    Although I would suggest to manage and deploy the certificates in a different fashion. A proxy mode for satellites is on the todo list, but I can't say when it is available (needs a sponsor).

  • Thanks for the response!

    Given that we want to be able to use the Icinga agent with clients that cannot reach the master, how would I then set-up the satellites to do the csr-autosigning as the master?

    I forgot to mention above, that I run those commands on the client node.

  • Thanks again!

    So another issue I experienced with this, I get this error trying to use the satellite as the CA to sign:

    information/cli: Icinga application loader (version: v2.6.3)
    information/cli: Loading configuration file(s).
    information/ConfigItem: Committing config item(s).
    critical/SSL: Error on bio X509 AUX reading pem file '/etc/icinga2/pki/client1.com.crt': 0, "error:00000000:lib(0):func(0):reason(0)"
    critical/config: Error: Cannot get certificate from cert path: '/etc/icinga2/pki/client1.com.crt'.
    Location: in /etc/icinga2/features-enabled/api.conf: 4:1-4:24
    /etc/icinga2/features-enabled/api.conf(2): * The API listener is used for distributed monitoring setups.
    /etc/icinga2/features-enabled/api.conf(3): */
    /etc/icinga2/features-enabled/api.conf(4): object ApiListener "api" {
    /etc/icinga2/features-enabled/api.conf(5): cert_path = SysconfDir + "/icinga2/pki/" + NodeName + ".crt"
    /etc/icinga2/features-enabled/api.conf(6): key_path = SysconfDir + "/icinga2/pki/" + NodeName + ".key"

    critical/config: 1 error

    Despite that error, I was able to connect the client another way. I created the 3 files on the master, signed the .csr on the master and transferred the contents to the clients /etc/icinga2/pki/ and then I also copied the ca.crt that was in the masters /etc/icinga2/pki folder and ran "icinga2 daemon -C" to check if it all worked. No errors, and now I can monitor the node with Icinga Director.

    We would much rather have the satellite sign, the TicketSalt is the same on both the master and satellite, yet I get the above error.

  • Regarding the error - when exactly did that happen? I would believe your passed CN to the cli command is not the same as the NodeName constant (which defaults to FQDN if not set, see icinga2 variable get NodeName). Then you fetch a certificate in /etc/icinga2/pki/client1.crt but the client wants /etc/icinga2/pki/blub,com,local.crt

    As said, signing on the satellite is a matter of security as you expose the private CA key to anything else than the master. If one gets access to the satellite, it may just steal the CA key and sign their own certificates or pretent to be someone else.

  • That error happened originally when I tried to use the satellite as the CA during "icinga node wizard", but what ends up happening is that error, so when I look in the client1.com.crt, there is no key.

    I am not worried about the satellites, they are on our internal network and secure from a linux perspective.