Hyper-V-Replikat: HTTPS-Zertifikat austauschen

Hyper-V-Replikat mit zertifikatbasierter Authentifizierung nutzt HTTPS (standardmäßig Port 443) und braucht ein gültiges Zertifikat auf jedem Host, sendend und empfangend. In einem Cluster ist die Empfangsseite die Rolle Hyper-V-Replikatbroker, deren Namen die Zertifikate enthalten müssen.

VoraussetzungenCopy Anchor Link

Microsofts Anforderungen an jedes Zertifikat:

• nicht abgelaufen,
• sowohl Clientauthentifizierung als auch Serverauthentifizierung in der erweiterten Schlüsselverwendung, mit privatem Schlüssel,
• Kette bis zu einem vertrauenswürdigen Stammzertifikat,
• CN oder ein SAN passend zum richtigen Namen:
  • ein einzelner Host: sein FQDN,
  • ein empfangender Cluster: der FQDN der Rolle Hyper-V-Replikatbroker,
  • ein sendender Cluster: jeder primäre Host braucht ein Zertifikat, das ebenfalls den FQDN des Replikatbrokers enthält.

Für die Replikation von einem Zwei-Knoten-Cluster zu einem Zwei-Knoten-Cluster heißt das:

Ein Zertifikat pro Knoten mit diesen Namen oder ein Zertifikat mit allen Namen, das auf jedem Knoten eines Clusters importiert wird - beides funktioniert.

Notieren Sie Port, Autorisierungseinträge, alte Fingerabdrücke und den aktuellen Replikationszustand (Get-VMReplication).

Let's Encrypt und die meisten öffentlichen CAs passen nicht. Let's Encrypt nimmt die Clientauthentifizierung nicht mehr in seine Zertifikate auf, und andere öffentliche CAs streichen sie ebenfalls; solche Zertifikate funktionieren für Hyper-V-Replikat nicht. Nutzen Sie eine interne CA mit einer Vorlage, die beide EKUs enthält. aethercert sperrt aus diesem Grund die Kombination aus Hyper-V-Replikat und Let's Encrypt.

Zertifikat Schritt für Schritt austauschenCopy Anchor Link

1. Importieren Sie das neue Zertifikat unter Zertifikate (Lokaler Computer) > Eigene Zertifikate auf jedem Host, der Replikation sendet oder empfängt.

2. Einzelner empfangender Host: neuen Fingerabdruck setzen, übrige Einstellungen beibehalten:

   Copy Text

   Set-VMReplicationServer -ReplicationEnabled $true `
     -AllowedAuthenticationType Certificate `
     -CertificateThumbprint "<fingerabdruck>" `
     -CertificateAuthenticationPort 443

   Oder im Hyper-V-Manager: Hyper-V-Einstellungen > Replikationskonfiguration > Zertifikatbasierte Authentifizierung (HTTPS) verwenden > Zertifikat auswählen.

3. Empfangender Cluster: im Failovercluster-Manager > Rollen mit der rechten Maustaste auf die Rolle Hyper-V-Replikatbroker > Replikationseinstellungen, unter Zertifikatbasierte Authentifizierung (HTTPS) verwenden auf Zertifikat auswählen klicken und das neue Zertifikat wählen. Jeder Knoten braucht es in seinem Speicher.

4. Sendende Seite: Jede replizierte VM speichert das Zertifikat, mit dem sie sich authentifiziert. Stellen Sie jede VM auf dem sendenden Host auf das neue Zertifikat um, in den Replikationseinstellungen der VM im Hyper-V-Manager oder per PowerShell:

   Copy Text

   Get-VMReplication -ReplicationMode Primary | ForEach-Object {
     Set-VMReplication -VMName $_.VMName -CertificateThumbprint "<fingerabdruck>"
   }

5. Gehen Sie Host für Host vor. Beide Seiten prüfen das Zertifikat der Gegenseite gegen die vertrauenswürdige CA, nicht über einen festen Fingerabdruck; die Reihenfolge der Hosts spielt also keine Rolle, solange altes und neues Zertifikat zu einem vertrauenswürdigen Stamm führen. Behalten Sie das alte Zertifikat, bis Get-VMReplication für jede VM den Zustand Normal und eine aktuelle LastReplicationTime zeigt.

Neues Zertifikat prüfenCopy Anchor Link

Testen Sie von einem sendenden Host die Verbindung mit dem neuen Zertifikat:

Test-VMReplicationConnection -ReplicaServerName replica.example.com `
  -ReplicaServerPort 443 -AuthenticationType Certificate `
  -CertificateThumbprint <fingerabdruck>
Get-VMReplication | Format-Table Name,State,Health,LastReplicationTime

Bei einem Cluster verwenden Sie den FQDN des Replikatbrokers als ReplicaServerName. Ein erfolgreicher Test meldet "The connection to the specified Replica server with the specified parameters was successful." Prüfen Sie außerdem, ob die Sperrlisten (CRL) des Zertifikats von beiden Seiten erreichbar sind.

Die Windows-Firewall-Regel Hyper-V Replica HTTPS Listener (TCP-In) muss auf allen empfangenden Hosts aktiviert sein.

RollbackCopy Anchor Link

Setzen Sie auf dem Replikatserver bzw. Broker und in den Replikationseinstellungen der VMs wieder den alten Fingerabdruck und prüfen Sie, ob die Replikation weiterläuft. Das geht nur, solange das alte Zertifikat gültig ist - ist es bereits abgelaufen, korrigieren Sie stattdessen das neue Zertifikat (Namen, EKUs, Kette, CRL).

Häufige ProblemeCopy Anchor Link

• In der EKU steht nur Serverauthentifizierung; Hyper-V-Replikat braucht Client- und Serverauthentifizierung.
• Der FQDN des Hosts oder des Replikatbrokers fehlt im Zertifikat.
• Nur einige Clusterknoten haben das Zertifikat.
• Die CRL ist nicht abrufbar, obwohl der Kette sonst vertraut wird.
• Die Firewall-Regel für den HTTPS-Listener ist nicht aktiviert.

Zertifikatstausch mit aethercert automatisierenCopy Anchor Link

Das aethercert-Deployment-Ziel für Hyper-V-Replikat importiert das Zertifikat und konfiguriert den lokalen Replikatserver für zertifikatbasierte Authentifizierung. Cluster- bzw. Broker-Umfang und die Gegenstellen müssen weiterhin über die ganze Umgebung geplant werden.

Unter Deployment-Ziele finden Sie die Felder dieser Vorlage, die Voraussetzungen auf dem Host und den Stand der Verifizierung.

QuellenCopy Anchor Link

• Microsoft Learn: Hyper-V-Replikat auf einem einzelnen Host aktivieren
• Microsoft Learn: Hyper-V-Replikat in einem Failovercluster
• Microsoft Learn: Set-VMReplicationServer