Vertrauenswürdige RDP-Zertifikate ohne Zugriffsunterbrechung bereitstellen
Ein RDP-TLS-Zertifikat authentifiziert den Serverendpunkt und schützt den Transportkanal. Verbindungsname, SAN, privater Schlüssel, Vertrauenskette und RDP-Listener-Bindung müssen übereinstimmen.
Auch ein gültiges Zertifikat kann neue Verbindungen verhindern.
Falscher SAN, nicht vertrauenswürdige Kette, fehlender Zugriff auf den privaten Schlüssel oder eine falsche Listener-Bindung können Verbindungen unterbrechen. Bewahren Sie den vorherigen Fingerabdruck und Konsolenzugriff auf.
Warum ein RDP-TLS-Zertifikat erforderlich ist
TLS schützt RDP-Daten während der Übertragung und bindet den öffentlichen Serverschlüssel an den verwendeten DNS-Namen. Ein korrekt validiertes Zertifikat reduziert Abhör- und Identitätsrisiken und beseitigt mehrdeutige Warnungen.
Das Zertifikat authentifiziert nicht den Benutzer und ersetzt MFA nicht. Es bestätigt den Server und errichtet den verschlüsselten Kanal vor der Übertragung von Anmeldedaten und Sitzungsinhalten.
Kann der Zugriff über die Lira-Konsole wiederhergestellt werden?
Ja, solange mindestens ein unabhängiger Verwaltungskanal verfügbar bleibt.
Administratoradresse gesperrt: Portal aus demselben externen Netz öffnen, in der Allowlist Meine öffentliche IP ermitteln wählen, die erkannte öffentliche Adresse hinzufügen und die Firewall-Synchronisierung der Agents abwarten.
Fehlerhafte RDP-MFA-Richtlinie: temporäre Umgehung oder Deaktiviert wählen. Der Online-Agent hebt die Erzwingung beim nächsten Richtlinienaustausch auf.
Falsches RDP-TLS-Zertifikat: Listener wiederherstellen wählen. Der Online-Agent entfernt die erzwungene Bindung, aktiviert Negotiate und startet die RDP-Dienste neu.
Ist der Agentendienst beendet, kann ein Superadmin ihn über zuvor konfiguriertes WinRM neu starten. Sind Agent und WinRM nicht erreichbar, ist eine lokale, Hypervisor-, iLO/iDRAC/KVM/VNC- oder physische Konsole erforderlich.
Was das Zertifikat schützt
TLS verschlüsselt den RDP-Transport und ermöglicht die Prüfung der Serveridentität. Es ersetzt keine starken Zugangsdaten, MFA, Firewallregeln oder Updates.
Die Prüfung beruht auf dem vom Client verwendeten Namen; ein Zertifikat für einen Namen gilt nicht automatisch für Aliase oder IP-Adressen.
1. Endpunktnamen festlegen
Einen stabilen DNS-Namen pro RDP-Endpunkt wählen.
DNS und Netzwerkveröffentlichung auf den vorgesehenen Server richten.
Gespeicherte RDP-Profile auf denselben Namen umstellen.
Wechselnde IP-Adressen nicht als Benutzeridentität des Dienstes verwenden.
2. Vertrauensmodell auswählen
Eine öffentliche CA wie Let’s Encrypt eignet sich für öffentlich delegierte Namen und ACME-Validierung.
Eine interne CA eignet sich für private Namen und verwaltete Geräte mit kontrollierter Stammzertifikatsverteilung.
Selbstsignierte Zertifikate nur für begrenzte Tests verwenden.
Lira automatisiert ACME-Ausstellung und Erneuerung; die permanente DNS-Delegierung der Challenge muss bestehen bleiben.
3. Vor der Bindung prüfen
SAN, EKU Server Authentication, Gültigkeit und vollständige Kette prüfen.
Vorhandenen und zugreifbaren privaten Schlüssel auf dem Zielserver bestätigen.
Aktuelle Listener-Bindung für die Rücknahme dokumentieren.
4. Im Wartungsfenster bereitstellen
Bestehende Administratorsitzung und Konsole bereithalten.
Zuerst einen Pilotserver verwenden.
Fingerabdruck und RDP-Richtlinie über Lira anwenden.
Bei Dienstneustart auf den Onlinezustand des Agents warten.
Von einem zweiten Client mit dem produktiven DNS-Namen verbinden und das Zertifikat prüfen.
Automatische Erneuerung und Wiederherstellung
Lira führt die ACME-DNS-Prüfung aus, überwacht die Laufzeit, erneuert rechtzeitig, installiert das Zertifikat und verifiziert die Bindung. Die delegierte CNAME-Challenge darf nach der ersten Ausstellung nicht entfernt werden.
Scheitern neue Verbindungen, verwenden Sie die Konsole, stellen Sie den vorherigen Fingerabdruck wieder her und prüfen Sie Schlüsselrechte, DNS, SAN und Vertrauenskette.
Häufige Fragen
Warum zeigt RDP weiterhin eine Zertifikatswarnung?
Typische Ursachen sind Namensabweichung, nicht vertrauenswürdiger Aussteller, unvollständige Kette, Ablauf oder Verbindung per IP bei einem reinen DNS-Zertifikat.
Benötigt DNS-01 einen eingehenden Port?
Nein. Der Agent kommuniziert ausgehend über HTTPS; die Domänenkontrolle wird über die delegierte DNS-Challenge bestätigt.
Werden aktive Benutzer getrennt?
Der Import normalerweise nicht, Änderungen an Listener oder Richtlinie können jedoch RDP-Dienste neu starten. Planen Sie ein Wartungsfenster.
Einen Endpunkt vor dem gesamten Serverpark prüfen
Prüfen Sie Name, Vertrauenskette und vorherige Bindung und stellen Sie das Zertifikat zuerst auf einem Pilotserver bereit.