[GELÖST] Problem nach der Erneuerung eines Wildcard-Zertifikats

[jm@rc]

WAPT-Serverversion: 2.1.2,
WAPT-Agentversion: 2.1.2.10652,
WAPT-Setupversion: 2.1.2.10652,
WAPT-Bereitstellungsversion: 2.1.2.10652
, Betriebssystem: Linux RHEL 7.9,
Administration/Clients: Windows 7 und Windows 10,
Lizenz: Enterprise.

Hallo,

das Wildcard-SSL-Zertifikat, das wir für verschiedene Administrationstools verwenden, ist gestern Morgen abgelaufen. Ich hatte es erneuert und überall installiert – dachte ich zumindest. Dieses Zertifikat wird insbesondere für WAPT auf der NGINX-Seite verwendet. Daher habe ich das erneuerte Zertifikat zum ersten Mal auf unserem WAPT-Server aktualisiert und NGINX neu gestartet. Wenn ich die URL unseres Servers aufrufe (z. B. https://xxx-wapt.xxxx.info), kann ich die Startseite unseres Servers erreichen, und das Wildcard-Zertifikat ist bis 2023 gültig

. Ich kann mich jedoch nicht mit der WAPT-Konsole verbinden. Beim Überprüfen meiner lokalen WAPT-Konsolenkonfiguration werden die URLs des Haupt-Repositorys und des WAPT-Servers als gültig erkannt, wenn ich die Option „HTTPS-Serverzertifikat überprüfen“ deaktiviere. Sobald ich die Option aktiviere, funktioniert es nicht mehr. Ein Klick auf „HTTPS-Serverzertifikat abrufen“ ruft mein Zertifikat in „C:\Program Files (x86)\wapt\ssl\server“ korrekt ab, jedoch nicht, wenn die Option aktiviert ist.
Nach Durchsicht der Dokumentation habe ich festgestellt, dass die Option „verify_cert=1“ bei Verwendung eines kommerziellen Zertifikats vorzuziehen ist. Tatsächlich besteht das Problem in meiner Konsole weiterhin, auch wenn diese Option aktiviert ist.

Wenn ich jedoch den Befehl `wapt-get enable-check-certificate` auf meinem Rechner eingebe, erhalte ich einen kritischen Fehler: „
KRITISCH: Der allgemeine Name des Zertifikats (*.xxxx.info) stimmt nicht mit dem Server-Hostnamen (xxx-wapt.xxxx.info) überein.“
Dies ist überraschend, da es sich um denselben Zertifikatstyp wie zuvor handelt. Ich habe sogar versucht, die postconf.sh-Prozedur zu wiederholen, leider ohne Erfolg.

Mein Hauptproblem ist nun, dass alle meine überwachten Rechner in der WAPT-Konsole nicht mehr angezeigt werden. Sie sind zwar alle vorhanden, aber bis auf meinen eigenen Rechner im Status „GETRENNT“.

Ich habe eine Gruppenrichtlinie (GPO) aktualisiert, in der die wapt-get.ini-Datei bereitgestellt wird, indem ich die Option `verify_cert=1` im Abschnitt [global] hinzugefügt habe. Ich ging davon aus, dass es, wenn es in der Konsole funktioniert, auch für den Agenten auf den Client-Rechnern funktionieren würde. Ich habe die GPO gestern auf die Workstations verteilt, während ich heute Morgen auf den Neustart des WAPT-Dienstes wartete. Meine Benutzer haben Verbindungsprobleme.

Gestern Abend waren noch zwei weitere Rechner verbunden, daher dachte ich, alles wäre wieder normal. Heute Morgen ist jedoch kein Rechner mehr verbunden.

Was habe ich falsch gemacht und wie kann ich das Problem beheben?

Vielen Dank im Voraus für Ihre Hilfe.

[dcardon]

Hallo JM,

es gab einige Probleme mit Wildcard-Zertifikaten, nicht direkt im Code, sondern bei deren Abruf und Speicherung. Das Zertifikat wird mit seiner Zertifikatsnummer (CN) gespeichert, und im Fall eines Wildcards enthält die CN ein Sternchen (*), was für das Dateisystem problematisch ist.
Die Verwendung von `verify_cert=1` mit dem Zertifikatspeicher des Betriebssystems funktioniert, sofern die Zertifizierungsstelle (CA) vom Betriebssystem erkannt wird.
Wenn `verify_cert` auf 1 gesetzt ist, muss `enable_verify_cert` nicht ausgeführt werden (es sei denn, Sie versuchen, das Zertifikat zu fixieren).
Es gab kürzlich einige Korrekturen für dieses Problem, aber ich weiß nicht, ob diese bereits in ältere Versionen übernommen wurden.

Viele Grüße,

Denis