7
Remote Desktop Server liefert falsches Zertifikat aus
Hallo,
ich hab ein kleines Problem mit unserem Remote Desktop Server. Es handelt sich um einen Server 2012 R2 mit komplett installierten RDS und einigen freigegebenen Remote Apps.
Wir haben bei uns eine sehr heterogene Umgebung mit vielen Mac's und Windows Maschinen. Ich habe nun vergangene Woche ein Wildcard-Zertifikat für eine Stange Geld gekauft und auf dem Server eingerichtet.
Über den den Remotedesktopgateway-Manager habe ich in den Eigenschaften des Servers --> SSL-Zertifikat --> "Vorhandenes Zertifikat Remotedesktopgateway auswählen..." entsprechend eingerichtet und nun steht oben auch das korrekte Zertifkat mit der richtigen Laufzeit.
Komischer Weiße hatte das ganze letzte Woche - bevor ich den Server neugsetartet hatte - auch gut funktioniert.
Wenn ich mich auf einem Mac mit der Remote Desktop App an den Remote Ressources verbinde verschwand die Warnung zum ungültigen (selbstsignierten) Zertifikat - sofern die hinterlegte URL zum Zertifikat passt.
Zum Zertifikat:
- WIldcard Zertifikat unserer Web-Domain
- 3 Jahre Laufzeit
- Unternehmensvalidiert
Ich hab im DNS entsprechend einen Eintrag gemacht, sodass RDSERVER.dom.local sowie remote.domain.com auf den gleichen Server zeigen.
Jetzt wurde der Server am Wochenende neugestartet und seid dem liefert der Server plötzlich einfach ein neues - selbstsigniertes - Zertifkat aus, das eben auf RDSERVER.dom.local lautet und 6 Monate gültig ist... Wenn ich dieses Zertifikat im Speicher suche und lösche wird anschließend wieder ein Zertifikat erstellt mit neuer Laufzeit.
Ich bin etwas ratlos, vorallem weil es ja schon funktioniert hatte und ich nicht mehr weiß wo ich was konfigurieren kann. Die Befragung der großen Suchmaschine brachte bisher auch nichts verwertbares.
Evtl weiß ja jemand Rat.
Wer mehr Infos braucht, einfach raus damit!
Gruß
Christian
ich hab ein kleines Problem mit unserem Remote Desktop Server. Es handelt sich um einen Server 2012 R2 mit komplett installierten RDS und einigen freigegebenen Remote Apps.
Wir haben bei uns eine sehr heterogene Umgebung mit vielen Mac's und Windows Maschinen. Ich habe nun vergangene Woche ein Wildcard-Zertifikat für eine Stange Geld gekauft und auf dem Server eingerichtet.
Über den den Remotedesktopgateway-Manager habe ich in den Eigenschaften des Servers --> SSL-Zertifikat --> "Vorhandenes Zertifikat Remotedesktopgateway auswählen..." entsprechend eingerichtet und nun steht oben auch das korrekte Zertifkat mit der richtigen Laufzeit.
Komischer Weiße hatte das ganze letzte Woche - bevor ich den Server neugsetartet hatte - auch gut funktioniert.
Wenn ich mich auf einem Mac mit der Remote Desktop App an den Remote Ressources verbinde verschwand die Warnung zum ungültigen (selbstsignierten) Zertifikat - sofern die hinterlegte URL zum Zertifikat passt.
Zum Zertifikat:
- WIldcard Zertifikat unserer Web-Domain
- 3 Jahre Laufzeit
- Unternehmensvalidiert
Ich hab im DNS entsprechend einen Eintrag gemacht, sodass RDSERVER.dom.local sowie remote.domain.com auf den gleichen Server zeigen.
Jetzt wurde der Server am Wochenende neugestartet und seid dem liefert der Server plötzlich einfach ein neues - selbstsigniertes - Zertifkat aus, das eben auf RDSERVER.dom.local lautet und 6 Monate gültig ist... Wenn ich dieses Zertifikat im Speicher suche und lösche wird anschließend wieder ein Zertifikat erstellt mit neuer Laufzeit.
Ich bin etwas ratlos, vorallem weil es ja schon funktioniert hatte und ich nicht mehr weiß wo ich was konfigurieren kann. Die Befragung der großen Suchmaschine brachte bisher auch nichts verwertbares.
Evtl weiß ja jemand Rat.
Wer mehr Infos braucht, einfach raus damit!
Gruß
Christian
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 293788
Url: https://administrator.de/forum/remote-desktop-server-liefert-falsches-zertifikat-aus-293788.html
Ausgedruckt am: 23.12.2024 um 03:12 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
was passiert, wenn du das Cert dann wieder im Assistent zufütterst?
Wir verwenden für RDS selbstsignierte Certs, aber das sollte keinen Unterschied machen...
Gruss,
tomolpi
was passiert, wenn du das Cert dann wieder im Assistent zufütterst?
Wir verwenden für RDS selbstsignierte Certs, aber das sollte keinen Unterschied machen...
Gruss,
tomolpi
Also ich hab das Problem noch etwas weiter eingrenzen Können...
Der Server liefert scheinbar das korrekte Zertifikat aus, wenn er sich mit den Remote-Ressource verbindet, die Ihm die Liste der freigegebenen Programme bereitstellt. Heißt, dass an der Stelle dann auch keine Zertifikats-Warnung mehr kommt sofern der Server korrekt eingegeben ist. Wenn man es bewusst "falsch" macht warnt er vor dem quasi richtigen Zertifikat.
Wenn ich mich aber nun mit einer App konkret verbinden will - einem Freigegebenen Editor oder what ever - dann bekomm ich wieder eine Warnung mit dem Selbstsignierten Zertifikat.
Das hat mich darauf gebracht mal in den "Bereitstellungseigenschaften" der Sammlungen zu schauen. Hier gibts auch nen Punkt Zertifikate. Hier hab ich dann nochmal die Zertifikate hinzugefügt und nun steht hier "Die aktuelle Zertifikatstufe der Bereitstellung ist Vertrauenswürdig".
Allerdings liefert er weiterhin das falsche Zertifikat wenn ich mich mit einem RemoteApp-Programm verbinden will.
Mir ist da noch aufgefallen, dass bei den Bereitstellungseigenschaften unter "Web Access für Remotedesktop" eigentlich noch die falsche Domain steht... Also die Domänen-Lokale URL des Servers... Hat jemand ne Ahnung wie/ob ich das ändern kann? Das ist wahrscheinlich so eingetragen worden wie ich den Dienst konfiguriert hab...
Gruß
Christian
Der Server liefert scheinbar das korrekte Zertifikat aus, wenn er sich mit den Remote-Ressource verbindet, die Ihm die Liste der freigegebenen Programme bereitstellt. Heißt, dass an der Stelle dann auch keine Zertifikats-Warnung mehr kommt sofern der Server korrekt eingegeben ist. Wenn man es bewusst "falsch" macht warnt er vor dem quasi richtigen Zertifikat.
Wenn ich mich aber nun mit einer App konkret verbinden will - einem Freigegebenen Editor oder what ever - dann bekomm ich wieder eine Warnung mit dem Selbstsignierten Zertifikat.
Das hat mich darauf gebracht mal in den "Bereitstellungseigenschaften" der Sammlungen zu schauen. Hier gibts auch nen Punkt Zertifikate. Hier hab ich dann nochmal die Zertifikate hinzugefügt und nun steht hier "Die aktuelle Zertifikatstufe der Bereitstellung ist Vertrauenswürdig".
Allerdings liefert er weiterhin das falsche Zertifikat wenn ich mich mit einem RemoteApp-Programm verbinden will.
Mir ist da noch aufgefallen, dass bei den Bereitstellungseigenschaften unter "Web Access für Remotedesktop" eigentlich noch die falsche Domain steht... Also die Domänen-Lokale URL des Servers... Hat jemand ne Ahnung wie/ob ich das ändern kann? Das ist wahrscheinlich so eingetragen worden wie ich den Dienst konfiguriert hab...
Gruß
Christian
Hallo Christian,
genau das meine ich, du musst dein Cert über diese Seite im Servermanager einfüttern.
Dann sollte es klappen.
Wie genau meinst du das mit der URL?
genau das meine ich, du musst dein Cert über diese Seite im Servermanager einfüttern.
Dann sollte es klappen.
Wie genau meinst du das mit der URL?
Hi tomolpi,
also mit URL mein ich das, was unter Web Access für Remote Desktop steht (im Assistent Bereitstellungseigenschaften):
Hier steht eben diese Lokale Domain. Das hab ich sicher bei der Einrichtung des Dienstes so eingegeben.
Ich hab noch ein wenig Recherchiert zu dem Thema, aber nichts befriedigendes finden können...
Wenn ich im IIS die web.config XML anpasse (C:\Windows\Web\RDWeb\Web.config) und dort die zwei Punkte wo REMOTE.XXX.int mit remote.XXX.de ersetze dann laden die Remote-Apps nicht mehr...
Ich habe in der Registry unter noch die ganzen freigegebenen Remote-Apps gefunden. Hier wird in der Registry scheinbar eine komplette RDP-Datei zu jeder Remote-App abgespeichert. Die Zeichenfolge RDPFileContents enthält jedenfalls augenscheinlich den gleichen Inhalt wie eine klassische *.rdp-Datei. Hier ist auch überall das REMOTE.xxx.int hinterlegt.
Ich vermute das Problem genau hier. Bearbeiten ist nur nicht so einfach, da der Registry-Editor nicht mit dem Mehrzeiligen Content umgehen kann. Ich kann es rauskopieren, in einen Editor packen. Alles gut soweit. Nur das zurück kopieren klappt nicht! Inline Editieren ist auch schwierig, mangels inline Suche...
Ich vermute mittlerweile, dass es am besten wäre die Rolle nochmal neu zu installieren
also mit URL mein ich das, was unter Web Access für Remote Desktop steht (im Assistent Bereitstellungseigenschaften):
Hier steht eben diese Lokale Domain. Das hab ich sicher bei der Einrichtung des Dienstes so eingegeben.
Ich hab noch ein wenig Recherchiert zu dem Thema, aber nichts befriedigendes finden können...
Wenn ich im IIS die web.config XML anpasse (C:\Windows\Web\RDWeb\Web.config) und dort die zwei Punkte wo REMOTE.XXX.int mit remote.XXX.de ersetze dann laden die Remote-Apps nicht mehr...
Ich habe in der Registry unter
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\QuickSessionCollection\ApplicationsIch vermute das Problem genau hier. Bearbeiten ist nur nicht so einfach, da der Registry-Editor nicht mit dem Mehrzeiligen Content umgehen kann. Ich kann es rauskopieren, in einen Editor packen. Alles gut soweit. Nur das zurück kopieren klappt nicht! Inline Editieren ist auch schwierig, mangels inline Suche...
Ich vermute mittlerweile, dass es am besten wäre die Rolle nochmal neu zu installieren
Sodallas,
nach dem ich quasi schon fast aufgegeben hatte nach einer Lösung zu suchen.
Nach dem ich aber mit dem Server in den letzten 2 Wochen noch massive andere Probleme hatte (VM bleibt alle 5 min für 10 sek. stehen!) habe ich hier noch ziemlich rumgedoktert und bin beim Suchen heut über die quasi Lösung gestolpert:
Suche: https://www.google.de/search?q=remote+desktop+%222012+R2%22+webaccess+fu ...
Das erste Ergebnis führte mich in die Technet Gallery zum Powershell Script https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
Zuerst musste ich noch unsignierte Scripte erlauben mit Hilfe von:
und anschließend das Script starten:
Anschließend lief mein Remote Desktop auf dem Mac ohne Zertifikats-Fehler!! :D Yea
Ich hatte zwar noch das Problem - dadurch dass ich die Dienste vorher erst komplett entfernt und neu eingerichtet hatte - dass meine Remote-Apps Doppelt angezeigt wurden, aber da erinnerte ich mich an meinen gefundenen Registry-Pfad der Remote-Apps...
Bei der neuen Einrichtung hatte ich meine Session-Sammlung wohl geringfügig anders benannt. So entstand ein zweiter Baum unterhalb von "PublishedFarms"... Ich hab den alten Baum "QuickSessionCollection" einfach gelöscht (und vorher sicherheitshalber exportiert)...
Dann war auch dieses Problem gelöst.
Fazit: Läuft...
Hoffe dass mein Fund anderen RDP-Laien weiterhilft und evtl schneller ans Zeit führt...
nach dem ich quasi schon fast aufgegeben hatte nach einer Lösung zu suchen.
Nach dem ich aber mit dem Server in den letzten 2 Wochen noch massive andere Probleme hatte (VM bleibt alle 5 min für 10 sek. stehen!) habe ich hier noch ziemlich rumgedoktert und bin beim Suchen heut über die quasi Lösung gestolpert:
Suche: https://www.google.de/search?q=remote+desktop+%222012+R2%22+webaccess+fu ...
Das erste Ergebnis führte mich in die Technet Gallery zum Powershell Script https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
Zuerst musste ich noch unsignierte Scripte erlauben mit Hilfe von:
Set-ExecutionPolicy UnrestrictedSet-RDPublishedName remote.domain.comAnschließend lief mein Remote Desktop auf dem Mac ohne Zertifikats-Fehler!! :D Yea
Ich hatte zwar noch das Problem - dadurch dass ich die Dienste vorher erst komplett entfernt und neu eingerichtet hatte - dass meine Remote-Apps Doppelt angezeigt wurden, aber da erinnerte ich mich an meinen gefundenen Registry-Pfad der Remote-Apps...
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\QuickSessionCollection\Dann war auch dieses Problem gelöst.
Fazit: Läuft...
Hoffe dass mein Fund anderen RDP-Laien weiterhilft und evtl schneller ans Zeit führt...
Zitat von @ChrisNbg:
Hoffe dass mein Fund anderen RDP-Laien weiterhilft und evtl schneller ans Zeit führt...
Hoffe dass mein Fund anderen RDP-Laien weiterhilft und evtl schneller ans Zeit führt...
Eigentlich sollte dann bei denen sowas garnicht nötig sein, der RDS Server funktioniert eigentlich
Naja, ich sag mal so: solange man ein selbstsigniertes Zertifikat verwendet, das man per AD verteilt und vertrauenswürdig macht ist das ja kein Problem. Wenn aber dann Rechner im Spiel sind die nicht teil des AD sind...
