Question about ca signing and tickets

[b1naryv1k1ng (Michael O'Brien)]

Using a agent > satellite > master setup.

I’m using a bash script on the agent that preforms all the steps needed to join an agent into icinga. Here is what it looks like:

icinga2 pki new-cert --cn dev-agent.qa.***.net \
--key /var/lib/icinga2/certs/dev-agent.qa.***.net.key \
--cert /var/lib/icinga2/certs/dev-agent.qa.***.net.crt

icinga2 pki save-cert --trustedcert /var/lib/icinga2/certs/trusted-parent.crt \
--host dev-satellite.qa.***.net

ticket=$(curl -k -s -u <api user>:<api pass> \
-H 'Accept: application/json' \
-X POST 'https://dev-icinga:5665/v1/actions/generate-ticket' \
-d '{ "cn": "dev-agent.qa.***.net" }'|python3 -m json.tool|grep '\"ticket\"'|awk -F '"' '{print $4}')

icinga2 node setup --ticket $ticket \
--cn dev-agent.qa.***.net \
--endpoint dev-satellite.qa.***.net \
--zone dev-agent.qa.***.net \
--parent_zone dev-satellites \
--parent_host dev-satellite.qa.***.net \
--trustedcert /var/lib/icinga2/certs/trusted-parent.crt \
--accept-commands \
--accept-config \
--disable-confd

Running this script currently does setup the node right now, with the exception of me needing to manually sign the certificate for the agent on the master.

My question is, since we do not want to have to expose the master to every single agent for generating a ticket, can I change the dev-master to dev-satellite in the curl and generate the ticket on the satellite? Or will the master always need to generate the ticket?

Its odd that right now, even through the ticket is generated on the master, I still need to do a icinga2 ca sign on the agent request before it starts working, I thought the ticket process is there to bypass the need of needing to sign requests?

[moreamazingnick]

you should generate the ticket on the master.
since you can access the master from you setup for now you can set

 --parent_host dev-icinga

in the icinga node setup command

what I currently not understand is why the ca-proxy does not work in your case?

[b1naryv1k1ng (Michael O'Brien)]

For the environment I’m currently setting up, yes I can access the master. Once I start pulling in other environments, I will not be able to.

I’m trying to automate the process of adding a new host as an agent, so this is why I was trying to see if it would be possible to generate the ticket on a satellite specifically in an env where the master might not be reachable.

[Tqnsls (Silas)]

@moreamazingnick

what I currently not understand is why the ca-proxy does not work in your case?

Hi Nick,
can you please explain how one could verify if the ca-proxy really works?

[moreamazingnick]

here is a blogpost about the ca-proxy:

How to: Icinga 2 - CA Proxy

here are the docs:

Upgrading Icinga 2 - Icinga 2

here is one thread about it:

Initialize Agent via Satellite with Master certificate

icinga2 has a feature named ca-proxy the /etc/icinga2/features-available/api.conf must allow the incoming request, but I think it is enabled by default on all agents, so every agent can act as a CA-Proxy

In summary:
A ) you send the cert request to the satellite with the correct ticket and your certificate gets autosigned

OR

B) You send the cert request to the satellite without any ticket and your masternode should have the request, and you can sign it there

icinga2 ca list

And if I remember correctly you have to have the api feature enabled on the satellite and listen on 0.0.0.0 or your device ip

[Tqnsls (Silas)]

Thanks for the detailed answer, Nick!
I already had read the docs and your quote before as well, but I could not clarify how exactly I can validate if the ca-proxy is running / working correctly.

@moreamazingnick

In summary:
A ) you send the cert request to the satellite with the correct ticket and your certificate gets autosigned

You mean e.g. via icinga2 node setup?
icinga2 node setup --cn <agent-hostname> --zone <agent-zonename> --parent_zone <sat-zone-1> --parent_host <sat-zone-1-endpoint-1> --endpoint <sat-zone-1-endpoint-1>–endpoint <sat-zone-1-endpoint-1> --trustedcert /tmp/trusted_<sat-zone-1-endpoint-1>.rhs.zz.crt --accept-commands --disable-confd --accept-config --ticket 99d629aca7bbaa825395925ab43b124784153702
This works as you described in our environment - certificate is auto-signed. Does the agent need the ticket to auto-renew his certificate? If yes, how does it supply it to the master / satellite and where is it located?

@moreamazingnick

B) You send the cert request to the satellite without any ticket and your masternode should have the request, and you can sign it there

Also, you mean e.g. via icinga2 node setup?
icinga2 node setup --cn <agent-hostname> --zone <agent-zonename> --parent_zone <sat-zone-1> --parent_host <sat-zone-1-endpoint-1> --endpoint <sat-zone-1-endpoint-1>–endpoint <sat-zone-1-endpoint-1> --trustedcert /tmp/trusted_<sat-zone-1-endpoint-1>.crt --accept-commands --disable-confd --accept-config
This works as you described in our environment - pending certificate is listed via icinga2 ca list on the master and both the sat-zone-1’s satellites / endpoints. I have to manually sign them.1

But I am currently experiencing a strange problem; We have multiple zones, exactly one zone sat-zone-1 has two satellites where the auto-renewing of the agents did not work and the agents were not checkable anymore. In another zone sat-zone-2 with exactly only one satellite, auto-renew worked.

This is the first renewal (we initiated icinga-agent in Q2 2024) so I can not verify

• if the satellites of sat-zone-1 are configured incorrectly (in which way ever..) and the sat-zone-2 with a single satellite is configured correctly
• or if the installed icinga-agent on the agents where auto-renewal did not work was installed / configured incorrectly. As they were the first to be installed and I tested around with them while building the ansible playbook I can not rule that out.

Maybe you have an idea what the issue is. As zones with max two endpoints are supported, I can not believe that the problem occurs because of the two-agent zone.