[RESOLU] Changement de nom de domaine

[flipflip]

Bonjour à tous,

Ce week-end j'ai changé mon nom de domaine DNS et SAMBA (encore en mode nt4). Depuis les agents sont visibles comme connecté dans la console mais lorsque je j'ai sur l'un d'eux pour forcer la mise à jour j'ai le message :

Code : Tout sélectionner

C:\Program Files (x86)\wapt>wapt-get update
2024-03-27 11:22:21,305 ERROR Certificate check failed for https://svwapt.nouveaudom/wapt/Packages and verify_cert C:\Program Files (x86)\wapt\ssl\server\svwapt.anciendom.crt
2024-03-27 11:22:21,305 CRITICAL Error merging Packages from wapt into db: None: None
2024-03-27 11:22:21,336 CRITICAL Error merging Packages from wapt-host into db:None : None
Using config file: C:\Program Files (x86)\wapt\wapt-get.ini
Update package list from https://svwapt.nouveaudom/wapt, https://svwapt.nouveaudom/wapt-host
Total packages : 120
Added packages :

Removed packages :

Discarded packages count : 0
Pending operations :
  install:
  upgrade:
  additional:
  remove:
  immediate_installs:
Repositories URL :
  wapt
  wapt-host

C:\Program Files (x86)\wapt>

Le message est clair, il y a un problème avec l'authentification et le certificat qui fait référence à l'ancien domaine.
J'ai trouvé sur le wiki une page qui explique comment re-générer les certificats en cas de vole ou perte mais j'ai l'impression que cela concerne le certificat utilisateur et non celui utilisé par serveur pour communiquer avec les agents.

Est-ce qu'il y a une procédure particulière ?

Merci d'avance.
Philippe.

[dcardon]

Bonjour Philippe,

est ce que vous êtes en certificat autosigné ou bien en certificat public (letsencrypt, etc.) ?

Visiblement vous êtes en verify_cert=1 dans le wapt-get.ini et le nom de serveur dans le certificat ne correspond pas à celui dans la conf. Vous pouvez débloquer la situation en passant un verify_cert=0 le temps de remettre la partie certificat à jour.

Est ce que vous êtes en pinning de certificat? C'est à dire que vous avez un verify_cert=c:\program files (x86)\wapt\ssl\moncertif.crt ?

Sur le serveur en linux, les certificats https sont stocké dans /opt/wapt/waptserver/ssl si vous voulez les mettre à jour par rapport à votre nouveau nom de serveur. Par contre si il y a du pinning ça ne va pas débloquer la situation pour autant.

Si c'était juste un test et que vous n'avez pas encore passé en prod, vous pouvez attendre la prochaine release. Dans le postconf on a intégrer la possibilité de créer un sous-certif avec le nouveau nom de serveur dans le subjectAltName qui devrait permettre de débloquer la situation dans ce cas là.

Cordialement,

Denis

[flipflip]

Bonjour,

Merci de votre réponse.

est ce que vous êtes en certificat autosigné ou bien en certificat public (letsencrypt, etc.) ?

C'est de l'autosigné

Visiblement vous êtes en verify_cert=1 dans le wapt-get.ini et le nom de serveur dans le certificat ne correspond pas à celui dans la conf. Vous pouvez débloquer la situation en passant un verify_cert=0 le temps de remettre la partie certificat à jour.

Bizarrement dans verify_cert j'ai le chemin d'accès local sur l'agent vers le certificat. Pour tester je l'ai passé à 0 et j'ai retrouvé la gestion de l'agent test dans la console.

Est ce que vous êtes en pinning de certificat? C'est à dire que vous avez un verify_cert=c:\program files (x86)\wapt\ssl\moncertif.crt ?

A priori je l'étais au vue de la réponse à votre précédente question

Sur le serveur en linux, les certificats https sont stocké dans /opt/wapt/waptserver/ssl si vous voulez les mettre à jour par rapport à votre nouveau nom de serveur. Par contre si il y a du pinning ça ne va pas débloquer la situation pour autant.

J'ai pas un gros parc donc je peux déployer manuellement le nouveau certificat sur les agents. Est-ce que le certificat doit avoir une config particulière pour wapt ou bien un certificat classique suffit ?

Si c'était juste un test et que vous n'avez pas encore passé en prod, vous pouvez attendre la prochaine release. Dans le postconf on a intégrer la possibilité de créer un sous-certif avec le nouveau nom de serveur dans le subjectAltName qui devrait permettre de débloquer la situation dans ce cas là.

Comme dirait l'autre : "trop tard !"

[dcardon]

Bonjour Philippe,

si vous avez un AD vous pouvez repousser l'agent mis à jour avec les paramètres modifiés.

Pour ce qui est du certificat https autosigné, si vous supprimer/déplacer les certificats dans /opt/wapt/waptserver/ssl des nouveaux certificats seront générés en reprenant le nouveau nom du serveur. Il faut bien vérifier ce que renvoie hostname -f pour avoir le FQDN qui devra être mentionné dans les wapt-get.ini sur les agents, et puis mettre le bon certificat en pinning (wapt-get enable-check-certificate) ou bien passer en verify_cert=0

Cordialement,

Denis