Aller au contenu principal

Configurer les certificats

TLS​

Principe de fonctionnement​

La connexion TLS (1.3) est négociée par le client (collecteur ou agent selon le sens), et nécessite des certificats. Selon le sens de connexion, l'agent/le collecteur vérifie que l'IP/DNS utilisée pour atteindre le serveur correspond strictement aux informations du certificat. Si ce n'est pas le cas, la connexion est refusée. La vérification est faite sur le bloc alt_names du certificat, qui peut contenir plusieurs DNS, IP ou CN.

Fichiers de certificat​

Les formats supportés sont :

  • fichier de certificat public, CA ou wildcard : .crt/.cer
  • fichier de clĂ© privĂ©e : .key

Les fichiers de certificat déposés sur le collecteur doivent être déposés dans /etc/pki/, à la racine ou dans un sous-repértoire. Ils doivent avoir les permissions suivantes :

chmod 644 /etc/pki/agent*

Les fichiers de certificat déposés sur l'hôte peuvent être déposés dans le répertoire de votre choix.

Ces fichiers peuvent également être directement enregistrés dans le magasin de certificats. Dans ce cas, il n'est pas nécessaire de les renseigner dans la configuration faite sur l'hôte (colonne "Configuration de l'hôte" du tableau ci-dessous).

Synthèse des configurations possibles​

L'agent vérifie, lors de la connexion au collecteur, que l'IP/DNS renseignée dans le paramètre Poller endpoint de la configuration de l'agent correspond strictement aux informations du certificat (SAN ou CN). Si ce n'est pas le cas, la connexion est refusée.

Cas d'usageFichier(s) sur le collecteurFichier(s) sur l'hôte (si non chargés dans le magasin de certificats)Configuration du Collecteur (interface)Configuration de l'hôte
Certificat signé par CAFichiers de certificat public et clé privéeFichier de CADans la section Récepteur OTLP :
  • Certificat public : chemin du certificat public (ex : '/etc'/pki'/certificate.crt)
  • ClĂ© privĂ©e : chemin de la clĂ© privĂ©e (ex : '/etc'/pki'/certificate.key)
  • CA : vide
  • Poller endpoint : IP/DNS du Collecteur
  • Private Key file/private_key: vide
  • Certificate file : vide
  • Trusted CA's certificate file/ca_certificate : chemin du CA
  • Certificate Common Name/ca_name : vide
Certificat autosignéFichiers de certificat public et clé privéeFichier de certificat publicDans la section Récepteur OTLP :
  • Certificat public : chemin du certificat public (ex : '/etc'/pki'/certificate.crt)
  • ClĂ© privĂ©e : chemin de la clĂ© privĂ©e (ex : '/etc'/pki'/certificate.key)
  • CA : vide, sauf besoin d'un double handshake
  • Poller endpoint : IP/DNS du Collecteur
  • Private Key file/private_key : vide
  • Certificate file/public_cert : vide
  • Trusted CA's certificate file/ca_certificate : chemin du certificat public
  • Certificate Common Name/ca_name : vide
Certificat wildcardFichiers wildcard et clé privéeFichier wildcardDans la section Récepteur OTLP :
  • Certificat public : Fichier de certificat wildcard
  • ClĂ© privĂ©e : chemin de la clĂ© privĂ©e
  • CA : vide
  • Private Key file/private_key : vide
  • Certificate file/public_cert : vide
  • Trusted CA's certificate file/ca_certificate : chemin du certificat wildcard
  • Certificate Common Name/ca_name : vide
Certificat public (service managé, par ex Collecteur central Centreon Cloud)AucunAucunDans la section Récepteur OTLP :
  • Certificat public : vide
  • ClĂ© privĂ©e : vide
  • CA: vide
  • Poller endpoint : IP/DNS du load balancer portant le certificat public
  • Private Key file/private_key : vide
  • Certificate file/public_cert : vide
  • Trusted CA's certificate file/ca_certificate : vide
  • Certificate Common Name/ca_name : vide
Certificat public (fichiers de clés)Fichiers de certificat public et clé privéeAucunDans la section Récepteur OTLP :
  • Certificat public : chemin du certificat public (ex : '/etc'/pki'/certificate.crt)
  • ClĂ© privĂ©e : chemin de la clĂ© privĂ©e (ex : '/etc'/pki'/certificate.key)
  • CA : vide
  • Poller endpoint : IP/DNS du collecteur
  • Private Key file/private_key : vide
  • Certificate file/public_cert : vide
  • Trusted CA's certificate file/ca_certificate : vide
  • Certificate Common Name/ca_name : vide

Comment générer un certificat autosigné (facultatif)​

Si vous ne possédez pas de certificat, il est possible de générer un certificat autosigné. Pour générer un certificat autosigné valide un an, exécutez la commande suivante sur votre collecteur ou votre hôte :

openssl req -new -subj '/CN={server_hostname}' \
                 -addext "subjectAltName = CN:{server_hostname}, DNS:{alt_poller_DNS}, IP:{alt_poller_IP}" \
                 -days 365 -nodes -x509 \
                 -newkey rsa:2048 -keyout {key} -out {cert}
  • {key} = chemin du fichier clĂ© privĂ©e
  • {cert} = chemin du fichier de certificat public
  • {server_hostname} = nom DNS du serveur et/ou utiliser {alt_poller_DNS} et/ou utiliser {alt_poller_IP} Dans le mode de chiffrement TLS, le DNS/IP du serveur utilisĂ© par le client doit obligatoirement correspondre Ă  une entrĂ©e CN ou SAN (altName) du certificat ({server_hostname}). La ligne -subj '/CN={server_hostname}' \ est facultative si des SAN sont dĂ©finis.

{server_hostname} doit correspondre au DNS/IP utilisé dans Poller endpoint" (installer) / endpoint (json), dans la configuration d'agent, sur l'hôte.

Mode test : communication non chiffrée​

Vous pouvez configurer une connexion non chiffrée à des fins de test uniquement. Dans ce mode, vous n'avez besoin d'aucun certificat ou jeton.

Notez que cette connexion ne durera qu'une heure. N'utilisez pas ce paramètre en production !

Pour configurer ce mode, sélectionnez No TLS dans la liste Niveau de chiffrement de la fenêtre Configuration collecteur/agent.

L'agent sera configuré de la manière suivante sur l'hôte :

{
  "log_level":"info",
  "endpoint":"<IP/DNS COLLECTEUR>:4317",
  "encryption" : "false",
  "host":"host_1",
  "log_type":"file",
  "log_file":"/var/log/centreon-monitoring-agent/centagent.log" 
}