RDP-Dateien signieren: Warnmeldung in Windows

Seit dem Sicherheitsupdate vom April 2026 zeigt die Remotedesktopverbindung bei jeder geöffneten .rdp-Datei einen Sicherheitsdialog, bevor überhaupt eine Verbindung aufgebaut wird. Ist die Datei nicht signiert, trägt der Dialog das Banner „Vorsicht: Unbekannte Remoteverbindung", das Feld Herausgeber steht auf „Unbekannter Herausgeber", und sämtliche Umleitungen (Laufwerke, Zwischenablage, Drucker, Kamera, Smartcard) sind abgeschaltet. Wer sie braucht, hakt sie bei jeder einzelnen Verbindung neu an.

Hinter der Änderung steckt CVE-2026-26151, eine aktiv ausgenutzte Spoofing-Schwachstelle im Remotedesktop. Angreifer verschicken präparierte .rdp-Dateien per Phishing-Mail. Öffnet das Opfer die Datei, verbindet sich der Client stillschweigend mit Angreifer-Infrastruktur und gibt dabei lokale Ressourcen frei. Genau diesen Automatismus bricht Microsoft auf, indem jede Umleitung eine bewusste Nutzerentscheidung erzwingt.

Eine Erwartung solltest du dabei sofort korrigieren: Signieren wird den Dialog nicht verschwinden lassen. Es tauscht ihn gegen die freundlichere Variante mit dem Banner „Bestätigen Sie den Herausgeber dieser Remoteverbindung" und deinem Namen im Herausgeber-Feld. Damit die Abfrage komplett wegfällt, brauchst du einen zweiten Schritt, den die meisten Anleitungen unterschlagen. Der steht weiter unten im Abschnitt zur Vertrauensliste.

Nicht betroffen sind manuelle Verbindungen, bei denen du den Hostnamen direkt in mstsc eintippst. Ebenfalls unauffällig bleiben Azure Virtual Desktop und Windows 365, weil Microsoft diese Dateien selbst signiert. Taucht dort ein Warndialog auf, ist das ein Grund abzubrechen und nachzuforschen.

Zusätzliche Software brauchst du nicht, Windows bringt alles mit:

Für Einzelrechner, Testumgebungen und Netze ohne Active Directory reicht ein selbstsigniertes Zertifikat.

Der Parameter -Type CodeSigningCert setzt die passende erweiterte Schlüsselverwendung und die Schlüsselverwendung bereits selbst, deshalb entfällt hier jede weitere Angabe dazu. Ersetze den Wert bei -Subject durch den Namen, der später im Dialog als Herausgeber erscheinen soll:

Damit der Client die Signatur überhaupt als gültig auswerten kann, muss er die Kette schließen können. Bei einem selbstsignierten Zertifikat ist das Zertifikat gleichzeitig die Wurzel, es gehört also in den Speicher für vertrauenswürdige Stammzertifizierungsstellen. Fehlt dieser Import, behandelt der Client die Datei wie eine unsignierte, selbst wenn du alle weiteren Schritte korrekt ausführst.

Der zweite Import in den Speicher für vertrauenswürdige Herausgeber schadet nicht und ist für andere signierte Inhalte sinnvoll. Für den RDP-Dialog bringt er dir allerdings nichts, weil mstsc.exe diesen Speicher nicht auswertet. Warum das so ist, steht im Abschnitt zur Vertrauensliste.

Auf jedem Rechner, der die signierte Datei öffnen soll, muss dasselbe Stammzertifikat liegen:

Verteile die .cer-Datei per GPO, Intune oder manuell in den Stammspeicher der Zielrechner. Und weil das ein echter Eingriff ist: Ein selbstsigniertes Codesignatur-Zertifikat im Stammspeicher gilt danach systemweit als vertrauenswürdig, nicht nur für RDP. Wer an den privaten Schlüssel kommt, kann beliebigen Code signieren, dem diese Rechner dann vertrauen. Halte den Schlüssel also nicht exportierbar auf einem beliebigen Admin-Notebook vor, sondern behandle ihn wie ein Signaturschlüssel-Material und nicht wie eine Konfigurationsdatei.

In einer Domäne ist der Weg über die Enterprise CA sauberer, weil alle Domänenmitglieder der internen Stammzertifizierungsstelle bereits vertrauen. Der Verteilungsaufwand für das Stammzertifikat entfällt damit komplett.

Öffne certsrv.msc, klicke mit der rechten Maustaste auf Zertifikatvorlagen und wähle Neu, dann Auszustellende Zertifikatvorlage. In der Liste steht die Vorlage unter dem Anzeigenamen Codesignatur. Per PowerShell arbeitest du mit dem Vorlagennamen, nicht mit dem Anzeigenamen:

Fordere das Zertifikat auf dem Rechner an, auf dem du später signierst, und lege es im selben Speicher ab, den du in der ganzen Kette verwendest:

In der Praxis ist die Vorlage oft für Benutzer und nicht für Computer berechtigt. Wirft der Befehl einen Berechtigungsfehler, prüfst du in der Vorlagenverwaltung die Registerkarte Sicherheit auf das Recht Registrieren für das anfordernde Konto.

Das eigentliche Signieren ist ein Aufruf. Zuerst holst du den Fingerabdruck aus dem Computerspeicher:

Dann signierst du die Datei:

Hier lauert ein Namensfallstrick, der reihenweise für Fehlversuche sorgt: Der Schalter heißt /sha256, erwartet aber den SHA-1-Fingerabdruck des Zertifikats, auch bei einem mit SHA-256 signierten Zertifikat. Genau den liefert die Eigenschaft .Thumbprint in PowerShell, weshalb der Ablauf oben passt. Wer den Wert stattdessen aus einem SHA-256-Feld kopiert, bekommt keinen Treffer. Auf Windows Server 2012 R2 und älter existiert /sha256 noch nicht, dort heißt der Schalter /sha1. Umgekehrt weisen aktuelle Windows-Versionen ein mit SHA-1 signiertes Zertifikat mit dem Fehlercode 0x8007000d zurück.

Vor dem produktiven Lauf kannst du mit /l trocken testen. Der Schalter prüft die Signierung, ohne die Eingabedatei zu überschreiben:

Ob eine Datei signiert ist, siehst du auch ohne Tool. Öffne sie im Editor und suche nach den Zeilen signscope:s: und signature:s:. Fehlen sie, ist nichts passiert.

An dieser Stelle scheitern die meisten Anleitungen, und hier liegt auch die Antwort auf die häufigste Rückfrage zu diesem Thema: Das Zertifikat liegt im Stammspeicher, es liegt in den vertrauenswürdigen Herausgebern, die Signatur ist gültig, und der Dialog kommt trotzdem.

Der Grund ist, dass mstsc.exe die Zertifikatsspeicher für diese Entscheidung nicht befragt. Der Client führt eine eigene Liste vertrauenswürdiger .rdp-Herausgeber, und die besteht ausschließlich aus SHA-1-Fingerabdrücken, die per Richtlinie gesetzt sind. Ist die Richtlinie nicht konfiguriert, gilt kein einziger Herausgeber als vertrauenswürdig. Die Zertifikatsspeicher entscheiden nur darüber, ob die Signatur überhaupt gültig ist, die Richtlinie darüber, ob du deswegen weniger gefragt wirst.

Der Pfad liegt unter Computerkonfiguration, Richtlinien, Administrative Vorlagen, Windows-Komponenten, Remotedesktopdienste, Remotedesktopverbindungs-Client. Dort aktivierst du die Einstellung „SHA1-Fingerabdrücke von Zertifikaten angeben, die vertrauenswürdige RDP-Herausgeber darstellen" und trägst den Fingerabdruck ein. Laut Richtlinienbeschreibung entfallen die Warnmeldungen für Dateien, die von einem gelisteten Zertifikat signiert sind. Dieselbe Einstellung existiert auch unter Benutzerkonfiguration, beide Listen werden zusammengeführt.

Ergänzend setzt du „RDP-Dateien von gültigen Herausgebern und Standardeinstellungen des Benutzers für RDP-Dateien zulassen" auf Aktiviert, damit signierte Dateien von vertrauenswürdigen Herausgebern überhaupt zugelassen werden.

Ohne Domäne oder bei Verteilung über Intune schreibst du den Wert direkt:

Der Wert ist vom Typ REG_SZ. Mehrere Zertifikate trägst du kommagetrennt in einem einzigen Wert ein.

Der Fingerabdruck muss in Großbuchstaben und ohne Leerzeichen stehen. Wird ein Eintrag nicht als gültiger Fingerabdruck erkannt, verwirft Windows ihn stillschweigend. Es gibt keine Fehlermeldung, kein Ereignis, nichts. Du siehst nur, dass der Dialog weiterhin erscheint.

Kopierst du den Fingerabdruck aus der Zertifikats-MMC, setzt Windows ein unsichtbares Steuerzeichen vor das erste Zeichen. Der String sieht danach korrekt aus und schlägt beim Vergleich trotzdem fehl. Deshalb liest du ihn besser per PowerShell aus, wie in den Beispielen oben.

Und das Stammzertifikat muss auf dem Client vorhanden bleiben. Fehlt es, bewertet der Client die Datei als unsigniert, und der eingetragene Fingerabdruck läuft ins Leere, weil es gar keine gültige Signatur zu vergleichen gibt.

Für Umgebungen, in denen die Umstellung nicht rechtzeitig fertig wird, gibt es einen Rückfallschalter auf das alte Dialogverhalten:

Microsoft schreibt selbst dazu, dass ein künftiges Windows-Update die Unterstützung für diese Einstellung entfernen kann, auch auf älteren Windows-Versionen. Als Übergangslösung für ein paar Wochen ist das vertretbar, als Dauerzustand nicht. Wer den Schalter setzt, deaktiviert genau die Kontrolle, die den Phishing-Vektor entschärfen soll, und zwar für alle RDP-Verbindungen des Rechners, nicht nur für die eigenen.

Das Signieren von RDP-Dateien ist keine Kosmetik gegen einen lästigen Dialog, sondern die einzige Maßnahme, die den Nutzer in die Lage versetzt, eine manipulierte von einer legitimen Verbindungsdatei zu unterscheiden. Die Signatur belegt zwei Dinge: wer die Datei erstellt hat und dass sie seitdem unverändert ist. Sie belegt nicht, dass die Datei harmlos ist. Ein Angreifer kann ebenfalls signieren, etwa mit einem Namen, der deinem Unternehmensnamen bis auf ein Wort gleicht. Der Blick auf den Herausgebernamen bleibt also Teil der Nutzerschulung und wird nicht durch Technik ersetzt.

Für den Betrieb ergibt sich daraus eine klare Reihenfolge. Zertifikat beschaffen, Vertrauenskette auf den Clients herstellen, Datei fertig konfigurieren, erst danach signieren, und zum Schluss den Fingerabdruck in die Richtlinie eintragen. Jede nachträgliche Änderung an der .rdp-Datei bricht die Signatur, danach steht der Dialog wieder auf unbekanntem Herausgeber. Das ist beabsichtigt und praktisch nützlich, weil eine unterwegs veränderte Datei sofort auffällt. Für dich heißt es aber auch: Signieren gehört ans Ende des Deployment-Prozesses, nicht in die Mitte.

In Domänen ist die interne Zertifizierungsstelle der saubere Weg, weil das Vertrauen bereits verteilt ist und du nur noch die Vorlage freigeben und den Fingerabdruck ausrollen musst. Selbstsignierte Zertifikate lösen das Problem in kleinen Umgebungen schnell, verschieben es aber in Richtung Schlüsselverwaltung: Ein Zertifikat, das auf allen Clients im Stammspeicher liegt, ist ein Vertrauensanker, den du dokumentieren, absichern und vor Ablauf erneuern musst. Setz dir für das Ablaufdatum eine Erinnerung, sonst stehst du in drei Jahren mit einer Flotte plötzlich unsignierter Verbindungsdateien da und suchst die Ursache an der falschen Stelle.