13
RDP: Zertifikatswarnung nur bei Verbindung via IP-Adresse
Hallo zusammen,
ich habe derzeit ein kleines Problem mit Zertifikatswarnungen bei Verbindung mit RDP.
Vorab: Unsere Clients haben Windows 10, die Server laufen auf 2016. Ich befinde mich derzeit im LAN des Unternehmens. Bei einer VPN-Verbindung aus dem Home-Office sieht es anders aus als unten beschrieben (lasse ich erstmal außen vor).
Wir nutzen NLA ohne Downgrade-Möglichkeit.
Folgendes Problem:
Wenn ich mich von meinem Client aus mittels RDP zu einem Client oder Server verbinden möchte, erhalte ich Zertifikatswarnungen, wenn ich mich über die IP-Adresse verbinden will. Also wenn ich die IP-Adresse in das RDP-Fenster eintrage. Dies ist unabhängig davon, ob ich mich via RDP auf einen Client oder einen Server verbinden will. Die Zertifikatswarnungen unterscheiden sich hinsichtlich der Meldung ("Name des Servers im Zertifikat unterscheidet sich" oder "Zertifikat stammt nicht von einer vertrauenswürdigen Stelle").
Verbinde ich hingegen mit dem Hostnamen oder dem FQDN erhalte ich keine Zertifikatswarnung, weder bei Clients, noch bei Servern.
Ich habe so das Gefühl, dass im Hintergrund geschaut wird, ob 'Vom Nutzer eingegebenes RDP-Ziel = Name des Ziels im ausgestellten Zertifikat' geprüft wird.
Nach meinem Verständnis von digitalen Zertifikaten ist das unsinnig, da ein Zertifikat doch immer für ein bestimmtes Objekt ausgestellt wird und demnach für die korrespondierende IP und Hostnamen (also für das Objekt an sich) gelten sollte.
Der einzige Punkt der mir dazu einfallen würde ist, dass die Zuordnung IP <-> Hostname nicht immer statisch ist und so eine Eintragung der IP-Adresse im Zertifikat zu Problemen führen könnte.
ich habe derzeit ein kleines Problem mit Zertifikatswarnungen bei Verbindung mit RDP.
Vorab: Unsere Clients haben Windows 10, die Server laufen auf 2016. Ich befinde mich derzeit im LAN des Unternehmens. Bei einer VPN-Verbindung aus dem Home-Office sieht es anders aus als unten beschrieben (lasse ich erstmal außen vor).
Wir nutzen NLA ohne Downgrade-Möglichkeit.
Folgendes Problem:
Wenn ich mich von meinem Client aus mittels RDP zu einem Client oder Server verbinden möchte, erhalte ich Zertifikatswarnungen, wenn ich mich über die IP-Adresse verbinden will. Also wenn ich die IP-Adresse in das RDP-Fenster eintrage. Dies ist unabhängig davon, ob ich mich via RDP auf einen Client oder einen Server verbinden will. Die Zertifikatswarnungen unterscheiden sich hinsichtlich der Meldung ("Name des Servers im Zertifikat unterscheidet sich" oder "Zertifikat stammt nicht von einer vertrauenswürdigen Stelle").
Verbinde ich hingegen mit dem Hostnamen oder dem FQDN erhalte ich keine Zertifikatswarnung, weder bei Clients, noch bei Servern.
Ich habe so das Gefühl, dass im Hintergrund geschaut wird, ob 'Vom Nutzer eingegebenes RDP-Ziel = Name des Ziels im ausgestellten Zertifikat' geprüft wird.
Nach meinem Verständnis von digitalen Zertifikaten ist das unsinnig, da ein Zertifikat doch immer für ein bestimmtes Objekt ausgestellt wird und demnach für die korrespondierende IP und Hostnamen (also für das Objekt an sich) gelten sollte.
Der einzige Punkt der mir dazu einfallen würde ist, dass die Zuordnung IP <-> Hostname nicht immer statisch ist und so eine Eintragung der IP-Adresse im Zertifikat zu Problemen führen könnte.
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: 571077
Url: https://administrator.de/forum/rdp-zertifikatswarnung-nur-bei-verbindung-via-ip-adresse-571077.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
13 Kommentare
Neuester Kommentar
Moin,
wie du schon merkst, ist das Zertifikat wohl auf den Namen des Ziels ausgestellt. Daher solltest du die Verbindung über dieser herstellen.
Gruß
Spirit
wie du schon merkst, ist das Zertifikat wohl auf den Namen des Ziels ausgestellt. Daher solltest du die Verbindung über dieser herstellen.
Gruß
Spirit
1
Moin,
Zertifikate, egal ob für webseiten oder RDP, werden ausschliesslich auf Hostnamen ausgestellt.
Denn IP-Adresse ändern sich viel häufiger bei den meisten Geräten als der Hostname.
Stefan
Zertifikate, egal ob für webseiten oder RDP, werden ausschliesslich auf Hostnamen ausgestellt.
Denn IP-Adresse ändern sich viel häufiger bei den meisten Geräten als der Hostname.
Stefan
2
Würde man ein Zertifikat auf eine IP Adresse ausstellen und ein fremdes Gerät nimmt diese IP Adresse an, weisst du, was passiert.
1
Hi,
danke für eure Antworten.
Das mit der Ausstellung auf Hostnamen hab ich dann soweit verstanden, macht ja auch Sinn.
Bei mir war es aber so, dass ich aus dem Homeoffice via VPN ebenfalls Zertifikatswarnungen erhalten habe. Die genaue Meldung weiß ich gerade aber leider nicht. Und das obwohl ich mich mit dem Hostnamen (und nicht mittels IP) über das Login-Fenster angemeldet habe.
Dazu muss gesagt werden, dass sich die Home-Office-Leute durch die VPN-Verbindungen 'in einem anderen Netzwerk befinden' (ergibt sich durch einen Abgleich der IP-Adressen und Subnetmask).
Für euch stellt sich jetzt natürlich die Frage, warum ich nicht einfach den Hostnamen nutze wie normale Menschen. Es geht darum, dass es einen MitM-Angriff gibt, den ich teste und da muss die Zertifkatswarnung weggeklickt/akzeptiert werden. Aus dem Home-Office hat es mit dem Hostnamen funktioniert. Im LAN funktioniert es nicht und das ärgert mich, speziell beim Demonstrieren.
danke für eure Antworten.
Das mit der Ausstellung auf Hostnamen hab ich dann soweit verstanden, macht ja auch Sinn.
Bei mir war es aber so, dass ich aus dem Homeoffice via VPN ebenfalls Zertifikatswarnungen erhalten habe. Die genaue Meldung weiß ich gerade aber leider nicht. Und das obwohl ich mich mit dem Hostnamen (und nicht mittels IP) über das Login-Fenster angemeldet habe.
Dazu muss gesagt werden, dass sich die Home-Office-Leute durch die VPN-Verbindungen 'in einem anderen Netzwerk befinden' (ergibt sich durch einen Abgleich der IP-Adressen und Subnetmask).
Für euch stellt sich jetzt natürlich die Frage, warum ich nicht einfach den Hostnamen nutze wie normale Menschen. Es geht darum, dass es einen MitM-Angriff gibt, den ich teste und da muss die Zertifkatswarnung weggeklickt/akzeptiert werden. Aus dem Home-Office hat es mit dem Hostnamen funktioniert. Im LAN funktioniert es nicht und das ärgert mich, speziell beim Demonstrieren.
Moin,
Gruß,
Dani
Bei mir war es aber so, dass ich aus dem Homeoffice via VPN ebenfalls Zertifikatswarnungen erhalten habe.
eine Warnung wieder immer erscheinen, solange du a) diese nicht unterdrückst b) den Aussteller in die Liste der vertrauenwürdige Stammzertifizierungsstellen aufnimmst. Bitte mach dich mit Zertifikaten und deren Funktionalität vertraut.Gruß,
Dani
Keine Sorge. Mit Zertifikaten und deren Funktionalität bin ich vertraut.
Wie gesagt: Mit der selben Maschine erhalte ich aus dem Home-Office Warnmeldungen bei Verbindung über den Hostnamen. Und in der Zwischenzeit wurde
a) nichts unterdrückt
und
b) kein Aussteller in die Liste der vertrauenswürdigen Aussteller aufgenommen.
Ich vermute (ganz sicher bin ich nicht, daher frage ich ja hier), dass es irgendeine Einstellung in einer Windowsdomäne gibt, die Zertifikate automatisch als vertrauenswürdig kennzeichnet, wenn die Verbindung aus dem selben Subnet initiiert wird UND der Hostname zum Verbindungsaufbau genutzt wird. Dies ist insbesondere auch bei selbst signierten Zertifikaten der Fall, die explizit NICHT a) unterdrückt oder b) als vertrauenswürdiger Aussteller gekennzeichnet wurden.
Vielen Dank
Wie gesagt: Mit der selben Maschine erhalte ich aus dem Home-Office Warnmeldungen bei Verbindung über den Hostnamen. Und in der Zwischenzeit wurde
a) nichts unterdrückt
und
b) kein Aussteller in die Liste der vertrauenswürdigen Aussteller aufgenommen.
Ich vermute (ganz sicher bin ich nicht, daher frage ich ja hier), dass es irgendeine Einstellung in einer Windowsdomäne gibt, die Zertifikate automatisch als vertrauenswürdig kennzeichnet, wenn die Verbindung aus dem selben Subnet initiiert wird UND der Hostname zum Verbindungsaufbau genutzt wird. Dies ist insbesondere auch bei selbst signierten Zertifikaten der Fall, die explizit NICHT a) unterdrückt oder b) als vertrauenswürdiger Aussteller gekennzeichnet wurden.
Vielen Dank
Moin,
Gruß,
Dani
Wie gesagt: Mit der selben Maschine erhalte ich aus dem Home-Office Warnmeldungen bei Verbindung über den Hostnamen. Und in der Zwischenzeit wurde
Okay, das ist das Standardverwalten von Microft Windows.Ich vermute (ganz sicher bin ich nicht, daher frage ich ja hier), dass es irgendeine Einstellung in einer Windowsdomäne gibt, die Zertifikate automatisch als vertrauenswürdig kennzeichnet, wenn die Verbindung aus dem selben Subnet initiiert wird UND der Hostname zum Verbindungsaufbau genutzt wird. Dies ist insbesondere auch bei selbst signierten Zertifikaten der Fall, die explizit NICHT a) unterdrückt oder b) als vertrauenswürdiger Aussteller gekennzeichnet wurden.
Das kannst du einfach gegenprüfen. Exportiere das Zertifikat, welches für RDP genutzt wird, via MMC oder certutil.exe. in ein Verzeichnis/Desktop. Anschließend die Datei mit einem Doppelklick öffnen und einen Blick in den letzten Reiter werfen. Findest du in der Zertifikatsketten keine rotes X sind alle Quellen als vertrauenswürdig markiert und daher gibt es auch in einer Domäne keine Warnung. Somit befindet sich im vertauenswürdige Stammzertifizierungsstellen des Computers oder Benutzers.Gruß,
Dani
1Zitat von @Dani:
Danke für den Tipp.Ich vermute (ganz sicher bin ich nicht, daher frage ich ja hier), dass es irgendeine Einstellung in einer Windowsdomäne gibt, die Zertifikate automatisch als vertrauenswürdig kennzeichnet, wenn die Verbindung aus dem selben Subnet initiiert wird UND der Hostname zum Verbindungsaufbau genutzt wird. Dies ist insbesondere auch bei selbst signierten Zertifikaten der Fall, die explizit NICHT a) unterdrückt oder b) als vertrauenswürdiger Aussteller gekennzeichnet wurden.
Das kannst du einfach gegenprüfen. Exportiere das Zertifikat, welches für RDP genutzt wird, via MMC oder certutil.exe. in ein Verzeichnis/Desktop. Anschließend die Datei mit einem Doppelklick öffnen und einen Blick in den letzten Reiter werfen. Findest du in der Zertifikatsketten keine rotes X sind alle Quellen als vertrauenswürdig markiert und daher gibt es auch in einer Domäne keine Warnung. Somit befindet sich im vertauenswürdige Stammzertifizierungsstellen des Computers oder Benutzers.Ich habe das so ausgeführt. Wir nutzen ein Zertifikat für RDP, das von einer CA stammt, die wiederum von einer Root-CA zertifiziert wurde. In der Zertifikatskette sind keine roten X zu sehen. Für mich bedeutet das, dass jede Verbindung als sicher zertifiziert wird, sofern das Zertifikat des RDP-Hosts von dieser CA signiert wurde und man sich mit dem Hostnamen anmeldet.
Dass eine Zertifikatswarnung immer erscheint, wenn man sich aus dem Homeoffice anmeldet, nehme ich mal so hin...
Problem:
Leider besitzen wir auch Hosts, die ihre Zertifikate selbst signieren. Verbinde ich mich im selben Subnet via Hostname mit solch einem RDP-Host, erhalte ich auch hier keine Zertifikatswarnung, obwohl es selbst signiert wurde. Die Meldung wurde von mir nicht unterdrückt und auch nicht im Vorfeld als vertrauenswürdig gekennzeichnet. Auch hier denke ich, dass es irgendeine Einstellung in der Windowsdomäne geben muss, die selbst signierte Zertifikate als sicher kennzeichnet, wenn sie im selben Subnet liegen.... oder bei uns im Unternehmen ist wieder alles anders, als man es eigentlich tun sollte
Moin,
Eine Sicherheitswarnung dürfte beim Zugriff auf den Server mit Remotedesktop mit dem Parameter /admin dürfte keiner Sicherheitswarnung anzeigen. Erfolgt der Zugriff ohne Parameter wird weiterhin eine Sicherheitswarnung angezeigt. Das Verhalten kann mit Hilfe einer Gruppenrichtlinien und den den Fingerprints der eingesetzten Zertifikate geändert werden.
Mit Hilfe der Richtlinie wird das Zertifikat im Bezug auf RDP als vertrauenswürdig eingestuft. Ob das auch für Self Signed Zertifikat gilt, weiß ich nicht (mehr). Ich bin inzwischen selten in operativen Tätigkeiten involviert.
Gruß,
Dani
Ich habe das so ausgeführt. Wir nutzen ein Zertifikat für RDP, das von einer CA stammt, die wiederum von einer Root-CA zertifiziert wurde. In der Zertifikatskette sind keine roten X zu sehen. Für mich bedeutet das, dass jede Verbindung als sicher zertifiziert wird, sofern das Zertifikat des RDP-Hosts von dieser CA signiert wurde und man sich mit dem Hostnamen anmeldet.
Das ist die halbe Miete für eine korrekte Funktionalität.Eine Sicherheitswarnung dürfte beim Zugriff auf den Server mit Remotedesktop mit dem Parameter /admin dürfte keiner Sicherheitswarnung anzeigen. Erfolgt der Zugriff ohne Parameter wird weiterhin eine Sicherheitswarnung angezeigt. Das Verhalten kann mit Hilfe einer Gruppenrichtlinien und den den Fingerprints der eingesetzten Zertifikate geändert werden.
Mit Hilfe der Richtlinie wird das Zertifikat im Bezug auf RDP als vertrauenswürdig eingestuft. Ob das auch für Self Signed Zertifikat gilt, weiß ich nicht (mehr). Ich bin inzwischen selten in operativen Tätigkeiten involviert.
Leider besitzen wir auch Hosts, die ihre Zertifikate selbst signieren.
Auch hier einmal die Zertifikatskette wie oben beschrieben überprüfen.Gruß,
Dani
Guten Morgen
Leider besitzen wir auch Hosts, die ihre Zertifikate selbst signieren.
Auch hier einmal die Zertifikatskette wie oben beschrieben überprüfen.Hier existiert keine Kette. Es ist einfach nur das selbst signierte Zertifikat an oberste Stelle zu sehen. Allerdings mit einem roten X. Im ersten Reiter habe ich dann die Möglichkeit, dieses Zertifikat zu installieren. Also es als vertrauenswürdig zu kennzeichnen. Im MMC ist das Zertifikat ohne diese Installation nicht zu sehen.
Auch hier habe ich die Zertifikatswarnung nur erhalten, wenn ich mich via IP verbinde. Via Hostname passiert nichts, obwohl es selbst signiert ist.
Moin,
Hmmmmm ...
Ja, das hast Du in den GPOs eingetragen, dass die lokale CA bei allen als Stammzertifikat eingetragen wird. Damit sind alle Zertifikate, die von dieser CA ausgestellt werden, vertrauenswürdig.
Ich kenne das Phänomen. Es wäre nun interessant zu erfahren, welche Meldung das ist. Ich kenne die, dass die Sperrliste nicht zur Verfügung steht, wenn der Rechner nicht im Hause und damit auch nicht in der Domain ist. Das ist auch logisch. Während das Stammzertifikat fest hinterlegt wird, werden die Sperrlisten ständig aktualisiert. Das kann der Rechner aber nicht, wenn er nicht in der Domain ist.
Das ist allerdings seltsam. Sind die wirklich selbst signiert oder sind das Zertifikate, die von der CA automatisch angefragt werden?
Warum es mit IP nicht geht, wurde ja schon hinreichend erklärt.
Liebe Grüße
Erik
Hmmmmm ...
Ich vermute (ganz sicher bin ich nicht, daher frage ich ja hier), dass es irgendeine Einstellung in einer Windowsdomäne gibt, die Zertifikate automatisch als vertrauenswürdig kennzeichnet,
Ja, das hast Du in den GPOs eingetragen, dass die lokale CA bei allen als Stammzertifikat eingetragen wird. Damit sind alle Zertifikate, die von dieser CA ausgestellt werden, vertrauenswürdig.
wenn die Verbindung aus dem selben Subnet initiiert wird UND der Hostname zum Verbindungsaufbau genutzt wird.
Ich kenne das Phänomen. Es wäre nun interessant zu erfahren, welche Meldung das ist. Ich kenne die, dass die Sperrliste nicht zur Verfügung steht, wenn der Rechner nicht im Hause und damit auch nicht in der Domain ist. Das ist auch logisch. Während das Stammzertifikat fest hinterlegt wird, werden die Sperrlisten ständig aktualisiert. Das kann der Rechner aber nicht, wenn er nicht in der Domain ist.
Dies ist insbesondere auch bei selbst signierten Zertifikaten der Fall, die explizit NICHT a) unterdrückt oder b) als vertrauenswürdiger Aussteller gekennzeichnet wurden.
Das ist allerdings seltsam. Sind die wirklich selbst signiert oder sind das Zertifikate, die von der CA automatisch angefragt werden?
Warum es mit IP nicht geht, wurde ja schon hinreichend erklärt.
Liebe Grüße
Erik
Zeig doch mal das Zertifikat/die Zertifikats Kette und Pseudonymisiere den Namen für uns.
Ist das zufällig eine zweistufige CA?
Ist das zufällig eine zweistufige CA?
Hallo an alle
Vielen Dank für eure Hinweise.
Ich versuch das mal etwas zu strukturieren:
Selbes Subnet, Verbindungsaufbau mittels IP, Zertifikat von einer CA signiert:
Die Zertifikatswarnung macht hier Sinn, da der Name nicht übereinstimmt. Verbinde ich mich mittels Hostnamen, erhalte ich keine Warnung (soweit logisch).
Selbes Subnet, Verbindungsaufbau mittels IP, Zertifikat selbst signiert:
Ich hoffe man erkennt es soweit, dass es selbst signiert ist. Obwohl ich mich via IP verbinde, erhalte ich nicht die Meldung, dass der Name auf dem Zertifikat anders ist, sondern dass es nicht vertrauenswürdig ist. Verbinde ich mich über den Hostnamen erhalte ich keine Zertifikatswarnung (obwohl das Zertifikat ja immer noch nicht vertrauenswürdig ist)
Vielen Dank für eure Hinweise.
Ich versuch das mal etwas zu strukturieren:
Selbes Subnet, Verbindungsaufbau mittels IP, Zertifikat von einer CA signiert:
Die Zertifikatswarnung macht hier Sinn, da der Name nicht übereinstimmt. Verbinde ich mich mittels Hostnamen, erhalte ich keine Warnung (soweit logisch).
Selbes Subnet, Verbindungsaufbau mittels IP, Zertifikat selbst signiert:
Ich hoffe man erkennt es soweit, dass es selbst signiert ist. Obwohl ich mich via IP verbinde, erhalte ich nicht die Meldung, dass der Name auf dem Zertifikat anders ist, sondern dass es nicht vertrauenswürdig ist. Verbinde ich mich über den Hostnamen erhalte ich keine Zertifikatswarnung (obwohl das Zertifikat ja immer noch nicht vertrauenswürdig ist)
