ApiListener: Add external_ca flag to control renewal behavior

[lazyfrosch]

This will disable checking and renewing certificates with the Icinga master or other parents within the cluster, so it is up for the user to control it.

I named the flag non-specific to being able to control other occasions where a non Icinga CA should be treated differently.

cc @mkayontour
fixes #7719
closes #8859

Notes

In addition it might help improving VerifyCertificate, but this is not relevant for the simple connection handling, only when we want to actually verify certificates with a chain for CLI commands or in the renewal logic.

Also this can be used as a one-sided features, so it should be enough to disable on the master side, so log messages are avoided, while it can be changed on satellites and clients once they are updated.

Of course needs more testing...

Open for questions.

ref/NC/729576

[lazyfrosch]

Can we consider this for 2.14? Should be a simple feature toggle to avoid certificate issues when Icinga is not the CA.

[julianbrost]

I haven't looked at this in too much detail so far. But my first impression is that I don't see how this is supposed to fix #7719: that issue states there's a problem with certificate validation but this PR only changes something about certificate issuance.

[lazyfrosch]

The problematic validation happens in the renewal logic, certificate validation with root and chain happens in OpenSSL anyways.

VerifyCertificate is only called in the renewal logic and some CLI commands.

[Al2Klimov]

• As I've described in Intermediate CA for client auth does not work #7719 (comment) there's no need in modifying a single line of Icinga code to archive Intermediate CA for client auth does not work #7719.
• If, however, the intermediate CA shall not be the cluster's effective root CA, but just play its regular role as in the regular internet, no additional flags as in this changeset should be needed. Instead Icinga shall just store and send its full chain with the leaf cert (as in LE). I imagine it like this: One places just the intermediate CA in the ca.crt which is used for signing. The one used for validation would still be the root one. In this case Icinga would have to send not only the new leaf, but also that cert in a CSR response. The agent -of course- stores intermediate+leaf in one file and sends them every time. Et voila!
• In case of completely externally signed certs just don't place the CA key in your cluster. *
• In the latter case if there are also intermediates, you'd have to store intermediate+leaf in one file on the nodes. Same code modifications required as in my 2nd bullet point.

*) But this PR would be useful not to collect useless CSRs on the file system if you know that your CA is external. Instead the user would have the option just to let Icinga discard them. Julian, if you agree with me, feel free to assign me.