Gelöst: RemoteApp zeigt "Unbekannter Herausgeber" trotz korrekt konfiguriertem Zertifikat

Problem:

Nach einem Windows-Patchday erscheinen beim Start von RemoteApp-Verbindungen über einen RD-Gateway plötzlich zwei neue Sicherheitswarnungen: "Unbekannte Remoteverbindung" und "Unbekannter Herausgeber". Ursache ist meist, dass die RDP-Dateien nicht mehr mit einem vertrauenswürdigen Zertifikat signiert werden – etwa weil ein Zertifikat abgelaufen ist oder ein neues Zertifikat ausgestellt wurde.

Der naheliegende Fix ist schnell gemacht: Neues Zertifikat über die interne Zertifizierungsstelle (CA) beantragen, als PFX exportieren und im Server-Manager unter Remotedesktopdienste → Bereitstellungseigenschaften → Zertifikate hinterlegen. Doch der Server-Manager zeigt hartnäckig weiterhin "Nicht konfiguriert" an – egal wie oft das PFX neu eingespielt wird.

Lösung:

Der Server-Manager gibt bei diesem Fehler keine aussagekräftige Meldung aus. Zielführender ist die Diagnose per PowerShell:

Zeigt die Ausgabe einen Thumbprint, aber leere Felder bei Subject, IssuedTo und ExpiresOn, liegt das Problem im Zertifikat selbst – nicht in der RDS-Konfiguration. Prüfen lässt sich das direkt im Zertifikatsspeicher:

powershell
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -eq "HIER_THUMBPRINT"} | Format-List Subject, Issuer, HasPrivateKey

Ist auch hier das Subject-Feld leer, wurde das Zertifikat bei der Beantragung ohne gültigen Antragstellernamen (Common Name) erstellt – meist, weil bei der manuellen Zertifikatsanforderung im Zertifikatsspeicher (certlm.msc) nur der Alternative Antragstellername (SAN) ausgefüllt wurde, nicht aber der eigentliche Reiter "Antragsteller" mit Typ "Allgemeiner Name".

So wird es richtig gemacht:

1. In certlm.msc ein neues Zertifikat über die passende Vorlage anfordern

2. Im Dialog "Es werden zusätzliche Informationen benötigt" den Reiter Antragsteller öffnen

3. Zuerst Typ Allgemeiner Name mit dem vollständigen Servernamen eintragen und über "Hinzufügen" bestätigen

4. Erst danach im selben Reiter auf Typ DNS wechseln und die benötigten Alternativnamen (SAN) ergänzen

5. Zertifikat registrieren, per PowerShell auf korrektes Subject-Feld prüfen, dann als PFX mit privatem Schlüssel exportieren

6. Zertifikat den RDS-Rollendiensten per PowerShell zuweisen:

Danach den SHA1-Thumbprint in der zugehörigen Gruppenrichtlinie (Pfad: Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Remotedesktopdienste → Remotedesktopclient) aktualisieren und das CA-Root-Zertifikat unter Richtlinien öffentlicher Schlüssel als vertrauenswürdig hinterlegen.

Fazit:

• Der Server-Manager meldet keinen Fehler, wenn ein Zertifikat ohne gültiges Subject-Feld importiert wird – er bleibt einfach stumm bei "Nicht konfiguriert"

• Diagnose per PowerShell (Get-RDCertificate, Get-PfxData) ist deutlich aussagekräftiger als die grafische Oberfläche

• Beim manuellen Beantragen eines Zertifikats mit SAN unbedingt auch den Common Name im Reiter "Antragsteller" setzen – sonst fehlt dem Zertifikat ein gültiger Antragstellername

• Zuweisung der Zertifikate an alle vier RDS-Rollendienste funktioniert zuverlässiger per PowerShell (Set-RDCertificate) als über den Server-Manager-Dialog

Quellen s. weiter unten

 Stand: 07/2026

Diese Tipps dienen als knowledgebase zur internen Nutzung. Es steht natürlich jedem frei, dieses Wissen auf eigene Gefahr anzuwenden. Wir empfehlen, den Rat Ihres Netzwerk-Administrators einzuholen, oder uns mit der Lösung Ihres Problems zu beauftragen. Verwendete Markennamen und Warenzeichen sind Namen/Eigentum der jeweiligen Firmen/Hersteller.

Über ein paar liebe Worte und ⭐️⭐️⭐️⭐️⭐️ in unserer Google-Bewertung freuen wir uns, wenn Dir dieser Beitrag gefällt und vielleicht sogar weiterhilft. Einfach hier klicken.