Jump to content

RDS - Windows Server 2022 - Verständnisfrage zu Zertifikaten


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Guten Morgen,

 

evtl. kann mir jemand hierzu etwas erklären, kommentieren, bestätigen oder auf einen Irrtum hinweisen. Die Angaben wann was notwendig ist, gehen in diversen Youtube-Videos und Tutorials auseinander. Entschuldigt die Länge.

 

Allgemein

Ab dem Zeitpunkt des Domain-Join hat der Client die lokale Zertifizierungsstelle als vertrauenswürdige Stammzertifizierungsstellt im Zertifikatsspeicher.

 

Zertifikat jedes Windows PC mit aktiviertem RDP

Mal noch ohne RDS gedacht. Jeder PC hat für RDP ein selbsigniertes Zertifikat (egal ob domain-joined oder nicht). Mit diesem Zertifikat weist sich dieser PC bei einer RDP-Anmeldung aus.

certlm -> Remotedesktop -> Zertifikate (Keine Zertifikatskette, eben selbst signiert)

1)

Greife ich von einem domain-joined PC auf einen anderen (ebenfalls domain joined) per RDP zu, erscheint keine Zertifikatswarnung? Warum? Es handelt sich doch um ein selbsigniertes Zertifikat, ohne Bezug zur lokalen CA?

2)

Greife ich von einem nicht domain-joined PC zu ==> Zertifikatswarnung. Klar, das Zertifikat ist unbekannt

 

Warum kommt keine Warnung per RDP von einem domain-joined PC auf einen anderen, obwohl das Zertifikat keine Kette zur lokalen CA aufweist?

 

RDS-Zertifikate

 

RDS - Verbindungsbroker SSO (einmaliges Anmelden)

Wird benötigt um z. B. von einem PC an dem ich bereits angemeldet bin, beim Zugriff auf RDS nicht noch einmal die Anmeldedaten eingeben zu müssen.

Lautet auf den internen Namen des PC mit der Rolle des Verbindungsbrokers.

Nicht unbedingt notwendig, wenn kein SSO konfiguriert.

 

RDS - Verbindungsbroker - Veröffentlichung

Wird zur Signierung der RDP-Dateien verwendet die man im Portal über Web Access herunterladen kann.

Lautet auf den internen Namen des PC mit der Rolle des Verbindungsbrokers.

Wenn ich die RDP-Dateien auch außerhalb der Domäne nutzen will, brauche ich für den Verbindungsbroker ein öffentliches Zertifikat.

Nicht unbedingt notwendig, dann erscheinen halt Warnungen wenn die RDP-Datei ausgeführt wird.

 

RDS - Web Access

Wird für die Webseite des IIS für das Web Access Portal verwendet.

Lautet auf den internen Namen des PC mit der Web Access Rolle.

Im Falle einer Veröffentlichung sollte auch ein öffentliches Zertifikat verwendet werden.

 

RD-Gateway

Das Gateway ist die einzige Rolle die auf jeden Fall ein öffentliches Zertifikat benötigt.

 

Öffentliche vs. interne Zertifikate

Während das Gateway die einzige Rolle ist die ohne öffentliches Zertifikat nicht funktioniert, kann bei allen anderen eine Warnung weggeklickt werden.

Man könnte aber auch für alles öffentliche Zertifikate nutzen, auch für den standalone PC mit offenem PC-Port. Dazu richtet man im DNS eine eigene Zone ein, damit die externen Namen auch intern aufgelöst werden können.

Man könnte für alles auch ein SAN oder Wildcard Zertifikat verwenden.

 

Habe ich das richtig verstanden?

 

Danke und Grüße

 

vor 35 Minuten schrieb wznutzer:

Warum kommt keine Warnung per RDP von einem domain-joined PC auf einen anderen, obwohl das Zertifikat keine Kette zur lokalen CA aufweist?

Kann es sein, dass sich die PCs dann per Kerberos untereinander authentifizieren? Nur wenn das nicht geht müsste dann TLS (und somit Zertifikate) verwendet werden.

Link zu diesem Kommentar
vor 51 Minuten schrieb wznutzer:

Greife ich von einem domain-joined PC auf einen anderen (ebenfalls domain joined) per RDP zu, erscheint keine Zertifikatswarnung? Warum? Es handelt sich doch um ein selbsigniertes Zertifikat, ohne Bezug zur lokalen CA?

Weil dann vermutlich Kerberossecurity ausgehandelt wird. Schau halt mal nach.

vor einer Stunde schrieb wznutzer:

Jeder PC hat für RDP ein selbsigniertes Zertifikat (egal ob domain-joined oder nicht).

Wenn er domain-joined ist, könnte man ihm ja ein korrektes Zertifikat verpassen, welches für RDP Zwecke geeignet ist. Wäre dann sauber.

Link zu diesem Kommentar
vor 3 Stunden schrieb wznutzer:
 

RD-Gateway

Das Gateway ist die einzige Rolle die auf jeden Fall ein öffentliches Zertifikat benötigt.

Das ist natürlich unzutreffend. Wenn einem privaten Root-Zertifikat am Endpoint vertraut wird und der Endpoint die Möglichkeit hat, das Zertifikat und die Kette zu validieren, ist eine private PKI genauso gut oder schlecht wie eine öffentliche.

Link zu diesem Kommentar
vor 4 Stunden schrieb cj_berlin:

Das ist natürlich unzutreffend. Wenn einem privaten Root-Zertifikat am Endpoint vertraut wird und der Endpoint die Möglichkeit hat, das Zertifikat und die Kette zu validieren, ist eine private PKI genauso gut oder schlecht wie eine öffentliche.

Das ist selbstverständlich richtig, auch wenn es wahrscheinlich nicht best practice ist. Da sind mir fremde Clients im Sinn.

Link zu diesem Kommentar
  • 2 Wochen später...

Die meisten hier werden es ohnehin wissen, aber evtl. nicht alle die auf diesen Thread stoßen. Deswegen folgender Hinweis:

 

Wenn bei einer RDP-Bereitstellung Zertifikate einer eigenen Zertifizierungsstelle verwendet werden muss auf die Einhaltung von RFC2818 geachtet werden. Das Zertifikat wird sonst "nur" noch vom Internet-Explorer akzeptiert (lt. meinen Tests jedenfalls).

 

Fehler: ERR_CERT_COMMON_NAME_INVALID

 

Die RFC fordert, dass die Identität nicht mehr durch den CN festgestellt wird, sondern durch einen oder mehrere DNS-Einträge im SAN.

 

https://tools.ietf.org/html/rfc2818

 

Das HTML5-Control funktioniert mit einem so ausgestellten Zertifikat auch nicht.

 

Grüße

Link zu diesem Kommentar
vor 5 Minuten schrieb wznutzer:

Wenn bei einer RDP-Bereitstellung Zertifikate einer eigenen Zertifizierungsstelle verwendet werden muss auf die Einhaltung von RFC2818 geachtet werden.

Naja eigentlich auch bei einer fremden CA, nur übernimmt die das inzwischen automatisch in allen mir bekannten Fällen. Lustig, dass man nach Jahren noch über das Problem stolpert. ;)

Ich meine, dass auch der CN irgendwie noch im SAN auftauchen muss.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...