Hallo,
das Verhalten ist korrekt: sobald das HTTPS‑Serverauthentifizierungszertifikat auf dem zentralen WEF‑Kollektor abläuft, bricht die Weiterleitung ab, weil WinRM den Listener nicht mehr mit einem gültigen Zertifikat binden kann. Die Lösung besteht darin, die Zertifikatserneuerung zu automatisieren und den Bindungsprozess für den WinRM‑HTTPS‑Listener ebenfalls automatisiert durchzuführen.
Der empfohlene Weg ist, das Zertifikat über eine interne PKI mit automatischer Registrierung (Autoenrollment) oder über ein Skript zu erneuern. Das Zertifikat muss im lokalen Computer‑Store unter Cert:\LocalMachine\My liegen und den privaten Schlüssel enthalten. Sobald das neue Zertifikat vorhanden ist, muss WinRM den Listener neu binden. Das erfolgt mit:
Code
winrm delete winrm/config/Listener?Address=*+Transport=HTTPS
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="<FQDN>"; CertificateThumbprint="<Thumbprint>"}
Der Thumbprint ist der SHA1‑Fingerabdruck des neuen Zertifikats. Diesen Schritt können Sie in ein Scheduled Task oder ein PowerShell‑Skript einbauen, das nach der Zertifikatserneuerung automatisch ausgeführt wird. Alternativ können Sie mit New-SelfSignedCertificate oder einer CA‑Registrierung ein neues Zertifikat erzeugen und direkt per Skript den Listener neu binden.
Wichtig ist, dass der Hostname im Listener exakt mit dem Subject oder SAN des Zertifikats übereinstimmt, sonst schlägt die Bindung fehl. Für die Automatisierung empfiehlt es sich, ein Skript zu erstellen, das den neuesten gültigen Zertifikatseintrag im Store ermittelt (Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "CN=<FQDN>" } | Sort-Object NotAfter -Descending | Select-Object -First 1) und dessen Thumbprint automatisch in den WinRM‑Listener schreibt.
Damit stellen Sie sicher, dass die WEF‑Clients auch nach Ablauf des alten Zertifikats wieder eine gültige HTTPS‑Verbindung zum Collector herstellen können, ohne dass die Ereignisweiterleitung unterbrochen bleibt.
Domic Vo.