Trusten eines Serverzertifikates welches nicht per certlm getrustet ist

[Flobold 0]

Hallo Zusammen,

 

wir haben den Anwendungsfall, dass wir einen Jumpserver haben, der nur (Benutzer-)Zertifikate von CA1 trusten soll. Von dieser CA1 können wir aber leider keine Serverzertifikate bekommen.

Vom Jumpserver wird eine https-Verbindung mit einem Applikationsserver aufgebaut, dessen SSL-Zertifikat von CA2 stammt. Diese CA2 stellt auch unsere Benutzerzertifikate für sämtliche User bereit.

 

Der Zugriff auf den Jumpservern ist aber nur einem kleinen Userkreis vorbehalten, welche ein Benutzerzertifikat von CA1 auf einem Token haben.

 

Wir stehen hier momentan vor dem Problem, dass der Jumpserver das Zertifikat von CA2 (des Applikationsservers) nicht vertraut (logischerweise). Hat hier jemand eine Idee, wie (ob) man einen einzelnen Server trusten kann, auch wenn das SSL-Zertifikat von einer nicht vertrauten CA stammt? Wie schon erwähnt ist ein Serverzertifikat von CA1 nicht möglich. CA2 darf nicht getrusted sein, da sonst sämtliche (VPN-)Zertifikate aller User akzeptiert werden.

 

Selbstverständlich stehen wir hier hinter enormen Zeitdruch, die Umsetzung durchzuführen. Dementsprechend bin ich über sämtliche Hinweise dankbar.

 

Gruß

Florian 

bearbeitet 8. Dezember 2021 von Flobold

[cj_berlin 1.323]

Moin,

 

ich verstehe den Zusammenhang zwischen Server- und Benutzerzertifikaten zwar nicht ganz, aber es gibt einige Verfahren, wo das Vertrauen in ein Leaf-Zertifikat explizit erklärt werden kann: Code Signing und S/MIME zum Beispiel. TLS gehört allerdings nicht dazu, hier muss der Zertifikatskette vertraut werden.

 

Hast Du Bedenken, dass, wenn Du das Vertrauen in CA2 erklärst, sich User mit CA2-Zertifikaten werden am Jumphost anmelden können? Dafür gibt es Policies, die die Anmeldung regeln, unabhängig davon, ob sie per Smartcard oder per Username/Password erfolgt. Außerdem - sofern es wirklich um Smartcards geht, Du verrätst ja nicht soviel - ist das generelle Vertrauen in die Zertifikatskette nicht ausreichend, die Root CA muss im NTAuth-Store eingetragen sein.

[Flobold 0]

Hallo,

 

danke schonmal für die Antwort. 

 

Auf dem Jumpserver wird eine RDWeb-App gestartet (Ein IE, der eine HTTPS-Verbindung vom Jumpserver zum Applikationsserver aufbaut). Diese RD-App soll aber nur von Usern gestartet werden können, welche das Benutzerzertifikat von CA1 haben. Eine generelle Regelung via RDP-Rechten ist hier nicht ausreichen, da hier eine 2FA verlangt wird.

 

Eine Smartcardauthentifizierung ist in der Domäne bisher nicht vorgesehen, und wir würden gerne daran vorbei kommen, da sonst diverse Berechtigungskonzepte und Systemdokumentationen angepasst werden müssen.

 

-Edit-

 

der Zusammenhang Benutzer-/Server-Zertifikat ist, dass der Jumpserver die Root-CA1 im Zertifikatsspeicher vertraut, aber der Applikationsserver ein Serverzertifikat hat, welches von der Root-CA2 ausgestellt wurde.

Hier versuchen wir die Anmeldung (bzw. das starten der Remote-App) auf dem Jumpserver für die Personen zu verhindern, welche kein Zertifikat der CA1, aber eines der CA2 haben. 

 

bearbeitet 8. Dezember 2021 von Flobold
Ergänzung von Informationen

[cj_berlin 1.323]

Du verrätst immer noch nicht, warum es aus Deiner Sicht schlimm wäre, wenn der Jumphost der CA2 vertraut. Erkläre doch bitte, wie genau das User-Zertifikat in die Anmledung a. am Jumphost und b. am RDWeb involviert ist.

[Flobold 0]

Okay, wenn der Jumpserver das Zertifikat der Root-CA2 vertraut kann ein Anwender bei der Anmeldung ein Zertifikat auswählen, welches sich in seinem Profil in Form eines Benutzerzertifikates zur Anmeldung an dem VPN-Tunnel befindet. Da der Jumpserver der Zertifikatskette vertraut, akzeptiert er dieses Zertifikat. Dieses Zertifikat besitzen aber sämtliche Personen im Unternehmen, und umgeht somit die 2FA.

 

Ich hoffe, das klärt die Sache ein wenig auf.

[cj_berlin 1.323]

vor 2 Minuten schrieb Flobold:

Okay, wenn der Jumpserver das Zertifikat der Root-CA2 vertraut kann ein Anwender bei der Anmeldung

bei der Anmeldung woran? Bei der Windows-Anmeldung am Jumphost, Browser-Anmeldung am RDWeb, an Facebook? Auch wenn es schwer vorstellbar ist: Wir kennen Dein System nicht.

 

Wenn es um ein Zertifikat im Browser geht, kann der User, meine ich, ein beliebiges Zertifikat für die Authentifizierung auswählen, das sich samt Private Key in seinem privaten Store befindet und die EKU "Client Authentication" besitzt, egal, ob der Rechner, wo er gerade angemeldet ist, dem Aussteller vertraut oder nicht. Es ist am Webserver, nur bestimmte Aussteller oder gar nur bestimmte Zertifikate (User) zu akzeptieren.

[Flobold 0]

vor 3 Minuten schrieb cj_berlin:

Wenn es um ein Zertifikat im Browser geht, kann der User, meine ich, ein beliebiges Zertifikat für die Authentifizierung auswählen, das sich samt Private Key in seinem privaten Store befindet und die EKU "Client Authentication" besitzt, egal, ob der Rechner, wo er gerade angemeldet ist, dem Aussteller vertraut oder nicht. Es ist am Webserver, nur bestimmte Aussteller oder gar nur bestimmte Zertifikate (User) zu akzeptieren.

 

Korrekt. Die Anmeldung erfolgt am RDWeb (https://server.domäne/RDweb). Hier erscheint dann eine Zertifikatsabfrage, bei der der User sein Zertifikat auswählen kann. Da der Webserver (=Jumpserver in dem Fall) aber den Aussteller der Userzertifikaten vertraut, lässt er dann die Verbindung zu. Ich weiß leider nicht, wie ich konfigurieren kann, dass er nur Zertifikate akzeptiert, die von CA1 ausgestellt wurden, ohne die Root-Zertifikate von CA2 nicht mehr zu vertrauen. Wenn ich aber das mache, kann die HTTPS-Verbindung zum Applikationsserver nicht mehr aufgebaut werden, da dessen Serverzertifikat ebenfalls von der CA2 ausgestellt wurde.

[NilsK 2.939]

Moin,

 

auch wenn es nur sehr indirekt zur Lösung beiträgt: Ich glaube, dass so ein Fall nicht sinnvoll in einem Forum geklärt werden kann. Die Zusammenhänge sind zu komplex für das Medium, und je länger das hier gehen würde, um so mehr sicherheitskritische Details müsste man offenbaren.

 

Gruß, Nils

 

[cj_berlin 1.323]

OK, also ist der Jumphost ist ein RDS-Session Host, Connection Broker und RDWeb in einem? 

 

Im IIS, dort wo die zertifikatsbasierte Authentifizierung konfiguriert ist, kann man Regeln definieren, die auf alle möglichen Eigenschaften des Zertifikats abzielen, so auch auf den Issuer. Das geht aber IIRC nur mit "IIS Client Certificate Mapping", nicht mit "AD Client Certificate Mapping". Vermutlich ist es nichts, was Du unter Zeitdruck und ohne entsprechendes Know-How angehen solltest.

 

Kannst Du nicht einfach alle User, die in Frage kommen, in eine Gruppe packen und die Session Collection bzw. die Remote App auf diese Gruppe beschränken? Du kannst ja aus der CA1 die Liste der User exportieren, die ein Client-Zertifikat bekommen haben...

[Flobold 0]

Genau, das haben wir auch schon gemacht, aber es wird nunmal 2 FA vorgegeben.. Aber ich schaue mir das mal an, vielen Dank!