Zum Inhalt springen
IDO DNS Service
Menü
Anmelden Konto anlegen
Alle Themen

Remotedesktop ohne Zertifikatswarnung: Let’s-Encrypt-Zertifikat für RDP

Fernzugriff · Windows Server 2016 und neuer

Zuletzt überarbeitet am

Für alle, denen beim Remotedesktop jedes Mal die Zertifikatswarnung entgegenkommt, obwohl das Zertifikat gültig ist. Diese Seite richtet keinen Tunnel ein — sie setzt ihn voraus und bringt Windows dazu, das vorhandene Zertifikat auch zu benutzen.

Diese Anleitung gehört zu Fernzugriff von IDO DNS Service — was die Leistung kann und was sie kostet.

Warum die Warnung bleibt

Windows benutzt ein Zertifikat nicht von allein, nur weil es im Zertifikatspeicher liegt. Der Remotedesktop erzeugt beim ersten Start ein eigenes, selbst signiertes und bleibt dabei, bis man ihm ausdrücklich ein anderes zuweist. Unseres liegt daneben und wird schlicht ignoriert.

Welche Meldung genau kommt, sagt Ihnen, woran es liegt:

„von einer nicht vertrauenswürdigen Zertifizierungsstelle“
Das selbst signierte ist noch aktiv — die Zuweisung fehlt. Das ist der Regelfall, und dafür sind die Schritte unten da.
„Der Name im Sicherheitszertifikat stimmt nicht überein“
Das Zertifikat wird benutzt, aber Sie verbinden sich über die IP-Adresse oder den kurzen Rechnernamen. In der Remotedesktopverbindung muss der vollständige Name stehen, also server.kunde.idodns.de.

Was Sie brauchen

  • Windows Server 2016 oder neuer — ältere Fassungen lesen die .pfx nicht — und eine PowerShell als Administrator darauf.
  • Einen Kunden im Fernzugriff, zu dem der Server gehört — Name und Zertifikat hängen an seinem Kundennetz. Abgeholt wird über HTTPS bei uns; der Server braucht dafür nur Internet, keinen Tunnel.
  • Einen Namen und ein Zertifikat für den Server im Kundenbereich — siehe unten.

Legen Sie im Kundenbereich unter Fernzugriff → Kunde → Namen und Zertifikat einen Namen für den Server an und lassen Sie das Zertifikat ausstellen. Der Name muss im Netz des Kunden auch auflösen — bei einer FRITZ!Box gehört er dafür vollständig in die Ausnahmen des DNS-Rebind-Schutzes.

Einrichten

Der Weg, den wir empfehlen: das Skript

Let's Encrypt stellt nur 90 Tage aus. Bei jeder Erneuerung ändert sich der Fingerabdruck — und die Zuweisung zeigt dann auf ein Zertifikat, das es nicht mehr gibt. Von Hand hieße das alle zwei Monate: Datei bauen, einlesen, Rechte setzen, zuweisen. Je Kunde. Irgendwann vergisst es jemand, und der Kunde sieht wieder die Warnung.

  1. Abholung einrichten

    Im Kundenbereich bei „Namen und Zertifikat“ auf Automatisch abholen. Sie bekommen mehrere Fassungen — nehmen Sie abholen.ps1 für Windows. Der Zugang darin wird nur dieses eine Mal angezeigt.

  2. Ablegen und einmal von Hand laufen lassen

    Etwa nach C:\ProgramData\IDO\ido-zertifikat.ps1, dann in einer PowerShell als Administrator:

    powershell -ExecutionPolicy Bypass -File C:\ProgramData\IDO\ido-zertifikat.ps1

    Es meldet jeden Schritt. Läuft es durch, ist der Remotedesktop bereits umgestellt — bestehende Sitzungen bleiben, neue benutzen das neue Zertifikat.

  3. Die tägliche Aufgabe anlegen — das macht das Skript selbst

    powershell -ExecutionPolicy Bypass -File C:\ProgramData\IDO\ido-zertifikat.ps1 -Einrichten

    Danach gibt es nichts mehr zu merken. Bei unverändertem Zertifikat tut das Skript nichts, bei einer Erneuerung macht es alle drei Schritte von selbst. Rückgängig mit -Entfernen.

Warum täglich und nicht alle 80 Tage? Ein Lauf, bei dem sich nichts geändert hat, kostet nichts — das Skript fragt einen Wert ab, vergleicht ihn und ist fertig. Ein einzelner Lauf alle 80 Tage wäre dagegen ein einzelner Punkt, an dem alles hängt: Fällt er aus, weil der Server gerade neu startete oder das Netz weg war, ist der nächste Versuch in 80 Tagen — lange nach dem Ablauf. Täglich heißt, der nächste Versuch ist morgen.

Und falls die Abholung doch einmal stillsteht — der Zugang wurde neu erzeugt, die Aufgabe läuft nicht mehr —, schreibt das Skript ab zehn Tagen Restlaufzeit eine Warnung ins Ereignisprotokoll (Anwendung, Quelle „IDO Zertifikat“). Sonst fiele es an dem Tag auf, an dem der Kunde wieder die Warnung sieht.

Von Hand — und was dabei schiefgeht

Falls Sie es einmalig ohne Skript machen wollen: Laden Sie das Zertifikat im Kundenbereich als .pfx herunter (Windows will Zertifikat und Schlüssel in einer Datei; der Zertifikatspeicher kennt kein Gegenstück zu zwei PEM-Dateien) und vergeben Sie dabei ein Kennwort.

  1. Einlesen

    Import-PfxCertificate -FilePath C:\kunde.pfx -CertStoreLocation Cert:\LocalMachine\My -Password (Read-Host -AsSecureString)

  2. Leserecht für den Netzwerkdienst setzen

    In certlm.msc → das Zertifikat → Rechtsklick → Alle Aufgaben → Private Schlüssel verwalten → NETZWERKDIENST mit Lesen hinzufügen.

  3. Dem Remotedesktop zuweisen

    $t = (Get-ChildItem Cert:\LocalMachine\My | Where-Object Subject -like '*server.kunde.idodns.de*').Thumbprint
    $p = (Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\CIMV2\TerminalServices -Filter "TerminalName='RDP-tcp'").__path
    Set-WmiInstance -Path $p -Argument @{SSLCertificateSHA1Hash=$t}

Schritt 2 ist der, der am häufigsten fehlt — und der einzige, der lautlos scheitert. Ohne das Leserecht fällt der Remotedesktop auf sein selbst signiertes Zertifikat zurück: keine Fehlermeldung, kein Eintrag im Ereignisprotokoll. Man sieht weiter die Warnung und sucht an der falschen Stelle.

Wenn es nicht klappt

„Das angegebene Netzwerkkennwort ist falsch“ beim Einlesen der .pfx

Diese Meldung führt in die Irre — meist stimmt das Kennwort. Die Datei ist mit AES-256 verschlüsselt, und das nimmt Windows erst ab Server 2016 an. Auf Server 2012 R2 und älter lässt sich die .pfx nicht einlesen. Diese Fassungen bekommen seit Oktober 2023 ohnehin keine Sicherheitsaktualisierungen mehr.

Die Warnung bleibt, obwohl alles eingerichtet ist

Fast immer Schritt 2: das fehlende Leserecht. Prüfen lässt sich das nicht am Zertifikat, sondern nur am Ergebnis — verbinden Sie sich und sehen Sie nach, welches Zertifikat der Server vorzeigt. Steht dort der Rechnername statt server.kunde.idodns.de, ist es weiter das selbst signierte.

Nach 90 Tagen ist die Warnung wieder da

Dann läuft die Zuweisung auf ein Zertifikat, das erneuert wurde. Genau dafür ist das Skript da; von Hand müssten Sie die drei Schritte jedes Mal wiederholen.

Es soll gar kein Zertifikat auf den Server

Dann ist Fernwartung im Browser der einfachere Weg: Dort endet die verschlüsselte Verbindung am Zugangsserver, und auf dem Zielrechner ist nichts einzurichten — RDP läuft nur noch im internen Netz.

Wie es weitergeht

Die Verbindung öffnet ab jetzt ohne Warnung, und in 90 Tagen bleibt das so — das Skript tauscht das erneuerte Zertifikat nachts von allein. Dasselbe für die anderen Geräte im Kundennetz: die OPNsense über ihre Trust-Schnittstelle, das QNAP-NAS mit einer eigenen Fassung für QTS.

Soll der Kunde selbst an seinen Server, ohne WireGuard auf seinem Rechner, führt der Weg über die Fernwartung im Browser — dort endet die verschlüsselte Verbindung am Zugangsserver. Und ein Server, den man sauber erreicht, ist einer, den man sichern kann: restic läuft unter Windows in der Aufgabenplanung und sichert verschlüsselt in den Cloud-Speicher.

Weiter im selben Bereich

Ihr Gerät ist nicht dabei? Alle Anleitungen

Kommen Sie nicht weiter? Sehen Sie zuerst unter Häufige Fragen nach.

Steht die Antwort dort nicht, schreiben Sie uns an info@idodns.de — mit dieser Anleitung im Betreff. Was mehrfach gefragt wird, steht danach hier.