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 les blocs subject et alt_names du certificat, qui peuvent 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
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
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
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
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

TLS non sécurisé​

Principe de fonctionnement​

Certaines configuration nécessitent un assouplissement de la manière dont la connexion est établie.

En TLS, le client (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.

Il peut parfois être nécessaire d'accepter la connexion, y compris lorsque cette correspondance n'est pas vérifiée.

Par exemple, dans le cas d'un MSP, qui mutualise des collecteurs pour ses clients. Les hôtes, au sein du parc client, ne connaissent pas les DNS des collecteurs, et doivent utiliser l'IP, qui ne correspondra pas nécessairement aux informations du certificat. Cela fait particulièrement sens dans le cas où le même certificat doit être utilisé sur plusieurs collecteurs, et que des restrictions de sécurité ne permettent pas l'usage d'un wildcard.

Le mode de chiffrement TLS non sécurisé répond à ce cas d'usage.

En TLS non sécurisé, le client (l'agent/le collecteur) vérifie d'abord le champ "Nom commun CA" du client.

  • Si le champ "Nom commun CA" est renseignĂ©, sa valeur est comparĂ©e avec les informations du certificat, qui doivent correspondre strictement.
  • Si le champ "Nom commun CA" est vide, la vĂ©rification est basĂ©e sur l'IP/DNS utilisĂ©e pour atteindre le serveur, comme pour le mode TLS.

Si aucune correspondance n'est trouvée, la connexion est refusée. La vérification est faite sur les blocs subject et alt_names du certificat, qui peuvent contenir plusieurs DNS, IP ou CN.

Fichiers de certificat​

Voir section dédiée pour TLS, les prérequis sont identiques.

Synthèse des configurations possibles​

La configuration est similaire à celle indiquée pour TLS.

La différence se situe dans l'usage du champ "Nom commun CA", côté client.

Le champ Certificate Common Name/ca_name contiendra la valeur (DNS, IP ou CN) renseignée dans le certificat.

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 = DNS:{alt_server_DNS}, IP:{alt_server_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. Dans le mode de chiffrement TLS non sĂ©curisĂ©, le DNS/IP du serveur peut ĂŞtre diffĂ©rent des informations du certificat. Il faudra alors renseigner la valeur Ă  utiliser dans "Nom commun CA", au sein de la configuration du client.

{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" 
}