 |
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
Si vous souhaitez utiliser l'interface web de Checkmk via HTTPS, vous devrez effectuer les opérations suivantes sur votre serveur de supervision, quels que soient vos sites :
Le module Apache
mod_sslest installé et activé.Les modules Apache
mod_rewriteetmod_headerssont présents et également activés.Vous disposez d'un certificat de serveur valide.
Le serveur est accessible via HTTPS.
Cet article explique tout ce qui est nécessaire pour réaliser une telle configuration.
2. Activation des modules Apache
L'accès HTTPS à l'interface Checkmk nécessite le module Apache mod_ssl.
Nous partons également du principe, dans la suite de la Configuration, qu'une connexion entrante sur le port non chiffré 80 doit être redirigée vers le port chiffré SSL 443.
Cela nécessite le module mod_rewrite.
Enfin, le module mod_headers est nécessaire pour que l'Apache accessible de l'extérieur et configuré en tant que proxy inverse (reverse proxy) transfère les en-têtes de requête vers l'instance Apache du site.
Vous pouvez afficher les modules Apache actuellement installés à l'aide de l'instruction « apachectl ». Les anciennes versions de Red Hat Enterprise Linux (RHEL) et de CentOS peuvent nécessiter « httpd » à la place.
Utilisez « grep » pour checker immédiatement si les trois modules requis sont présents :
L'activation des modules manquants peut être effectuée sur la plupart des distributions à l'aide du script a2enmod.
Ce script crée des liens symboliques dans le dossier /etc/apache2/mods-enabled.
Le fichier portant l'extension .load contient les instructions pour charger le module, et le fichier .conf contient la configuration réelle du module :
Pour les anciennes versions de RHEL et les distributions qui en sont dérivées, mod_ssl est un paquet dédié qui doit être installé séparément :
Si l'instruction a2enmod n'est pas disponible, vous utilisez une distribution qui conserve la configuration d'Apache dans un seul fichier de configuration au lieu de la répartir dans des répertoires et de nombreux fichiers individuels.
Dans ce cas, la ligne commentée LoadModule ssl_module […] dans le fichier de configuration /etc/httpd/conf/httpd.conf doit être débarrassée de #.
Procédez de la même manière pour les deux autres modules.
La possibilité de redémarrer le serveur web Apache immédiatement ou ultérieurement dépend de la génération automatique de certificats simples et auto-signés lors de l'installation d'Apache.
Vous pouvez le vérifier en recherchant d'abord le fichier de configuration contenant les chemins d'accès au certificat et aux clés, puis en checkant si ces fichiers existent (pour RHEL, indiquez /etc/httpd comme répertoire de départ pour la recherche) :
root@linux# find /etc/apache2/ -type f -exec grep -Hn '^\s*SSLCertificate.*File' {} \;
/etc/apache2/sites-available/default-ssl.conf:32: SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
/etc/apache2/sites-available/default-ssl.conf:33: SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.keyVérifiez si les fichiers spécifiés dans le fichier de configuration sont présents. Si aucun certificat créé automatiquement n'existe, attendez d'avoir reçu ou créé vous-même un certificat avant de redémarrer le serveur web Apache — sinon, le redémarrage échouera.
Si le certificat et la clé existent, redémarrez le serveur web Apache, dans le cas de systemd, qui est désormais utilisé par défaut, à l'aide de l'instruction suivante :
Une fois encore, certaines distributions n’utilisent pas apache2 comme nom du service, mais plutôt httpd, qui est un peu plus générique.
Dans ce cas, modifiez l’instruction.
Remarque : dans la Checkmk Appliance, activez HTTPS via l'interface web !
3. Obtention des certificats
En substance, les méthodes suivantes sont disponibles pour obtenir un certificat de serveur :
Vous faites appel à un prestataire de services externe pour l'émission de certificats via une CSR (demande de signature de certificat), dont le certificat racine est reconnu comme fiable par les fabricants de navigateurs et de systèmes d'exploitation. Grâce à cette procédure, les certificats peuvent être validés non seulement au niveau du domaine, mais également au niveau de l'organisation (validation d'organisation) et à un niveau supérieur (validation étendue), comme l'exigent certaines catégories d'entreprises pour des raisons réglementaires. Vous trouverez plus d'informations sur ces options dans la section Niveaux de validation.
Vous utilisez des certificats gratuits de Let’s Encrypt. Cette méthode ne permet qu’une validation au niveau du domaine. Pour pouvoir demander des certificats, le serveur à sécuriser doit être accessible depuis l’extérieur ou vous devez être en mesure de créer des entrées (automatisées) dans le DNS public du domaine utilisé.
Vous devenez votre propre autorité de certification (CA) et générez vos propres certificats. Le certificat racine de votre propre CA doit être présent sur toutes les machines qui communiquent avec des serveurs utilisant des certificats signés avec la clé de la CA. Des normes de sécurité élevées doivent être respectées lorsque vous gérez votre propre CA, car celle-ci peut être utilisée pour émettre des certificats pour n’importe quel domaine.
3.1. Utilisation d’AC externes
Pendant longtemps, le fait de faire signer des certificats par une autorité de certification commerciale était le seul moyen d’obtenir des certificats acceptés par tous les navigateurs et systèmes d’exploitation. Cette procédure est encore courante aujourd’hui, en particulier lorsque l’on souhaite des périodes de validité longues.
La procédure consiste à générer d'abord la clé privée du serveur, puis à créer une demande de signature de certificat (CSR) pour celle-ci, que vous transmettez au fournisseur sélectionné. Le fournisseur vérifie ensuite la propriété du domaine, confirme la CSR avec sa clé et vous envoie le certificat de serveur obtenu.
Indépendamment des exemples ci-dessous, veillez à suivre les directives de votre autorité de certification et à modifier les instructions en conséquence.
Génération de la clé et de la CSR
Commencez par générer la clé privée du serveur. Vous pouvez effectuer cette étape directement sur le serveur où se trouve l’instance Checkmk à sécuriser.
Le dossier /etc/certs utilisé est le dossier par défaut pour de nombreuses distributions.
Vous pouvez toutefois utiliser n’importe quel dossier auquel le processus Apache dispose d’un accès en lecture.
Nommer la clé d’après le nom de domaine principal pour lequel elle est utilisée (ici checkmk.mydomain.com) offre un meilleur aperçu dans ce contexte.
Ce schéma de nommage facilite l’attribution, en particulier si des noms de serveurs supplémentaires sont ajoutés ultérieurement, pour lesquels des clés/certificats propres sont utilisés.
La clé privée est ensuite utilisée pour chiffrer le trafic de données et doit être traitée avec le soin approprié (par exemple, en ce qui concerne les droits d'accès). Afin de pouvoir redémarrer automatiquement le serveur Apache, la plupart des administrateurs n'attribuent pas de phrase de passe.
À l'étape suivante, vous créez la demande de signature de certificat (CSR) — une demande numérique pour la création d'un certificat d'identité (ici : un certificat à clé publique) :
Veillez à saisir correctement les informations relatives à l'entreprise et à indiquer le nom du serveur comme adresse e-mail (Common Name).
L'adresse e-mail (Email Address) doit se trouver dans le même domaine et appartenir à une boîte aux lettres existante qui est activement consultée.
Création d'un fichier d'extension
Les navigateurs modernes exigent des certificats utilisant l'extension pour les noms de domaine alternatifs, même si les certificats ne sont délivrés que pour un seul nom de domaine.
Cela nécessite un fichier d'extension, que certains fournisseurs créent et intègrent automatiquement.
Si ce n'est pas le cas ou si vous n'êtes pas sûr, créez un tel fichier.
Si un certificat doit être valide pour plusieurs noms de domaine, ajoutez des lignes supplémentaires après [alt_names], DNS.2 =, etc. selon les besoins :
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = checkmk.mydomain.comSoumission des documents
Selon le niveau de validation recherché, il peut être nécessaire de rassembler d’autres documents, tels que des extraits du registre du commerce ou des données bancaires. Étant donné que les documents requis, les modalités de transmission et les méthodes de confirmation varient d’un fournisseur à l’autre, aucune recommandation d’application générale ne peut être fournie ici. Par exemple, la validation étendue (Extended Validation) peut également impliquer l’envoi d’un code par courrier recommandé au directeur général ou à un signataire autorisé, qui doit ensuite saisir ce code via une interface web.
Dans le cas le plus simple d’une validation au niveau du domaine uniquement, le fichier CSR et, le cas échéant, le fichier EXT sont téléchargés via une interface web.
Vous avez alors la possibilité de sélectionner une adresse e-mail : parmi celles enregistrées pour l’Admin-C (propriétaire du domaine) ou pour le Tech-C (responsable technique du domaine), ou une adresse e-mail générique telle que webmaster@domain.com.
Un lien de confirmation sera alors envoyé à cette adresse.
Réception du certificat
Le processus de validation lui-même prend généralement quelques minutes au maximum pour une validation au niveau du domaine, ou peut parfois prendre plusieurs jours pour une validation étendue. Une fois ce processus terminé, vous recevrez le certificat correspondant à votre clé par e-mail ou via téléchargement. En plus du certificat, vous recevrez également un lien de téléchargement vers le fichier de chaîne de certificats. Veillez à enregistrer ce fichier également.
3.2. Let’s Encrypt
Si un serveur est accessible à distance ou si vous avez accès au serveur de noms, vous pouvez faire générer automatiquement des certificats via le fournisseur de services à but non lucratif Let’s Encrypt, qui appartient à l’Electronic Frontier Foundation (EFF). Cela n’entraîne aucun coût. Les certificats validés via le DNS nécessitent quelques minutes d’attention tous les 90 jours, tandis que les certificats validés via le répertoire du serveur peuvent être régénérés automatiquement pendant des années.
Pour les certificats Let’s Encrypt, l’EFF fournit Certbot, un programme Python disponible sous divers formats de paquets. Certbot crée la clé, envoie la CSR, vérifie la propriété du serveur ou du domaine, puis télécharge le certificat. Certbot communique avec les serveurs de l’EFF via le protocole ACME (Automatic Certificate Management Environment).
Installation du script Certbot
Il existe trois façons d’installer Certbot. Le choix de la méthode dépend principalement de l’ancienneté de la distribution que vous utilisez et de la directive de votre organisation concernant l’installation de paquets provenant de sources tierces :
Si le gestionnaire de packs de votre distribution Linux propose Certbot version 1.10 ou supérieure, vous pouvez utiliser cette version de Certbot.
L'EFF recommande l'installation à partir d'une image snap, comme indiqué sur sa page de documentation Certbot. Les avantages et inconvénients connus du format de paquet snap s'appliquent.
Certbot peut être installé via l'outil d'installation de paquets Python
pipà partir du Python Package Index. Commencez par créer un environnement virtuel Python (venv) afin d'éviter d'endommager les modules Python fournis par la distribution. Dans l'environnement virtuel, exécutez l'instructionpip install certbotpour installer Certbot et toutes les dépendances requises.
Configuration entièrement automatisée
Si le serveur Checkmk est accessible depuis internet et que vous n’avez apporté aucune modification à la configuration du serveur web Apache au niveau du système depuis l’installation de Checkmk, vous pouvez utiliser la fonctionnalité « automatisme Apache » de Certbot. Cela vous permet de générer des clés, de demander des certificats, d’ajuster automatiquement la configuration d’Apache et enfin de configurer une tâche cron pour réaliser périodiquement le renouvellement des certificats valables pendant 90 jours maximum, avant leur expiration.
Le script va maintenant vous demander de manière interactive certaines informations concernant vos coordonnées (adresse e-mail pour des informations supplémentaires telles que les rappels de certificats nécessaires) et les chemins d'accès à l'installation.
Une fois le script terminé, vous disposerez d'une configuration SSL opérationnelle.
La modification du fichier de configuration d'mod_ssl n'est pas nécessaire, celle-ci a déjà été effectuée par Certbot.
Configuration semi-automatisée
Si vous demandez des certificats, comme décrit dans la section précédente, mais que vous souhaitez personnaliser vous-même la configuration d'Apache, utilisez l'instruction :
Vous pouvez ensuite terminer la configuration comme décrit ci-dessous dans le fichier de configuration d'mod_ssl.
Autres options
Par exemple, si le serveur Checkmk n'est accessible que depuis l'intranet ou via un VPN, mais que le serveur DNS est public, vous pouvez effectuer la validation via un DNS Challenge. Ici, la propriété d’un domaine n’est pas checkée pour pouvoir placer des fichiers sur le serveur web, mais pour pouvoir ajouter des entrées dans le DNS. Il ne s’agit pas d’entrées qui résolvent un nom de domaine en une adresse IP, mais d’entrées dites TXT, qui peuvent contenir n’importe quelle chaîne de caractères. Les entrées TXT sont également utilisées, par exemple, pour spécifier quels serveurs sont autorisés à envoyer des e-mails pour un domaine.
Les défis DNS peuvent être effectués manuellement, ce qui n’est généralement pratique que pour des systèmes de test individuels avec une validité de 90 jours. Si votre fournisseur DNS dispose d’une API prise en charge par Let’s Encrypt, un renouvellement automatique peut également être effectué. Pour cela, consultez l’aperçu des types de défis sur Let’s Encrypt.
3.3. Utilisation d’autorités de certification internes
Vous pouvez endosser le rôle d’une autorité de certification (CA) et émettre des certificats pour n’importe quel domaine (vos domaines, des domaines externes et des domaines fictifs).
La solution via votre propre CA est particulièrement utile pour les environnements de test ou les serveurs Checkmk isolés comptant un nombre raisonnable d’utilisateurs.
C’est également le seul moyen d’obtenir des certificats si vous utilisez en interne l’un des cinq domaines de premier niveau (TLD) réservés : .example, .invalid, .local, .localhost ou .test.
Il n’existe aucun registraire pour ces domaines ; par conséquent, aucune propriété ne peut être vérifiée.
Ce chapitre explique comment émettre des certificats avec une telle autorité de certification interne. On part du principe que vous disposez déjà de la clé racine ou de la clé intermédiaire de l'autorité de certification privée et que vous devez désormais l'utiliser pour émettre des certificats afin de sécuriser un serveur Checkmk.
La création des clés de l'autorité de certification, du certificat de l'autorité de certification et du fichier de configuration associé n'est pas abordée dans ce tutoriel.
Génération de la clé et de la CSR
Pour créer la clé du serveur, la demande de signature de certificat (CSR) et le fichier d'extension, procédez comme décrit dans la section sur l'émission de certificats via une autorité de certification commerciale. La procédure et les fichiers requis sont identiques.
Signature de la CSR
Pour signer vous-même des certificats, vous avez besoin au minimum d’une clé privée (ici intermediate.key.pem) et du certificat intermédiaire correspondant intermediate.pem.
Si vous disposez également d’un fichier de configuration, son chemin d’accès doit être spécifié à l’aide du paramètre --config.
La signature basée sur le fichier CSR checkmk.mydomain.com.csr, le fichier d'extension checkmk.mydomain.com.ext et le fichier de sortie checkmk.mydomain.com.crt est ensuite effectuée à l'aide de l'instruction suivante :
En plus du certificat de serveur checkmk.mydomain.com.crt créé ici, vous devez également transmettre votre certificat d'autorité de certification intermediate.pem.
Si vous n'êtes pas une autorité de certification racine, vous devez également transmettre le certificat racine (désigné par ca_certificate_internal.pem dans la suite du texte).
Importation du certificat
Les options permettant d’importer un certificat d’autorité de certification (CA) en tant que certificat de confiance varient d’un navigateur à l’autre.
Il suffit généralement d’ajouter le certificat ca_certificate_internal.pem sous Settings > Privacy et Security > Certificates > Import.
Afin que la gestion des certificats ne constitue pas un obstacle lors de la mise à jour automatique des agents dans les éditions commerciales, nous avons prévu dans la boulangerie d’agents la possibilité de fournir un certificat d’autorité de certification (CA) propre, utilisé uniquement pour les mises à jour des agents. Dans ce cas, les certificats système ne sont pas modifiés et les mises à jour des agents restent possibles.
Comme alternative à la distribution via les mises à jour des agents, vous pouvez intégrer le certificat racine dans la base de données CA locale de l’ordinateur hôte.
Pour ce faire, copiez le fichier ca_certificate_internal.pem vers /usr/local/share/ca-certificates/, puis régénérez le cache :
Sous Windows, il est possible de gérer les certificats système via le snap-in MMC « Certificats ». Cela est nécessaire, par exemple, si vous souhaitez utiliser un navigateur Microsoft pour accéder à un Checkmk sécurisé par sa propre autorité de certification. Vous pouvez consulter la procédure exacte dans l'article de la base de connaissances Microsoft consacré à l'infrastructure PKI. Vous pouvez également distribuer les certificats via Intune.
4. Configuration de la connexion HTTPS pour une instance
Vous devez tout d'abord indiquer les chemins d'accès corrects vers la clé, le certificat et le certificat intermédiaire dans le fichier de configuration SSL. Veuillez noter qu'il s'agit de configurations destinées au serveur web apache2 et qu'elles ne sont pas spécifiques à Checkmk. Par conséquent, le fichier de configuration utilisé sur les systèmes basés sur Debian est généralement le fichier par défaut /etc/apache2/sites-enabled/default-ssl.conf ; toutefois, le chemin d'accès peut être différent sur les distributions plus anciennes.
Dans l'exemple ci-dessous, SSLCertificateKeyFile désigne la clé privée générée lors de la configuration initiale de ce serveur.
SSLCertificateChainFile contient le certificat intermédiaire ou, le cas échéant, une concaténation de certificats intermédiaires dépendants.
Ceci n'est omis que pour une autorité de certification interne (CA) où la clé de la CA est utilisée directement pour la signature.
De nombreux fournisseurs commerciaux utilisent des noms de fichiers plutôt génériques ; si vous adoptez ces noms, la configuration ressemblera à ce qui suit :
Si vous avez utilisé Let’s Encrypt pour générer des certificats mais que vous souhaitez mettre à jour la configuration manuellement, identifiez les chemins d’accès aux fichiers stockés sous /etc/letsencrypt/live et saisissez-les :
4.1. Ajout de la redirection HTTPS
Apache utilise des hôtes virtuels pour servir du contenu pour plusieurs noms de domaine sous une seule adresse IP.
Si le terme « instance » est utilisé dans le contexte d'Apache, il s'agit d'un hôte virtuel, et non d'une instance Checkmk.
Sur un serveur Checkmk dédié, on utilise généralement un seul hôte virtuel avec un nom de serveur sous lequel toutes les instances Checkmk sont alors accessibles.
La configuration de l'VirtualHoste se trouve dans l'un des fichiers suivants, selon la distribution utilisée :
Debian, Ubuntu |
|
RHEL, CentOS |
|
SLES |
|
L'exemple suivant part du principe que vous utilisez un seul fichier de configuration pour les connexions non chiffrées sur le port 80 et les connexions chiffrées sur le port 443.
Dans ce cas, ajoutez les lignes suivantes à la section VirtualHost :
Les deux lignes d'RequestHeader set X-Forwarded…s ci-dessus garantissent que l'instance Apache sur le port 5000 est informée qu'un appel a été effectué via SSL, confirmant ainsi que les règles de sécurité ont été respectées.
Une fois la modification de configuration effectuée, le serveur web doit être redémarré :
Une fois encore, certaines distributions n'utilisent pas apache2 comme nom du service, mais le nom plus générique httpd.
Dans ce cas, il suffit de modifier l'instruction.
5. Options supplémentaires
5.1. Configuration du HSTS
Rendre le serveur Checkmk accessible uniquement via HTTPS constitue la première étape, et la plus importante, pour sécuriser les connexions à la supervision. Vous pouvez toutefois renforcer encore davantage la sécurité grâce à des paramètres supplémentaires facultatifs. Par exemple, le serveur web peut indiquer au navigateur qu’à l’avenir, il ne sera accessible que via HTTPS et qu’une connexion non sécurisée via HTTP sera systématiquement rejetée.
Cette technique est appelée « HTTP Strict Transport Security » (HSTS) et est définie pour une certaine période de temps en secondes. Une fois cette période de temps écoulée, le navigateur vérifie à nouveau si la restriction via HSTS est toujours valide.
Fonctionnalités HSTS
La mise en place de HSTS présente non seulement l’avantage de garantir que seules des connexions sécurisées peuvent être utilisées, mais son utilisation s’accompagne également de certaines conditions dont il faut être conscient avant de procéder au changement :
Une fois que l’entrée HSTS a été créée par le navigateur de l’utilisateur, elle ne peut être supprimée — du moins avant l’expiration du délai spécifié — qu’avec une connaissance approfondie du navigateur en question. Notez que cela ne s’applique pas à la plupart des utilisateurs.
La connexion sera rejetée si, entre autres, le certificat a expiré ou a été remplacé par un certificat auto-signé. Ces pages ne peuvent pas être contournées, même avec une exception de confiance temporaire accordée à un certificat.
À l'inverse, le HSTS n'est pris en compte que si le certificat est considéré comme fiable lors de l'établissement initial de la connexion. Dans le cas contraire, le navigateur ne crée pas d'entrée pour le HSTS, de sorte que ce mécanisme de protection supplémentaire n'est pas utilisé.
Configuration du serveur web Apache
Pour définir cette option, ajoutez l'entrée suivante à la configuration HTTPS.
Sous Debian/Ubuntu, il s'agit par défaut du fichier default-ssl.conf :
Important : définissez d'abord une période de temps courte — par exemple, 600 secondes — pour tester le paramètre, sinon la connexion risque d'être définitivement rejetée en cas d'erreur ! Pour en savoir plus, consultez la section Fonctions spéciales ci-dessous.
Pour vérifier si le nouveau paramètre fonctionne, vous pouvez utiliser le programme « curl » pour interroger le serveur.
Dans cet exemple, seules les 4 premières lignes de sortie sont affichées :