RDS - Windows Server 2022 - Verständnisfrage zu Zertifikaten

[wznutzer 35]

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.

[NorbertFe 2.045]

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.

[cj_berlin 1.323]

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.

[wznutzer 35]

vor 7 Stunden schrieb wznutzer:

 

RDS - Verbindungsbroker - Veröffentlichung

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

Das ist nicht korrekt. Der Name auf dem Zertifikat scheint egal zu sein. Er muss vom Client noch nicht einmal aufgelöst werden können. Hauptsache dem Zertifikat wird vertraut.

[wznutzer 35]

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.

[wznutzer 35]

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

[NorbertFe 2.045]

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.

[wznutzer 35]

vor 36 Minuten schrieb NorbertFe:

Lustig, dass man nach Jahren noch über das Problem stolpert.

Es ist nie zu spät etwas nicht zu wissen .

[daabm 1.356]

vor 9 Stunden schrieb NorbertFe:

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

Korrekt. Sobald ein SAN gesetzt ist, wird der CN ignoriert. Der CN muß dann auch in den SANs auftauchen. RFC könnte ich raussuchen, hab aber grad keine Lust

[cj_berlin 1.323]

vor 1 Stunde schrieb daabm:

RFC könnte ich raussuchen, hab aber grad keine Lust

Ist aber oben schon verlinkt, daher musst Du noch nicht einmal schlechtes Gewissen haben