· Henning Scholand · Security · 4 Min. Lesezeit
RemoteApp — Sicherheitswarnung 'Unbekannter Herausgeber' dauerhaft abschalten
Plötzlich erscheint bei bestehenden RemoteApp-Verbindungen ein Sicherheitsdialog — Zwischenablage blockiert, Drucker weg. Ursache ist eine fehlende .rdp-Signatur. So wird das sauber gelöst.

Bestehende RemoteApp-Verknüpfungen funktionieren seit Jahren — und plötzlich erscheint beim Start dieser Dialog:

Der Herausgeber ist „Unbekannt”, die Ressourcen-Checkboxen (Zwischenablage, Drucker, Laufwerke) sind ausgegraut oder standardmäßig deaktiviert. An der Verbindung selbst hat sich nichts geändert. Was ist passiert?
Warum der Dialog nur bei manchen Nutzern erscheint
Das ist keine zufällige Erscheinung — zwei Mechanismen spielen zusammen.
Windows cached die Nutzerentscheidung. Wer den Dialog einmal mit „Verbinden” bestätigt hat, sieht ihn nicht nochmal — solange die .rdp-Datei byte-identisch bleibt. Sobald eine neue Version ausgeliefert wird (Connection-Broker-Feed, neues RD-Web-Download, geänderte Parameter), ist der Cache ungültig und der Dialog erscheint erneut.
Client-Updates verschärfen die Prüfung. Microsoft hat die Signierungsanforderungen in Windows 10/11-Updates von 2024 und 2025 nachgezogen. Ältere Clients haben fehlende Signaturen still ignoriert, neuere erzwingen den Dialog. Auf einem frisch gepatchten Rechner erscheint die Warnung daher, auf einem mit älterem Patch-Stand nicht — obwohl beide dieselbe .rdp-Datei öffnen.
Das Muster ist also: wer „Immer fragen” noch nicht gecacht hat und einen neueren Client betreibt, sieht den Dialog. Das erklärt, warum Rollouts scheinbar willkürlich treffen.
Was Windows hier prüft
Bei RemoteApp-Verbindungen liest der RDP-Client die .rdp-Datei und prüft, ob sie mit einem vertrauenswürdigen Zertifikat signiert ist. Ist sie nicht signiert — oder das signierende Zertifikat nicht im Trusted Publishers Store des Clients hinterlegt — erscheint genau dieser Dialog.
Das Verhalten ist nicht neu, aber Microsoft hat die Prüfung in den letzten Client-Updates verschärft. Verbindungen, die bisher still funktionierten, lösen jetzt die Warnung aus. Der eigentliche Schmerz: Zwischenablage und Drucker funktionieren danach nicht mehr, weil der User die Checkboxen nicht gesehen oder weggeklickt hat.
Schritt 1 — Signing-Zertifikat erzeugen
Einmalig auf dem Admin-Rechner, PowerShell als Administrator:
$cert = New-SelfSignedCertificate `
-Subject "CN=RDP Signing" `
-Type CodeSigningCert `
-KeyUsage DigitalSignature `
-KeyExportPolicy Exportable `
-CertStoreLocation "Cert:\CurrentUser\My" `
-NotAfter (Get-Date).AddYears(10)
$cert.ThumbprintDen ausgegebenen Thumbprint notieren — er wird in den nächsten Schritten gebraucht.
Anschließend das Zertifikat in zwei Varianten exportieren:
# Mit privatem Schlüssel (.pfx) — zum Signieren aufbewahren
Export-PfxCertificate -Cert "Cert:\CurrentUser\My\$($cert.Thumbprint)" `
-FilePath "C:\Certs\rdp-signing.pfx" -Password (Read-Host -AsSecureString "PFX-Passwort")
# Ohne privaten Schlüssel (.cer) — für die Verteilung an Clients
Export-Certificate -Cert "Cert:\CurrentUser\My\$($cert.Thumbprint)" `
-FilePath "C:\Certs\rdp-signing.cer"Das .pfx kommt in den Passwort-Manager. Es ist der Signing-Key für alle Clients — wer es hat, kann beliebige .rdp-Dateien mit diesem Vertrauensanker signieren.
Schritt 2 — .rdp-Datei signieren
rdpsign.exe /sha256 <Thumbprint> "C:\Pfad\zur\verbindung.rdp"rdpsign.exe ist seit Windows 8 / Server 2012 im System enthalten. Die Datei wird in-place signiert — am Ende stehen zusätzliche Zeilen wie signature:s: und signscope:s: in der Datei.
Wichtig: Jede Änderung an der .rdp-Datei nach der Signierung macht die Signatur ungültig. Erst ändern, dann erneut signieren.
Für Connection-Broker-Umgebungen lässt sich das Signing zentral im Server Manager hinterlegen: Remote Desktop Services → Collections → Tasks → Edit Deployment Properties → Certificates → RD Connection Broker – Publishing. Dann werden alle per RemoteApp-Feed ausgelieferten Verbindungen automatisch signiert.
Schritt 3 — Clients das Zertifikat vertrauen lassen
Zwei Dinge müssen auf jedem Client passieren: Das .cer in den Trusted Publishers Store importieren und den Thumbprint als vertrauenswürdig registrieren.
Variante A — Per GPO (AD-Umgebung)
Zertifikat verteilen: Computerkonfiguration → Richtlinien → Windows-Einstellungen → Sicherheitseinstellungen → Richtlinien für öffentliche Schlüssel → Vertrauenswürdige Herausgeber → Import
Thumbprint eintragen: Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Remotedesktopdienste → Remotedesktopverbindungs-Client → SHA1-Fingerabdrücke von Zertifikaten angeben, die vertrauenswürdige RDP-Herausgeber darstellen
Zusätzlich im gleichen GPO-Ordner empfohlen: „Zulassen, dass RDP-Dateien von gültigen Herausgebern stammen” → Aktiviert
Variante B — Per PowerShell-Skript (ohne AD oder für einzelne Clients)
# Zertifikat in Trusted Publishers importieren
Import-Certificate -FilePath "C:\Certs\rdp-signing.cer" `
-CertStoreLocation "Cert:\LocalMachine\TrustedPublisher"
# Thumbprint in Registry eintragen
$thumbprint = "<Thumbprint>"
$regPath = "HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services"
if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force }
Set-ItemProperty -Path $regPath -Name "TrustedCertThumbprints" -Value $thumbprintNach Ausführung dieses Skripts erscheint der Dialog nicht mehr — die Verbindung öffnet direkt, Zwischenablage und Drucker funktionieren wieder ohne Rückfrage.
Das Skript lässt sich per RMM einmalig an den Client schicken oder als Startup-Script hinterlegen.
Wichtig für den Betrieb: Zertifikat und Thumbprint dokumentieren, Ablaufdatum im Kalender. Läuft das Signing-Zertifikat ab (hier: 10 Jahre), ist das .pfx wertlos, alle signierten .rdp-Dateien verlieren ihre Signatur und der Dialog erscheint überall wieder. Rechtzeitig — mindestens 4 Wochen vor Ablauf — neu ausstellen, alle Dateien neu signieren und das neue .cer ausrollen.
Pro Kunde ein eigenes Signing-Zertifikat — nicht mehrere Kunden mit demselben Zertifikat bedienen. Wer das .pfx eines Kunden hat, kann beliebige .rdp-Dateien signieren, die von allen Clients dieses Kunden als vertrauenswürdig akzeptiert werden. Mandantentrennung gilt hier genauso wie überall sonst.
Fazit
Die Warnung ist kein Fehler, sondern eine Sicherheitsprüfung, die Microsoft schrittweise verschärft. Die Lösung ist einmalig aufwändig — Zertifikat erstellen, signieren, auf Clients verteilen — danach vollständig transparent für alle Nutzer. Wer mehrere Kunden betreibt, profitiert von einem zentralen Signing-Zertifikat: ein Setup, einmal dokumentiert, für alle Installationen wiederverwendbar.



