I’ve Icinga2 2.15.1 running. The CA master node just failed to extend/renew the cert. The satellites requested the new certificate but couldn’t get it signed. The request remained on the CA master and were seen in ‘icinga2 ca list’ command. AFAIK, the cert renewal is automatic so I don’t understand why it failed. The validity is 1 year by default apparently.
Does anyone know what could be the cause and how to fix this issue so the automatic renewal happens as it is supposed to be?
Certificate Auto-Renewal ¶
Icinga 2 v2.8+ added the possibility that nodes request certificate updates on their own. If their expiration date is soon enough, they automatically renew their already signed certificate by sending a signing request to the parent node. You’ll also see a message in the logs if certificate renewal isn’t necessary.
The cluster is setup with 2x Masters and 2x satellites in multiple zone. There is no icinga2 agent. I will get the logs but the logs are similar to the topic liked here. The log on master shows the concerned satellites certificate is good and not required renewal whereas the certificate got expired eventually when the renewal requests ( started a few days before the expiry ) failed all the times. As I mentioned the request was the CA master ‘icinga2 ca list’ and they were never renewed by the master.
This is a log of one instance of the satellite request out of many such requests. There is no error or any other message logged on the satellite after those requests.
satellite sat-01
[2026-05-26 05:33:50 -0700] information/JsonRpcConnection: Requesting new certificate for this Icinga instance from endpoint "master01.com’
master01
[2026-05-26 05:33:50 -0700] information/JsonRpcConnection: Received certificate request for CN ‘sat-01.com’ signed by our CA.
[2026-05-26 05:33:50 -0700] information/JsonRpcConnection: The certificates for CN ‘sat-01.com’ and its root CA are valid and uptodate. Skipping automated renewal.
Both masters have CA available. I don’t have the logs of that day anymore but I remember seeing the similar messages reported by master01 on master02 as well.
The masters and the satellites have their own certs in the /var/lib/icinga2/certs directory on the respective hosts.
If both masters have the CA key, they renew the CA certificate independently so this ends up with two new CA certificates.
One more reason not to copy the CA over manually! I mean, it’s still not broken, but…
And I think that is what happened on your setup.
You copied the ca.crt and ca.key in order to be able to sign certs if the main-master-node/configmaster is not available.
Sadly if this condition is fulfilled you wouldn’t be able to update the config, so signing certs in that setup is rather useless to enroll new hosts, it would only help for existing ones to renew, but I think you have bigger problems than a nodes cert gets invalid if your master node is not available.
So you shouldn’t copy the ca at all. It should stay on the node which created it, and of course have a backup somewhere.
Back to your ca, I think it got renewed individually on both master nodes.
I would:
Delete the key from the secondary master node, so this doesn’t happen again.
choose one ca.crt and sync it manually with the same permissions to all the nodes including the secondary masternode but to the place it belongs, in the same folder as the client certificates
you can also use an icinga2 pki save-cert command for that
restart icinga on the agents and the secondary node, cause you switched the ca.crt
renew the certs manually against the node that has the one and only ca.key and ca.crt if there are still problems.
this means delete the certificate folder an the node and do a node setup again
This last post and the references got me confused, in particular:
Could someone please clarify: does Icinga support redundancy for the CA? If yes, how should it be set up? Is there a section in the documentation that explains the steps to take?
It works, but it can cause problems.
You would need to resync this ca folder if there is an autorenewal.
Which didn’t happen in this case since the sha hashes differ.
But nowhere in the docs it says copy the ca key from a to b.
Icinga supports only one config master. so the configuration is created on ONE host only.
The rest is synced via cluster protocol.
According to the icingabook in my own words:
If your config master is dead, you need to fix it, or promote the other machine, or create a new one.
If you choose to do the last two (promote the other machine, or create a new one) never ever turn on the previously pronounced dead configmaster.
The question is, why do you need to enroll an agent if there is no valid way to get the config for it ready?
Your biggest problem is fixing your setup, if there are certificate renewals in the mean time, at least your pain gets bigger fixing the problem in the first place.
If you use icinga director your config will not be deployed anyway since the config master is dead.
