2. FAQ - Problèmes liés au serveur¶

2.1. Certificats SSL/TLS et confiance¶

2.1.1. Comment renouveler mon autorité de certification (CA) SSL/TLS avant son expiration ?¶

Lors du remplacement d’un certificat de CA avant son expiration, la nouvelle CA doit être déployée sur les agents avant que le serveur WAPT ne commence à utiliser le nouveau certificat.

Cela permet aux agents de faire confiance au nouveau certificat tant que la CA existante est encore valide.

Danger

Avertissement important pour les futures mises à jour du serveur WAPT

Lors de la prochaine mise à jour du serveur WAPT, assurez-vous que les agents WAPT utilisent le certificat mis à jour plutôt que l’ancien. Ne pas vérifier ce point peut entraîner des problèmes de connectivité entre les agents et le serveur.

Important

Cette procédure est destinée aux transitions de certificats suivantes :

D’un certificat épinglé vers un autre certificat épinglé, en utilisant une PKI interne ou un certificat auto-signé.
D’un certificat épinglé vers un certificat commercial.
D’un certificat commercial vers un certificat épinglé.

Si vous remplacez un certificat commercial par un autre certificat commercial, conserver verify_cert = 1 devrait suffire.

Testez la procédure dans un environnement de développement avant de la déployer en production.

Afficher la solution

1. Préparer un environnement de test

Clonez le serveur WAPT et créez un environnement de test maîtrisé.

Ajoutez le serveur cloné et un agent WAPT, par exemple une machine Windows, à l’environnement de test. Assurez-vous que les deux machines peuvent communiquer sur le réseau.

Installez l’agent WAPT actuel depuis le serveur sur la machine de test.

Si les machines sont dans un groupe de travail, utilisez l’adresse IP du serveur à la place de son FQDN pour établir la communication. Par exemple :

https://10.11.9.70

Vérifiez que l’agent fonctionne correctement :

Exécutez wapt-get update pour vérifier la synchronisation des paquets.
Envoyez un message de test avec waptmessage pour confirmer la communication.

Ne poursuivez qu’une fois ces opérations réussies.

2. Fusionner les certificats de CA existant et nouveau

Connectez-vous au serveur WAPT et inspectez le fichier de certificat actuel :

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

Identifiez le certificat de CA actuel à la fin du fichier.

Copiez le certificat de CA actuel dans un fichier texte, par exemple 2ca.txt.

Ouvrez le nouveau certificat de CA dans un éditeur de texte et ajoutez son contenu à la suite du fichier.

Enregistrez le fichier obtenu et créez un fichier de certificat nommé 2ca.crt.

3. Créer un paquet de configuration

Dans la Console WAPT, ouvrez :

Paquets WAPT > Configuration dynamique de l’agent hôte.

Configurez le paquet comme suit :

Saisissez un nom de paquet, par exemple prefix-renew_ca-dev.
Définissez une priorité suffisamment élevée pour garantir que le paquet est appliqué comme prévu.
Sélectionnez le niveau de maturité PROD.
Choisissez le panneau de configuration Global.
Sélectionnez Utiliser un bundle spécifique et ajoutez le nouveau fichier de CA, par exemple wapt/ssl/server/2ca.crt.
Cliquez sur Enregistrer.

Ajout d'un nouveau certificat de CA à un paquet de configuration WAPT — Ajout d’un nouveau certificat de CA à un paquet de configuration WAPT.¶

4. Déployer le paquet de configuration

Déployez le paquet de configuration sur la machine de test.

Vérifiez que le nouveau certificat de CA est présent sur l’agent et que l’agent peut toujours communiquer avec le serveur.

Une fois la procédure validée, déployez le paquet sur le reste de votre parc.

5. Remplacer le certificat du serveur

Ne remplacez le certificat du serveur qu’après que toutes les machines concernées ont reçu la nouvelle CA.

Connectez-vous au serveur WAPT et ouvrez le répertoire SSL :

cd /opt/wapt/waptserver/ssl/

Sauvegardez le certificat actuel :

mv cert.pem cert.pem.2025

Créez un nouveau fichier cert.pem contenant la chaîne de certificats complète du nouveau certificat.

vi cert.pem

Si votre environnement utilise une PKI interne ou un certificat auto-signé et possède un fichier ca_cert.pem distinct, sauvegardez-le également :

mv ca_cert.pem ca_cert.pem.2025

Créez un nouveau fichier ca_cert.pem contenant uniquement le nouveau certificat de CA.

Redémarrez Nginx :

systemctl restart nginx.service

6. Mettre à jour le cache de certificats de la Console WAPT

Lorsque le serveur commence à utiliser le nouveau certificat, les machines peuvent disparaître de la Console WAPT, car la Console fait toujours confiance à l’ancienne CA.

Le répertoire local des certificats se trouve à l’emplacement suivant :

%LOCALAPPDATA%\waptconsole\ssl\server

Pour mettre à jour le certificat de confiance :

Supprimez l’ancien fichier de certificat de CA, par exemple xxx.crt.
Copiez le fichier de CA fusionné 2ca.crt dans le même répertoire.
Redémarrez la Console WAPT.

Vérifiez que les machines réapparaissent dans l’inventaire. Testez les mises à jour de paquets et la distribution des messages.

La transition de CA est terminée lorsque les agents et la Console communiquent correctement avec le nouveau certificat.

7. Identifier les machines qui n’ont pas reçu la nouvelle CA

Recherchez les machines qui n’ont pas communiqué avec le serveur récemment.

La requête SQL suivante liste les machines qui n’ont pas été vues depuis plus de 14 jours :

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;

Ajustez l’intervalle selon vos besoins.

Pour plus d’informations sur l’onglet de reporting, voir Utiliser la fonction de requête dans WAPT .

2.1.2. Comment renouveler une CA SSL/TLS qui a déjà expiré ?¶

Si l’autorité de certification (CA) a déjà expiré, les agents peuvent ne plus être en mesure d’établir une connexion de confiance avec le serveur WAPT.

Il n’existe pas de procédure native unique qui rétablisse automatiquement le contrôle de toutes les machines concernées. La méthode de récupération dépend de l’environnement et des mécanismes de gestion disponibles.

Afficher la solution

Cas 1 : Machines gérées via Active Directory

Si une part importante des machines appartient à un domaine Active Directory, utilisez des objets de stratégie de groupe (GPO) pour distribuer le nouveau certificat de CA et mettre à jour la configuration de l’agent WAPT.

Déployer le nouveau certificat de CA

Ouvrez la Gestion des stratégies de groupe et configurez le chemin suivant :

Configuration ordinateur ‣ Préférences ‣ Paramètres Windows ‣ Fichiers

Utilisez la GPO pour copier le nouveau certificat de CA dans le répertoire wapt/ssl/server de l’agent.

Copie du nouveau certificat de CA à l'aide d'une GPO — Copie du nouveau certificat de CA à l’aide d’une GPO.¶

Mettre à jour la configuration de l’agent WAPT

Configurez la GPO sous :

Configuration ordinateur ‣ Préférences ‣ Paramètres Windows ‣ Fichiers INI

Mettez à jour les paramètres appropriés dans wapt-get.ini afin que l’agent utilise le nouveau certificat de CA.

Mise à jour de la configuration INI de l'agent WAPT à l'aide d'une GPO — Mise à jour de la configuration INI de l’agent WAPT à l’aide d’une GPO.¶

Cette approche permet d’automatiser le processus de récupération sur l’ensemble des machines jointes au domaine.

Cas 2 : Machines non gérées via Active Directory

Les machines hors Active Directory peuvent nécessiter une intervention manuelle.

Commencez par remplacer le certificat du serveur par le nouveau certificat et redémarrez Nginx.

Sauvegardez le certificat existant avant de le remplacer :

mv cert.pem cert.pem.2025
vi cert.pem
systemctl restart nginx.service

Assurez-vous que la configuration du certificat et de la clé privée est correcte pour votre environnement. Ne remplacez ni ne supprimez une clé privée sans disposer de la clé et du certificat de remplacement correspondants.

Transférez ensuite le nouveau certificat de CA dans le répertoire wapt/ssl/server de l’agent, par exemple à l’aide d’une clé USB.

Mettez à jour le paramètre verify_cert dans wapt-get.ini pour qu’il pointe vers le nouveau certificat de CA :

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

Redémarrez le service WAPT et enregistrez à nouveau l’agent :

net stop waptservice
net start waptservice
wapt-get register

Enfin, vérifiez que la machine réapparaît dans la Console WAPT et qu’elle peut mettre à jour des paquets et envoyer des messages.

Cette procédure est longue, mais elle peut être nécessaire pour les machines qui ne peuvent pas être gérées via Active Directory.

Indication

Lors du remplacement d’un certificat commercial par un autre certificat commercial, conserver verify_cert = 1 peut suffire. Validez ce comportement dans un environnement de test avant de déployer le changement en production.

2.1.3. Pourquoi l’agent WAPT signale-t-il une incohérence de nom d’hôte dans le certificat ?¶

L’agent WAPT peut signaler l’erreur suivante lorsque la vérification du certificat est activée :

Certificate CN ### sent by the WAPT Server does not match URL host ###

Cela signifie que le nom commun (CN) du certificat, ou le nom d’hôte couvert par ses noms alternatifs du sujet (SAN), ne correspond pas au nom d’hôte utilisé par l’agent pour se connecter au serveur.

Afficher la solution

1. Vérifier le nom d’hôte du serveur configuré

Ouvrez le fichier wapt-get.ini de l’agent WAPT et vérifiez la valeur de wapt_server.

Assurez-vous que le nom d’hôte configuré correspond au nom d’hôte couvert par le certificat du serveur.

2. Vérifier le certificat du serveur

Si le nom d’hôte configuré est correct, le certificat a peut-être été généré avec un nom d’hôte incorrect.

Cela peut se produire si une erreur est survenue lors de la post-configuration du serveur WAPT, par exemple à cause d’une faute de frappe.

3. Régénérer les certificats auto-signés si nécessaire

Si le serveur utilise des certificats auto-signés et que le certificat contient un nom d’hôte erroné, régénérez les certificats en utilisant le bon FQDN du serveur.

Sur le serveur WAPT, sauvegardez le répertoire SSL existant avant de procéder à des modifications.

La procédure d’origine identifie le répertoire suivant :

/opt/wapt/waptserver/apache/ssl/

Après avoir sauvegardé les fichiers, ne supprimez les fichiers de certificats obsolètes que si une régénération est nécessaire, puis relancez le script de post-configuration avec les mêmes arguments d’installation et le bon FQDN.

Voir la post-configuration de WAPT pour la procédure de post-configuration.

4. Relancer la vérification du certificat

Relancez la commande suivante :

wapt-get enable-check-certificate

Vérifiez que la commande s’exécute avec succès et que l’agent peut communiquer avec le serveur WAPT.

2.2. Disponibilité du serveur WAPT et reprise après sinistre¶

2.2.1. Que faire si mon serveur WAPT est hors service ?¶

Si le serveur WAPT est détruit ou devient indisponible à la suite d’un incendie, d’une inondation, d’une panne matérielle ou d’un autre incident, la procédure de récupération dépend de l’urgence et de la disponibilité des sauvegardes.

Afficher la solution

1. Évaluer l’urgence

Déterminez si une action immédiate est nécessaire.

Si vous devez déployer un paquet ou une mise à jour urgente, la restauration du service est critique.
Si vous n’utilisez pas régulièrement WAPT pour les mises à jour, le déploiement de paquets ou le reporting, vous disposez peut-être de plus de temps pour restaurer le serveur.

2. Restaurer depuis une sauvegarde externe si disponible

Si une solution de sauvegarde externe est disponible, suivez Sauvegarder le Serveur WAPT pour recréer le serveur WAPT.

3. Recréer le serveur WAPT si aucune sauvegarde exploitable n’est disponible

La méthode de récupération suivante est destinée principalement aux environnements disposant d’un Active Directory et d’un grand nombre d’agents WAPT joints au domaine.

Commencez par créer un nouveau serveur WAPT :

Vérifiez les prérequis du serveur.
Installez le serveur selon le système d’exploitation en utilisant Installer le Serveur WAPT.
Installez et configurez la Console WAPT en utilisant Comment installer la Console de gestion WAPT.

4. Mettre à jour la configuration de l’agent WAPT à l’aide d’une GPO

Avant d’effectuer des modifications, inspectez le fichier wapt-get.ini existant sur les agents.

Identifiez les paramètres à modifier pour faire pointer les agents vers le nouveau serveur.

Dans la Gestion des stratégies de groupe, ouvrez :

Configuration ordinateur ‣ Préférences ‣ Paramètres Windows ‣ Fichiers INI

Utilisez une GPO pour mettre à jour les paramètres concernés dans wapt-get.ini.

Avertissement

Si vous utilisez des paquets de configuration WAPT, vérifiez également la section [default-global] et mettez à jour les paramètres qui font référence à l’ancien serveur.

GPO utilisée pour mettre à jour le fichier INI de l'agent WAPT — GPO utilisée pour mettre à jour le fichier INI de l’agent WAPT.¶

L’exemple modifie le paramètre verify_cert afin d’épingler le nouveau certificat du serveur WAPT. D’autres modifications peuvent être nécessaires selon la configuration.

Une fois la GPO appliquée, vérifiez que les agents se connectent au nouveau serveur et réapparaissent dans l’inventaire WAPT.

5. Mettre en place des sauvegardes externes régulières

Configurez des sauvegardes régulières stockées en dehors du serveur WAPT.

Cela vous permet de restaurer rapidement le serveur en cas de nouvelle défaillance.

2.2.2. Pourquoi les agents WAPT ne parviennent-ils pas à se connecter après une restauration du serveur ?¶

Après la reconstruction d’un serveur WAPT, les agents peuvent encore pointer vers l’ancien serveur ou ne faire confiance qu’à son certificat.

Afficher la solution

1. Vérifier l’adresse du serveur

Vérifiez le paramètre wapt_server dans wapt-get.ini.

Assurez-vous qu’il pointe vers le nouveau serveur et que le nom d’hôte configuré se résout vers la bonne adresse IP.

2. Vérifier le certificat de confiance

Si le certificat du serveur a changé, vérifiez que l’agent fait confiance au nouveau certificat.

Mettez à jour verify_cert et le fichier de certificat de CA selon les exigences de la configuration des certificats.

3. Vérifier les paquets de configuration

Si des paquets de configuration WAPT sont utilisés, vérifiez que la section [default-global] contient les bons paramètres de serveur et de certificat.

4. Vérifier la communication

Une fois la configuration corrigée, redémarrez le service WAPT et testez les mises à jour de paquets et la distribution des messages.

2.3. Configuration d’un reverse proxy¶

2.3.1. Comment configurer un reverse proxy devant le serveur WAPT ?¶

Les reverse proxies qui effectuent une interception TLS ou une terminaison TLS, y compris les pare-feu applicatifs web (WAF), ne sont plus supportés.

Un reverse proxy placé devant le serveur WAPT doit fonctionner comme un simple proxy de transfert TLS basé sur l’indication du nom de serveur (SNI). Il doit transférer le flux TLS sans déchiffrer ni inspecter le trafic HTTPS.

Avec cette configuration, le traitement TLS et la vérification des certificats restent entre le client et le serveur WAPT.

Afficher la solution

1. Configurer la résolution DNS

L’agent WAPT résout le nom d’hôte du serveur configuré via le DNS et se connecte à l’adresse IP retournée.

La décision de routage est donc prise par le DNS :

Sur le réseau interne, le DNS interne doit résoudre le nom d’hôte du serveur WAPT directement vers l’adresse IP interne du serveur, en contournant le reverse proxy.
En dehors du réseau, le DNS public doit résoudre ce même nom d’hôte vers l’adresse IP publique du reverse proxy.

Le reverse proxy transfère ensuite la connexion TLS vers le serveur WAPT interne.

2. Installer le module stream de Nginx

Sur le serveur reverse proxy, assurez-vous que le module stream de Nginx est installé.

Debian et Ubuntu : libnginx-mod-stream
Red Hat et dérivées : nginx-mod-stream

3. Configurer le transfert stream de Nginx

Créez ou modifiez le fichier suivant sur le serveur reverse proxy :

/etc/nginx/modules-enabled/80-stream.conf

Ajoutez la configuration suivante en remplaçant le nom d’hôte et l’adresse IP par les valeurs utilisées dans votre environnement :

stream {
    tcp_nodelay on;

    map $ssl_preread_server_name $https_upstream {
        wapt.mydomain.com 192.168.2.5:443;
    }

    server {
        listen 443;

        resolver 127.0.0.1;

        proxy_pass $https_upstream;
        ssl_preread on;
    }
}

Dans cet exemple, 192.168.2.5 est l’adresse IP interne du serveur WAPT.

Vérifiez que le fichier de configuration est chargé par une directive include appropriée dans /etc/nginx/nginx.conf. Certaines installations de Nginx n’incluent pas automatiquement les fichiers de modules-enabled.

Ne combinez pas cette configuration avec un bloc HTTP server ou une directive HTTP default_server à l’écoute sur la même adresse et le même port. L’objectif est de transférer le flux TLS brut sans traitement au niveau HTTP.

4. Vérifier les exigences relatives au certificat

Comme le reverse proxy ne termine pas le TLS, le certificat présenté par le serveur WAPT est vérifié par le client.

Le nom commun (CN) du certificat ou l’un de ses noms alternatifs du sujet (SAN) doit correspondre au nom d’hôte configuré dans l’agent WAPT.

Le certificat ne doit pas reposer sur l’identité du reverse proxy.

5. Vérifier la configuration

Inspectez les journaux 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 requêtes provenant de clients externes.

Si les connexions externes n’apparaissent pas dans les journaux du serveur WAPT, vérifiez :

La résolution DNS publique.
La configuration SNI du reverse proxy.
La destination et le port de transfert.
La connectivité réseau entre le reverse proxy et le serveur WAPT.

Note

Une configuration similaire peut être mise en œuvre avec la fonctionnalité de TLS passthrough de HAProxy. Cette configuration n’est pas couverte par le support WAPT ; reportez-vous à la documentation de HAProxy pour plus de détails.

2.4. Administration et maintenance du serveur WAPT¶

2.4.1. Comment réinitialiser le mot de passe SuperAdmin du serveur WAPT ?¶

Si vous avez oublié le mot de passe SuperAdmin de la Console WAPT, vous pouvez relancer le processus de post-configuration du serveur WAPT.

Afficher la solution

1. Se connecter au serveur WAPT

Connectez-vous au serveur WAPT Linux en SSH.

2. Obtenir les privilèges d’administration

Connectez-vous en root ou utilisez sudo.

3. Relancer le script de post-configuration

Exécutez le script de post-configuration du serveur WAPT.

Suivez les instructions pour reconfigurer le serveur et réinitialiser les paramètres d’administration concernés.

2.4.2. Que peut-il mal se passer lors de la mise à jour du serveur WAPT ?¶

Plusieurs problèmes peuvent empêcher la mise à jour d’un serveur WAPT de se terminer correctement.

Afficher la solution

1. L’antivirus bloque l’installation

Un antivirus peut bloquer l’installation ou l’exécution de composants WAPT.

WAPT est un outil de déploiement de logiciels qui maintient une connexion WebSocket avec un serveur de gestion centralisé. Ce comportement peut être considéré comme suspect par certains antivirus.

Si une mise à jour échoue, consultez la console de gestion de l’antivirus et ses journaux.

Si l’antivirus est en cause, appliquez l’exception appropriée selon la politique de sécurité de votre organisation. Dans certains environnements, il peut également être nécessaire de signer le binaire waptagent.exe avec un certificat interne de signature de code.

2. Une autre application verrouille une DLL de WAPT

Une autre application peut verrouiller une DLL fournie avec WAPT.

Cela peut se produire lorsqu’un installeur utilise la variable système %PATH% et charge les DLL OpenSSL ou Python de WAPT à la place de ses propres dépendances.

Consultez les journaux de mise à jour et identifiez le processus qui détient le fichier avant de relancer l’installation.

3. Les tâches planifiées Windows ne fonctionnent pas correctement

Une installation Windows défectueuse ou un problème de tâche planifiée peut empêcher le processus de mise à jour de s’exécuter correctement.

Consultez le Planificateur de tâches Windows, l’historique des tâches et les journaux WAPT concernés pour identifier la défaillance.

2.4.3. Est-il possible de déplacer le répertoire web du serveur WAPT, /var/www, vers un autre répertoire, tel que /opt/www ?¶

Bien que certains chemins d’accès au serveur WAPT puissent être configurés dans le fichier waptserver.ini, le répertoire /var/www est toujours référencé directement par certains scripts d’installation et paquets WAPT. Il n’est donc pas entièrement pris en charge en tant que remplacement configurable.

Afficher la solution

Conservez /var/www comme chemin d’accès par défaut et utilisez un montage via fstab ou un lien symbolique pour le rediriger vers l’emplacement de stockage souhaité, tel que /opt/www. Cela permet de déplacer l’espace de stockage tout en conservant la compatibilité avec WAPT. Pour créer un lien symbolique, vous pouvez consulter cette page pour Windows ou celle-ci pour Linux.