Objectif : supprimer le `curl -k` du rapporteur. Fait, et la maniere a ete
imposee par la mesure.
SERVIR UN CERTIFICAT STEP-CA SUR L'API EST IMPOSSIBLE. Icinga le dit lui-meme :
« Our certificate will expire soon, but we own the CA. Renewing. » Il renouvelle
tout certificat expirant sous 30 jours ; les notres vivent 24 h ; possedant une
AC, il re-emet avec la sienne et ecrase le notre a chaque demarrage. Collision
entre deux politiques de PKI, et la notre n'est pas negociable.
Deux decouvertes en chemin, toutes deux par le garde-fou `icinga2 daemon -C`
ajoute au role, qui a ARRETE le deploiement avant de redemarrer la supervision :
- cert_path/key_path/ca_path sont DEPRECIES depuis 2.8 ; les poser reveille un
chemin de code herite qui exige en plus un objet Endpoint ;
- l'identite de l'API est le CN du certificat. NodeName valait « mon-01 », donc
le SAN aussi, alors qu'on appelle par le FQDN : aucune verification n'aurait
pu reussir. NodeName est desormais aligne sur le FQDN.
A LA PLACE : Icinga garde son AC (domaine de confiance FERME, legitime) et
backup-01 verifie le pair contre CETTE AC, recuperee depuis mon-01 au
deploiement. Le pair est authentifie ; seule la racine differe.
Controle negatif — une verification qu'on ne teste pas est un ornement : avec la
mauvaise AC (step-ca), curl refuse (« unable to get local issuer certificate ») ;
avec la bonne, les neuf rapports passent.
Sous-AC step-ca ecartee : elle poserait sur l'hote de supervision une cle capable
d'EMETTRE pour n'importe quel nom, alors qu'on a choisi le sens du flux pour que
compromettre mon-01 ne donne rien.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
25 lines
1.2 KiB
Django/Jinja
25 lines
1.2 KiB
Django/Jinja
/*
|
|
* Gere par Set-OPS (role serveur_icinga). Ne pas editer a la main.
|
|
*
|
|
* AUCUN chemin de certificat n'est declare ici, et c'est le resultat d'une mesure.
|
|
*
|
|
* `cert_path`, `key_path` et `ca_path` sont DEPRECIES depuis Icinga 2.8 : les poser
|
|
* reveille un chemin de code herite qui exige en plus un objet `Endpoint` (constate le
|
|
* 2026-08-11). Depuis 2.8, Icinga lit `/var/lib/icinga2/certs/${NodeName}.{crt,key}` par
|
|
* CONVENTION — et il s'emet lui-meme ce certificat avec sa propre AC.
|
|
*
|
|
* On a tente de lui servir un certificat step-ca : impossible. Icinga renouvelle tout ce
|
|
* qui expire sous 30 jours, les certificats Set-OPS vivent 24 h, et il ecrasait donc le
|
|
* notre a chaque demarrage — « Our certificate will expire soon, but we own the CA.
|
|
* Renewing. » Le consommateur verifie desormais le pair contre l'AC d'Icinga.
|
|
*
|
|
* Ce qui EST durci ici : l'API n'accepte ni configuration ni commande a distance. Le seul
|
|
* usage legitime est le depot de resultats passifs, qui passe par un ApiUser a portee
|
|
* limitee (voir setops-api-users.conf).
|
|
*/
|
|
object ApiListener "api" {
|
|
accept_config = false
|
|
accept_commands = false
|
|
|
|
ticket_salt = TicketSalt
|
|
}
|