· 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.

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:

Sicherheitswarnung: Unbekannter Herausgeber

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.Thumbprint

Den 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 $thumbprint

Nach 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.

Zum Blog

Ähnliche Artikel

Alle Artikel »
Stalwart — selbstgehosteter Mail-Server in Rust

Stalwart — selbstgehosteter Mail-Server in Rust

Mailcow war mir zu schwer, Mailu zu eingeschränkt. Stalwart ist eine einzelne Binary in Rust, die SMTP, IMAP, JMAP, CalDAV und CardDAV gleichzeitig beherrscht — und dabei weniger RAM braucht als Mailcow allein für Redis.