2. FAQ - Serveur¶

2.1. Comment modifier correctement mon certificat CA (SSL/TLS)¶

2.1.1. Renouvellement du certificat SSL/TLS auprès de l’autorité de certification (CA) avant expiration¶

Danger

Avis important concernant les futures mises à jour du serveur WAPT

Lors de la prochaine mise à jour de votre serveur WAPT, assurez-vous que le nouvel agent WAPT s’appuie sur le certificat mis à jour et non sur l’ancien. L’absence de validation peut entraîner des problèmes de connectivité entre les agents et le serveur.

Le certificat SSL/TLS actuel n’ayant pas encore expiré, les agents restent accessibles à partir de la console WAPT. L’objectif de cette procédure est de déployer la nouvelle autorité de certification (AC) parallèlement à l’autorité existante, de manière contrôlée et progressive.

Important

Cette procédure est destinée à ceux qui souhaitent passer d’un :

certificat d’épinglage à certificat d’épinglage (PKI interne ou certificat auto-signé)
épingler le certificat au certificat commercial
certificat commercial à certificat d’épinglage

Si vous passez d’un certificat commercial à un autre certificat commercial, conservez simplement le paramètre verify_cert = 1.

Cela devrait suffire, mais faites un test avant de passer en production.

2.1.1.1. Procédure détaillée pour le test de l’environnement de développement.¶

1 : Préparer votre environnement de test

Pour tester en toute sécurité le nouvel agent CA, commencez par créer une copie de votre serveur WAPT (clonez-le) et mettez en place un environnement de laboratoire contrôlé.

Configurer l’environnement de test:

Ajoutez votre serveur WAPT et un agent WAPT (par exemple, une machine Windows) à votre laboratoire de test. Assurez-vous de la connectivité réseau entre les deux machines.

Installer l’agent actuel:

Déployez l’agent WAPT actuel de votre serveur sur la machine de test. Si les machines font partie d’un groupe de travail, utilisez l’adresse IP au lieu du FQDN pour établir la communication (exemple : https://10.11.9.70 ).

Vérifier la fonctionnalité de l’agent:

Tester les opérations de base :

Exécutez wapt-get update pour assurer la synchronisation des paquets.
Envoyez un message test à l’aide de waptmessage pour confirmer la communication.

Une fois la phase 1 achevée avec succès, vous pouvez passer à la phase suivante.

2 : Fusionner les deux autorités de certification (AC):

Pour combiner les certificats existants et les nouveaux certificats d’autorité de certification :

Accéder au serveur WAPT naviguer jusqu’au serveur WAPT et localiser le certificat CA actuel :

cat /opt/wapt/waptserver/ssl/cert.pem

Le dernier certificat du fichier est votre autorité de certification actuelle.

Copier l’AC actuelle:

Copier le contenu de l’AC actuelle et le coller dans un fichier texte (par exemple, 2ca.txt).

Ajouter la nouvelle autorité de certification:

Ouvrez votre nouveau certificat d’autorité de certification dans un éditeur de texte, copiez son contenu et ajoutez-le à 2ca.txt.

Sauvegarder et renommer :

Enregistrez le fichier, créez une copie et renommez-la en 2ca.crt (par exemple).

Votre fichier d’autorité de certification fusionné (2ca.crt) est maintenant prêt pour l’étape suivante.

3 : Créer le paquet de configuration.

Dans la console WAPT, les modèles de paquets sont disponibles en cliquant sur WAPT Packages → Host agent dynamic configuration.

Entrez un nom, par exemple prefix-renew_ca-dev. (1)
Entrer une priorité, c’est important de fixer une priorité très élevée. En effet, si un paquet a une priorité plus élevée, cela empêchera votre paquet d’être installé… (2)
Sélectionner le niveau de maturité de PROD. (3)
Choisissez le panneau de configuration Global.
Sélectionnez Use specific bundle et déposez le nouveau fichier ca (exemple ; deposit in wapt/ssl/server/2ca.crt). (4)
Cliquez sur Save pour appliquer la configuration. (5)
Votre paquet de configuration est maintenant prêt.

4 : Installez le paquet sur la machine.

Déployez le paquet de configuration nouvellement créé sur la machine.

5 : déployez le nouveau fichier cert.pem sur le serveur.

Une fois que toutes les machines de votre parc sont dotées de la nouvelle AC :

Accédez au serveur WAPT et naviguez jusqu’au répertoire SSL :

cd /opt/wapt/waptserver/ssl/

Sauvegarder et remplacer les fichiers de certificats :
- Sauvegarde du cert.pem actuel :
```
mv cert.pem cert.pem.2025
```
- Editez cert.pem et collez le contenu de votre nouveau certificat fullchain.
```
vi cert.pem #copy the contents of your new fullchain
```
- Si vous disposez d’une PKI interne ou d’un certificat auto-signé, il se peut que vous disposiez également d’un fichier ca_cert.pem. Sauvegardez-le et remplacez-le :
```
mv ca_cert.pem ca_cert.pem.2025
```
- Editez ca_cert.pem et collez le contenu de votre nouvelle autorité de certification uniquement.
```
vi ca_cert.pem #copy the contents of your new ca only
```
Redémarrer le service Nginx sur le serveur WAPT :

systemctl restart nginx.service

6 : Redémarrer la console WAPT et mettre à jour le cache

Une fois que la machine aura basculé dans la nouvelle configuration, elle disparaîtra de votre console WAPT actuelle. Cela se produit parce que votre console s’appuie sur l’ancien fichier de certificat CA (xxx.crt), situé à l’emplacement suivant : C:\Users\Administrateur\AppData\Local\waptconsole\ssl\server.

Pour y remédier :

Supprimez l’ancien fichier CA (xxx.crt) du répertoire ssl\server.
Placez votre fichier CA fusionné (2ca.crt) dans le même répertoire.
Redémarrez la console WAPT.

La machine devrait maintenant réapparaître dans la console. Testez les mises à jour des paquets et la livraison des messages pour vous assurer que tout fonctionne correctement.

La transition de votre AC est maintenant terminée. Tous les agents doivent désormais communiquer en toute sécurité en utilisant la nouvelle autorité de certification.

Avertissement

Attention aux machines qui n’ont pas été démarrées depuis X jours via cette requête ( comment fonctionne l’onglet reporting ici ).

Dans l’exemple ci-dessous, la valeur est de 14 jours, mais vous pouvez la modifier si nécessaire.

SELECT
uuid,
computer_name,
last_seen_on
FROM
    hosts
WHERE
    TO_TIMESTAMP(last_seen_on, 'YYYY-MM-DD') < CURRENT_TIMESTAMP - INTERVAL '14 days'
ORDER BY
    last_seen_on;

2.1.2. Renouvellement de l’autorité de certification (AC) SSL/TLS après expiration¶

Danger

Avis important concernant les futures mises à jour du serveur WAPT

Si votre autorité de certification (AC) a déjà expiré, il n’existe pas de méthode native pour reprendre le contrôle de votre parc de machines. Cependant, en fonction de votre environnement, vous pouvez utiliser les méthodes de récupération suivantes :

Indication

si vous passez d’un certificat commercial à un autre certificat commercial, il vous suffit de conserver le paramètre verify_cert = 1. Cela devrait suffire, mais faites un test avant de passer à la version prod.

2.1.2.1. Pour les machines dans un environnement Active Directory¶

Si une grande partie de vos machines font partie d’un Active Directory (AD), vous pouvez utiliser des objets de stratégie de groupe (GPO) pour.. :

Ouvrir le gestionnaire de stratégie de groupe :
Déployez le nouveau certificat CA directement dans le répertoire wapt/ssl/server.

Chemin d’accès : Computer Configuration → Preferences → Windows Settings → Files.

par exemple :

copier le crt par gpo — Copier le crt par gpo¶

Mettre à jour le fichier de configuration wapt-get.ini sur toutes les machines.

Chemin d’accès : Computer Configuration → Preferences → Windows Settings → INI Files.

par exemple :

modifier ini par gpo — Modifier l’ini par gpo¶

Cette approche vous permet d’automatiser le processus de récupération sur l’ensemble de vos machines reliées à AD.

2.1.2.2. Pour les machines hors domaine (récupération manuelle)¶

Pour les machines qui ne font pas partie d’Active Directory, la récupération peut nécessiter une intervention manuelle sur chaque machine :

Modifiez le certificat CA (cert.pem et key.pem) sur votre waptserver et relancez le postconf.sh

mv cert.pem cert.pem.2025 #just in case keep the old cert.pem
vi cert.pem #copy your new certificate
systemctl restart nginx.service

Utilisez une clé USB pour transférer le nouveau certificat CA dans le répertoire wapt/ssl/server agent.

Mettre à jour manuellement le fichier de configuration de l’agent (wapt-get.ini).

verify_cert = C:\Program Files (x86)\wapt\ssl\server\your_new_ca.crt

Redémarrez le service WAPT pour appliquer les modifications.

net stop waptservice
net start waptservice
wapt-get register

Vérifier que l’ordinateur est de nouveau en ligne dans la console wapt et qu’il est pleinement fonctionnel (mise à jour des paquets, envoi d’un message wapt).

Cette méthode prend du temps, mais elle est nécessaire pour les machines qui ne sont pas gérées par AD.

2.2. Quelle procédure dois-je suivre si mon serveur WAPT est hors service (incendie, inondation, destruction physique) ?¶

Note

Évaluer le degré d’urgence :

Déterminez si la situation nécessite une action immédiate. Par exemple :

Cas 1 : Si vous devez installer un nouveau paquet ou une mise à jour urgente, l’urgence est critique et une action rapide est nécessaire.

Cas 2 : Si vous n’utilisez pas régulièrement les mises à jour via WAPT, les nouveaux paquets, les déploiements ou les rapports, vous pouvez disposer de quelques jours, voire d’une semaine, avant d’agir.

Note

Si vous disposez d’une solution de sauvegarde externe, vous pouvez suivre cette documentation pour recréer facilement le serveur WAPT.

Cette solution ne s’applique que si vous disposez d’un Active Directory et de nombreux agents membres de votre AD.

1- Créer un nouveau serveur :

La solution la plus rapide est de recréer un serveur. Vous pouvez suivre les liens ci-dessous :

Vérifiez les conditions requises pour le serveur.
Installez le serveur selon le système d’exploitation.
Lancez la console WAPT et créez un agent.

2- Créer une GPO qui modifie plusieurs paramètres dans le wapt-get.ini file :

Avant cela, consultez le fichier wapt-get.ini existant sur vos agents. Notez les paramètres qui doivent être modifiés afin de diriger vos agents vers votre nouveau serveur.

Group Policy Management ‣ Computer Configuration ‣ Preferences ‣ Windows Settings ‣ .ini files

Avertissement

Si vous utilisiez des paquets de configuration WAPT, vous devez également modifier la section [default-global].

Dans cette image, nous modifions la ligne de paramètre verify_cert pour épingler le nouveau certificat du serveur WAPT. D’autres modifications peuvent bien sûr être nécessaires.

Cela permettra aux agents de basculer vers le nouveau serveur et de rétablir le contrôle sur les machines.

3- Mettre en place des sauvegardes externes régulières :

Enfin, la meilleure solution consiste à effectuer des sauvegardes régulières. Cela permettra de restaurer rapidement un clone en cas de défaillance.

2.3. Serveur WAPT derrière un reverse proxy¶

Avertissement

Les reverse proxy (WAF, etc.) effectuant une interception ou une terminaison TLS ne sont plus pris en charge. Si un reverse proxy est placé en amont du serveur WAPT, il doit être configuré comme un simple proxy de transfert TLS basé sur le SNI ; il ne doit en aucun cas déchiffrer ni inspecter lui-même le trafic TLS. L’analyse TLS est effectuée directement sur le serveur WAPT, et non sur le reverse proxy.

Concrètement, cela signifie que le reverse proxy doit utiliser le module « stream » de NginX (voir « ngx_stream_core_module ») au lieu du bloc HTTP « server » standard. Le module « stream » transfère de manière transparente le flux TLS brut vers le serveur WAPT en fonction du nom d’hôte demandé (SNI), sans interrompre ni inspecter le trafic HTTPS ; aucun certificat n’est impliqué du côté du reverse proxy, et aucune configuration HTTP n’est nécessaire.

Comment le client se connecte au serveur WAPT

L’agent WAPT ne sait pas s’il se trouve sur le réseau interne ou sur Internet : il se contente de résoudre le nom d’hôte du serveur configuré via le DNS et se connecte à l’adresse IP renvoyée par le DNS. Cela signifie que la décision de routage (connexion directe ou reverse proxy) s’effectue entièrement au niveau du DNS, et non au sein de l’agent WAPT lui-même :

Sur le réseau interne : votre serveur DNS interne doit résoudre le nom d’hôte du serveur WAPT directement en adresse IP interne du serveur WAPT, en contournant complètement le reverse proxy.

Depuis l’extérieur du réseau (sans VPN) : votre DNS public/externe doit faire correspondre ce nom d’hôte à l”adresse IP publique du reverse proxy, qui transmettra ensuite le flux TLS au serveur WAPT interne.

Prérequis

Vérifiez que le module « stream » est bien installé sur le serveur reverse proxy NginX :

Debian / Ubuntu : libnginx-mod-stream

RedHat et derivés : nginx-mod-stream

Configuration

Créez (ou modifiez) le fichier « /etc/nginx/modules-enabled/80-stream.conf » sur le serveur reverse proxy Nginx :

stream {
    tcp_nodelay on;

    map $ssl_preread_server_name $https_upstream {
        wapt.mydomain.com 192.168.2.5:443;  # 192.168.2.5 is the local IP address of the WAPT server
    }

    server {
        listen 443;

        resolver 127.0.0.1;

        proxy_pass $https_upstream;
        ssl_preread on;
    }
}

Note

Ce bloc « stream » ne doit pas être associé à un bloc « server » HTTP ou à une directive « default_server » sur le même reverse proxy ; l’intérêt de cette configuration est justement de transférer le flux TLS brut sans aucun traitement au niveau HTTP. Vérifiez également que ce fichier est bien chargé en recherchant une directive « include » correspondante dans « /etc/nginx/nginx.conf » ; certaines installations par défaut de Nginx n’incluent pas automatiquement les fichiers du répertoire « modules-enabled ».

2.3.1. Conditions d’obtention du certificat¶

Étant donné que le reverse proxy ne met jamais fin à la connexion TLS, la vérification du certificat HTTPS s’effectue entièrement côté client, par rapport au certificat propre au serveur WAPT — le reverse proxy est invisible pour cette vérification. Par conséquent, le nom commun (ou l’un des noms alternatifs du sujet) du certificat doit correspondre au nom du serveur configuré dans l’agent WAPT, et non à l’identité du reverse proxy lui-même.

2.3.2. Vérification de la configuration¶

Pour vérifier que les connexions externes parviennent bien au serveur WAPT via le reverse proxy, consultez les fichiers journaux suivants directement sur le serveur WAPT (et non sur le reverse proxy) :

tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log

Recherchez les adresses IP sources correspondant à vos clients externes. Si aucune connexion externe n’apparaît ici, vérifiez à nouveau la résolution DNS externe et la configuration « stream » du reverse proxy décrite ci-dessus.

Note

Une configuration similaire est possible à l’aide du module TLS Passthrough d’HAProxy, mais celle-ci n’est pas prise en charge par notre service d’assistance. Veuillez vous reporter à la documentation d’HAProxy pour plus de détails.

Attention

Le support des reverse proxy (WAF, etc.) effectuant des interceptions TLS ou des terminaisons TLS n’est plus supporté. Si vous avez un reverse proxy devant le serveur WAPT, il doit être configuré comme un simple proxy de transfert TLS basé sur SNI (cf. ngx_stream_core_module sur le serveur nginx, par exemple).

Tout d’abord, vous devez vérifier si le paquetage du module stream (libnginx-mod-stream sur Debian / Ubuntu, nginx-mod-stream sur RedHat et dérivés) est installé sur le serveur NginX Reverse Proxy.
Ensuite, vous pouvez insérer le contenu suivant dans /etc/nginx/modules-enabled/80-stream.conf du serveur Reverse Proxy de NginX :

stream {
tcp_nodelay on;

map $ssl_preread_server_name $https_upstream {
  wapt.mydomain.com  192.168.2.5:443;   # 192.168.2.5 is the local IP address of the WAPT server
}

server {
  listen 443;

  resolver 127.0.0.1;

  proxy_pass $https_upstream;
  ssl_preread on;
}
}

Une configuration similaire est possible en utilisant le module HAProxy TLS Passthrough, mais nous ne fournissons pas de support. Veuillez vous référer à la documentation correspondante pour plus de détails.

2.4. Réinitialisation du mot de passe du serveur WAPT Linux¶

Il arrive parfois que l’on installe un serveur WAPT et que l’on oublie son mot de passe.

Pour réinitialiser le mot de passe de la console WAPT SuperAdmin, vous devez relancer le processus de post-configuration sur le serveur WAPT :

Connectez-vous au serveur WAPT avec SSH.
Connectez-vous avec l’utilisateur root (ou utilisez sudo).
Lancez le script de configuration postconfiguration.

2.5. Problèmes lors de l’activation de enable-check-certificate¶

2.5.1. Message « Certificate CN ### sent by the WAPT Server does not match URL host ### »¶

Cela signifie que le CN du certificat envoyé par le serveur WAPT ne correspond pas à la valeur de l’attribut wapt_server dans le fichier wapt-get.ini de l’agent WAPT.

Il y a deux solutions :

Vérifier la valeur de wapt_server dans le fichier wapt-get.ini de l’agent WAPT.

Si la valeur est correcte, Cela signifie surement que cette erreur apparaît durant la génération du certificat auto-signé durant l’étape de post_configuration du serveur WAPT (typing error, …).

Vous DEVEZ ensuite regénérer vos certificats auto-signé.

Sur le serveur WAPT, supprimez le contenu du dossier /opt/wapt/waptserver/apache/ssl/.

Ensuite, relancez le script de post-configuration (le même que celui utilisé lors de l’installation initiale, avec les mêmes arguments et valeurs).

Ensuite, assurez-vous que la valeur de FQDN pour le serveur WAPT est correcte.

Vous pouvez maintenant réessayer enable-check-certificate.

2.6. Qu’est-ce qui peut se passer pendant les mises à jour de WAPTserver ?¶

Le problème le plus courant lors du processus de mise à niveau est le blocage de l’installation par l’antivirus local (WAPT est un logiciel d’installation qui maintient un websocket ouvert vers un serveur de gestion central, de sorte que ce comportement peut être signalé comme suspect par un antivirus, même si cette méthode est la base de la gestion des points finaux…). Si vous rencontrez un problème lors du déploiement de la mise à jour, veuillez vérifier votre console antivirus et mettre waptagent.exe sur liste blanche. Une autre option est de re-signer le binaire waptagent.exe si votre organisation dispose d’un certificat de signature de code interne.
Le deuxième problème le plus courant est que, pour une raison quelconque, un autre programme verrouille une DLL fournie avec WAPT. Cela peut se produire avec des programmes d’installation mal conçus qui récupèrent d’abord la variable locale %PATH% avant de trouver la DLL openssl ou python de WAPT.
Le troisième problème le plus courant est une installation défectueuse de Windows, qui n’exécute pas correctement les tâches planifiées, et oui, nous l’avons vu !