[GELÖST] Domainnamenänderung

[Flipflip]

Hallo zusammen,

Am Wochenende habe ich meine DNS- und SAMBA-Domänennamen geändert (immer noch im nt4-Modus). Seitdem werden die Agenten in der Konsole als verbunden angezeigt, aber wenn ich versuche, ein Update auf einem von ihnen zu erzwingen, erhalte ich die folgende Meldung:

Code: Alle auswählen

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>

Die Botschaft ist eindeutig: Es gibt ein Problem mit der Authentifizierung und dem Zertifikat, das sich auf die alte Domäne bezieht.
Ich habe eine Seite im Wiki gefunden, die erklärt, wie man Zertifikate im Falle von Diebstahl oder Verlust neu generiert. Ich habe jedoch den Eindruck, dass es sich dabei um das Benutzerzertifikat handelt und nicht um das Zertifikat, das der Server zur Kommunikation mit den Agenten verwendet.

Gibt es ein bestimmtes Vorgehen?

Dank im Voraus.
Philippe.

[dcardon]

Hallo Philippe,

verwendest du ein selbstsigniertes Zertifikat oder ein öffentliches Zertifikat (z. B. von Let's Encrypt)?

In deiner `wapt-get.ini`-Datei steht `verify_cert=1`, und der Servername im Zertifikat stimmt nicht mit dem in der Konfiguration überein. Du kannst das Problem vorübergehend beheben, indem du `verify_cert=0` setzt, während du die Zertifikatseinstellungen aktualisierst.

Verwendest du Certificate Pinning? Hast du beispielsweise `verify_cert=c:\program files (x86)\wapt\ssl\moncertif.crt` gesetzt?

Auf einem Linux-Server werden HTTPS-Zertifikate in `/opt/wapt/waptserver/ssl` gespeichert, falls du sie aktualisieren möchtest, um deinen neuen Servernamen widerzuspiegeln. Wenn du jedoch Pinning verwendest, löst das das Problem nicht.

Falls es sich nur um einen Test handelte und du die Anwendung noch nicht produktiv eingesetzt hast, kannst du auf die nächste Version warten. In der Postconf-Datei haben wir die Möglichkeit integriert, ein Subzertifikat mit dem neuen Servernamen im SubjectAltName zu erstellen. Dies sollte das Problem in diesem Fall beheben.

Viele Grüße,

Denis

[Flipflip]

Guten Morgen,

Vielen Dank für Ihre Antwort.

Verwenden Sie ein selbstsigniertes Zertifikat oder ein öffentliches Zertifikat (Let's Encrypt usw.)?

Es ist selbstsigniert

Anscheinend ist in Ihrer `wapt-get.ini`-Datei `verify_cert=1` gesetzt, und der Servername im Zertifikat stimmt nicht mit dem in der Konfiguration überein. Sie können dies vorübergehend beheben, indem Sie `verify_cert=0` setzen, während Sie die Zertifikatseinstellungen aktualisieren.

Seltsamerweise ist in `verify_cert` der lokale Pfad zum Zertifikat auf dem Agenten angegeben. Zum Testen habe ich ihn auf 0 geändert und konnte den Testagenten in der Konsole wieder steuern.

Verwenden Sie Certificate Pinning? Haben Sie also eine verify_cert=c:\program files (x86)\wapt\ssl\moncertif.crt-Datei?

Das habe ich aufgrund der Antwort auf Ihre vorherige Frage angenommen

Auf dem Linux-Server befinden sich die HTTPS-Zertifikate im Verzeichnis `/opt/wapt/waptserver/ssl`, falls Sie diese aktualisieren möchten, um Ihren neuen Servernamen widerzuspiegeln. Wenn jedoch eine Namensfixierung (Pinning) aktiv ist, behebt dies das Problem nicht.

Da ich kein großes Netzwerk habe, kann ich das neue Zertifikat manuell auf den Agenten verteilen. Benötigt das Zertifikat eine spezielle Konfiguration für WAPT, oder reicht ein Standardzertifikat aus?

Falls es sich nur um einen Test handelte und Sie die Anwendung noch nicht in der Produktionsumgebung bereitgestellt haben, können Sie auf die nächste Version warten. In der Postkonfiguration haben wir die Möglichkeit integriert, ein Unterzertifikat mit dem neuen Servernamen im SubjectAltName zu erstellen. Dies sollte das Problem in diesem Fall beheben.

Wie man so schön sagt: „Zu spät!“

[dcardon]

Hallo Philippe,

falls du Active Directory verwendest, kannst du den aktualisierten Agenten mit den geänderten Einstellungen erneut bereitstellen.

Bezüglich des selbstsignierten HTTPS-Zertifikats: Wenn du die Zertifikate nach /opt/wapt/waptserver/ssl löschst oder verschiebst, werden neue Zertifikate mit dem neuen Servernamen generiert. Du musst die Ausgabe von `hostname -f` sorgfältig prüfen, um den FQDN zu ermitteln. Dieser muss in der Datei `wapt-get.ini` auf den Agenten eingetragen sein. Anschließend kannst du entweder das korrekte Zertifikat festlegen (`wapt-get enable-check-certificate`) oder `verify_cert=0` setzen.

Viele Grüße,

Denis