This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introduction
Les certificats garantissent le fonctionnement sécurisé de votre système de supervision : pour les communications entrantes et sortantes dans votre environnement Checkmk, ils confirment la fiabilité des clés utilisées, par exemple entre les agents et votre instance Checkmk ou, dans le cadre d’une supervision distribuée, pour la communication entre l’instance centrale et les instances distantes.
Les certificats sont stockés au format PEM chez Checkmk – y compris pour les autorités de certification (CA) Checkmk, qui attestent chacune de leur propre fiabilité à l'aide d'un certificat CA. PEM signifie « Privacy-Enhanced Mail » (courrier à confidentialité renforcée) et est un format de fichier texte facile à utiliser pour stocker et partager des clés cryptographiques, des certificats et des demandes. Les fichiers au format PEM sont des fichiers en texte brut et, à ce titre, peuvent être facilement consultés et modifiés à l’aide d’un éditeur de texte.
Checkmk dote vos instances Checkmk de leurs propres autorités de certification et certificats, qui sont indispensables au fonctionnement et à la communication entre les composants d’une configuration Checkmk (par exemple, entre les agents et l’instance). Les certificats émis par une AC sont appelés « certificats AC ». Les certificats AC servent d’identités numériques pour la communication cryptée : ils héritent de la confiance de leur AC et la transmettent au sein d’une chaîne de confiance (ou chaîne de certificats).
L'autorité de certification racine est une autorité de confiance qui sert de point d'ancrage dans une chaîne de certificats : Elle émet un certificat racine auto-signé (un certificat d'autorité de certification) qui établit la crédibilité et l'identité numérique des certificats et des autorités de certification qui en découlent. À l'extrémité de la chaîne de certificats se trouve le certificat feuille, en tant qu'entité individuelle. Il hérite de la confiance des membres de niveau supérieur de la chaîne qui le précèdent. La confiance est transmise et confirmée par des processus de signature utilisant des signatures numériques. Un ou plusieurs certificats intermédiaires peuvent exister entre les certificats racine et feuille (au sens figuré : les branches de l'arborescence des certificats). Le certificat intermédiaire supérieur est signé par l'autorité de certification racine, et les intermédiaires situés en dessous agissent en tant qu'autorités de certification subordonnées. Il n'y a pas de certificats intermédiaires dans Checkmk, car ils ne sont pas nécessaires à l'architecture de sécurité du logiciel Checkmk.
Concrètement, vous pouvez imaginer le processus comme suit : Une autorité de certification (CA) signe le certificat qu’elle émet avec sa clé privée, garantissant ainsi son authenticité et sa validité. Les composants système concernés s’appuient sur une liste prédéfinie de certificats d’autorité de certification. Les navigateurs, par exemple, fournissent une liste de certificats d’autorité de certification (approuvée par un consortium des principaux fabricants de navigateurs) et feront donc confiance aux sites web qui utilisent des certificats intermédiaires signés par ces certificats d’autorité de certification et, par conséquent, aux clés de serveur signées par ceux-ci. Les certificats qui confirment l’identité d’un client ou d’une personne derrière un serveur (ou un domaine web) sont appelés certificats de serveur – un exemple en est le certificat de serveur d’un site web qu’il présente au navigateur. Le terme « certificats TLS/SSL » est souvent utilisé comme synonyme de certificats de serveur.
En termes simples, l’autorité de certification vérifie la clé publique d’un demandeur (personne, site web ou composant logiciel) en contrôlant l’authenticité et la validité de son certificat. Si le résultat est positif, la communication interne du système est activée, par exemple entre un site et ses ordinateurs hôtes assignés ou dans le cadre d’une supervision distribuée entre sites.
Chez Checkmk, la communication des agents est sécurisée d’une manière qui va même au-delà du SSL/TLS : La communication entre le récepteur d’agent (au sein de l’instance) et le contrôleur d’agent (sur l’ordinateur hôte) s’effectue via mTLS, de manière asynchrone et avec un chiffrement de bout en bout. Le « m » dans mTLS signifie confirmation mutuelle d’une base de confiance : authentification du client et du serveur qui étend le protocole TLS standard. Une autorité de certification (CA) répond aux demandes de signature émanant de l’Agent Controller des ordinateurs hôtes sous supervision. Cela facilite l’identification des agents compromis.
L'authenticité de chaque certificat peut être vérifiée à l'aide d'une empreinte digitale : Une somme de contrôle est calculée à partir de toutes les données du certificat et affichée sous forme de nombre hexadécimal. Cette « empreinte digitale » est l'identifiant numérique unique du certificat. Toute altération d'un certificat modifie son empreinte digitale et est détectée lors de la comparaison avec une autorité de confiance. La communication n'a lieu qu'après vérification réussie des certificats nécessaires, et uniquement sous forme chiffrée. Les certificats SSL/TLS, par exemple, permettent une communication sécurisée entre les navigateurs et les sites web utilisant le protocole Internet HTTPS et garantissent que les données ne peuvent être ni lues ni manipulées pendant la transmission.
Vous pouvez consulter les certificats préinstallés dans Checkmk sur la page «Certificate overview».
2. Aperçu des certificats dans Checkmk
Ouvrez la page « Certificate overview » via Setup > Maintenance > Certificate overview. Vous y trouverez en un coup d’œil tous les certificats de base qui ont été créés et enregistrés côté Checkmk lors de la configuration de votre instance. Cette page est fournie à titre informatif uniquement et sert de point d’accès rapide en interne – par exemple, pour vérifier la validité et les empreintes digitales des certificats préinstallés. Si vous soupçonnez des problèmes avec les certificats, cet aperçu peut accélérer le dépannage. La page « Certificate overview » est le premier endroit où se rendre à cet effet.

La page Certificate overview répertorie les certificats des composants Checkmk avec leurs métadonnées : dans la section « Common Name (Subject) », vous trouverez les certificats qui ont été émis, et sous « Common Name (Issuer) », leur émetteur (autorité de certification), chacun avec ses dates de création et d’expiration correspondantes. Pour chaque certificat, l’empreinte individuelle, le type de clé (RSA), la longueur de clé en bits, l’emplacement de stockage avec le chemin d’accès au fichier, ainsi qu’une brève description de sa fonction (Purpose) sont enregistrés en plus de la durée de validité. L'empreinte digitale complète s'affiche sous forme d'infobulle (texte apparaissant au survol) pour l'entrée d'empreinte digitale correspondante lorsque vous passez la souris sur l'entrée. N'hésitez pas à consulter votre propre site pour vous repérer ; la longueur de clé et d'autres éléments peuvent différer de l'exemple.
Trois autorités de certification (CA) sont toujours générées individuellement en tant qu’émetteurs de certificats de confiance lors de la création d’une instance Checkmk. La page répertorie leurs certificats CA : un certificat CA pour la signature du certificat de l’instance, un certificat CA pour les clés d’agent lors de l’authentification mTLS, et un certificat CA pour les certificats du message broker sur RabbitMQ.
Par défaut, cinq certificats sont répertoriés pour un seul site. Dans le cadre de la supervision distribuée, l'aperçu des certificats de votre instance centrale contient une entrée supplémentaire pour chaque instance distante connectée, car chaque instance distante reçoit un certificat d'instance distante afin de confirmer l'authenticité de la clé utilisée pour la communication entre l'instance centrale et les instances distantes.
2.1. Certificats pour les composants Checkmk
Checkmk dote toutes les instances de supervision d’autorités de certification (CA) et de certificats indispensables au fonctionnement et à la communication entre les composants d’une installation Checkmk. Le tableau suivant détaille la fonction de chacun de ces certificats, sa position dans la chaîne de certificats, ainsi que les fonctionnalités logicielles et les processus dans lesquels il est intégré.
Vous trouverez de plus amples informations dans la dernière colonne : le terme « composants Checkmk » est ici utilisé de manière délibérément large pour désigner divers composants et fonctionnalités de votre logiciel de supervision.
Chemin d'accès dans le dossier « ~/etc » |
Position dans la chaîne de certificats | Description de la fonction | Composants Checkmk |
|---|---|---|---|
|
Certificat CA |
Certificat racine pour la signature du certificat de l'instance. Sécurise l'instance. |
|
|
Certificat de serveur |
Certificat de site destiné à sécuriser la communication entre le site (Agent Receiver) et l'ordinateur hôte (Agent Controller). Il s'agit d'un certificat SSL qui confirme l'authenticité de la clé utilisée pour la communication réseau ; il est utilisé à plusieurs endroits. |
|
|
Certificat CA |
Certificat CA destiné à signer les certificats de l'agent (Agent Controller). Sécurise le protocole mTLS – chargé de l'authentification mutuelle sécurisée entre le client et le serveur, qui étend le protocole TLS standard. |
|
|
Certificat CA |
Certificat CA destiné à la signature des certificats individuels des courtiers de messages. Les courtiers de messages sont nécessaires pour le transfert des données ferroutées dans le cadre de la supervision distribuée. CMK utilise le logiciel libre RabbitMQ comme courtier de messages. |
|
|
Certificat de serveur |
Certificat de serveur destiné à sécuriser la communication réseau du courtier de messages local. Il s'agit d'un certificat SSL. |
|
|
Certificat de serveur |
Certificat de serveur du courtier de messages distant – pour Message Broker. Sécurisation de la communication réseau du courtier de messages de l’instance distante |
La gestion générale des certificats de confiance pour la communication chiffrée TLS entre le serveur Checkmk et les agents sur vos ordinateurs hôtes surveillés se trouve dans une section distincte de l'interface utilisateur. Les paramètres correspondants peuvent être consultés et gérés sous Setup > General > Global settings > Edit global setting > Trusted certificate authorities for SSL. Depuis la page Certificate overview, vous pouvez ouvrir ce paramètre à l'aide de l'entrée Related > Trusted certificate authorities for SSL.
Les clés et les certificats associés à Apache doivent être stockés avec des privilèges root par l’administrateur du serveur ! |
Les certificats du système Apache (c'est-à-dire le serveur web Apache HTTP de votre système) sont importants, mais ils ne sont pas répertoriés sur la page Certificate overview car ils ne font pas partie du logiciel Checkmk. L'administrateur du serveur est responsable de ces certificats ; les utilisateurs de l'instance Checkmk ne disposent généralement pas de droits d'accès. Les certificats du système Apache sont pertinents pour les mises à jour des agents, l'interface web et l'utilisation de l'API REST, par exemple.
Remarque : dans le cadre d'une supervision distribuée avec configuration centrale, les paramètres sont transférés via l'API REST. Si vous souhaitez savoir comment sécuriser votre interface web avec HTTPS, vous pouvez en savoir plus dans l'article du même nom.
