TRestClient mit SSL-P12-Zertifikat, wie funktioniert das?

**gmc616**

Hallo DP.

Ich möchte einen REST-Client schreiben, der eine SSL-Verbindung zu einem REST-Server aufbauen soll.
Für die SSL-Verbindung wird mir pro Benutzer ein P12-Zertifikat(??) und ein Passwort bereit gestellt.

Ich habe im Umgang mit Zertifikaten keinerlei Erfahrung.
Das Zertifikat soll zur Laufzeit geladen werden, nicht aus dem Windows-Zertifikatsspeicher.

Funktioniert sowas mit Delphi-Rio-Boardmitteln? Oder brauche ich Fremd-Komponenten?
Wie muß ich vorgehen?

Evtl. hat jemand ein Beispiel für mich?

Danke.

**jaenicke**

Zitat von gmc616:

Das Zertifikat soll zur Laufzeit geladen werden, nicht aus dem Windows-Zertifikatsspeicher.

Funktioniert sowas mit Delphi-Rio-Boardmitteln?

Leider gab es da einen Bug, der erst mit Delphi 11 behoben ist. Hier findest du meinen entsprechenden (gelösten) Bugreport:

https://quality.embarcadero.com/brow...4451?filter=-2
Der Bug bezieht sich zwar auf THTTPRIO, aber das gilt genauso für TRestClient.

Bei Delphi 10.3 kannst du, um Zertifikate zur Clientauthentifikation aus dem Speicher oder Dateien zu nutzen, nur andere Komponenten verwenden oder mit Hooks und Pointerspielerei auf die intern dafür vorhandene Funktionalität zugreifen (die vor Delphi 11 zwar vorhanden aber nicht nutzbar war). Ich habe das mit Hook usw. gelöst.

**himitsu**

Wir hatten es letztendlich manuell gemacht. (wir haben auch nur eine Hand vol API/Methoden, welche wir ansprechen)
Indy/TIdHTTP mit der kranken JSON-Komponente vom Delphi, zum Ansprechen des REST-Servers,
und OpenSSL für die Behandlung des Zertifikats beim Login-Prozess. (das aktuelle Zettifikat wird runtergeladen und zur Berechnung des Key benutzt, für die weitere Kommunikation)

https://code.google.com/archive/p/openssl-delphi/

Für XE + 10.4 (bzw. nun auch noch so im 11.2)

Jupp, war nicht zugreifbar und Kollege hatte dann eine andere Komponente gesucht, wo es ohne Krämpfe ging.
Außerdem XE und TRestClient

**jaenicke**

Zitat von himitsu:

Jupp, war nicht zugreifbar und Kollege hatte dann eine andere Komponente gesucht, wo es ohne Krämpfe ging.

Einen entsprechenden Bugeintrag hatte ich allerdings nicht gefunden. Und meiner wurde ja nach etwa einem Jahr dann gelöst, was ich für einen solchen Bug (vorgesehene spezielle Funktionalität funktionierte noch nie) auch für völlig akzeptabel halte. Nur muss es halt auch jemand melden.

**himitsu**

Da wir das Problem vorrangig in XE lösen mußten und Emba da sowieso nix mehr macht, hatten wir keine Lust dazu sinlos was zu melden.
(bin grade dabei D11 endlich mal zum laufen zu bekommen, damit wir endlich produktiv umstellen können, aber da knallt noch genug Anderes)

**gmc616**

Hmm ... Sorry, aber jetzt bin ich genau so schlau wie vorher.
Die Aussage "Leider gab es da einen Bug, der erst mit Delphi 11 behoben ist." hat nicht unbedingt eine motivationsfördende Wirkung.

Nun gut. Natürlich hab ich ne Reihe rumgegoogelt.
Unter anderem hab ich Dinge gefunden über TIdHTTP, dort kann man mittels IdSSLIOHandlerSocketOpenSSL-Handler ein Zertifikat laden.
Nach einem Blick in den Source ist es offenbar auch möglich, P12 bzw. PFX Zertifikate zu laden.
Das hab ich getan und nach der Angebe des korrekten Passworts in IdSSLIOHandlerSocketOpenSSL1GetPassword, gab es auch keine Fehler mehr.

Es sieht ganz danach aus, als ob man so eine SSL-Verbindung mit dem P12-Zertifikt aufbauen kann.
Wenn ich allerdings einen REST-Endpoint abrufen möchte, bekomme ich einen HTTP-Error 403 zurück.
Okay. Eine 403 ist keine 401.

Aber heißt das nun das die Verbindung tatsächlich funktioniert, oder das nicht?

**DeddyH**

Eine 403 (Forbidden) bedeutet normalerweise, dass Du versuchst, auf eine Ressource zuzugreifen, auf die Dir die Berechtigung fehlt. Das kann sein, wenn Du entweder nicht angemeldet bist (wobei ich da eher eine 401 erwarten würde), oder Deine Anmeldung das entsprechende Recht zum Zugriff nicht beinhaltet. Andererseits kann der Server Dir ja zurückschicken, was er für richtig hält, hier sollte ein Blick in die Dokumentation oder eine Rückfrage beim Betreiber Klarheit schaffen.

**jaenicke**

Zitat von gmc616:

Hmm ... Sorry, aber jetzt bin ich genau so schlau wie vorher.
Die Aussage "Leider gab es da einen Bug, der erst mit Delphi 11 behoben ist." hat nicht unbedingt eine motivationsfördende Wirkung.

Ich habe ja geschrieben, dass ich es trotzdem damit umgesetzt habe. Dafür muss man sich allerdings über den Speicher des Objekts, das man in einer gehookten Methode übergeben bekommt, weiterhangeln, um an die Interna der Windows-spezifischen REST-Umsetzung zu kommen. Darüber bekommt man dann das Handle der Verbindung aus der WinHTTP-API und kann darüber das Zertifikat selbst setzen.

Zitat von gmc616:

Wenn ich allerdings einen REST-Endpoint abrufen möchte, bekomme ich einen HTTP-Error 403 zurück.
Okay. Eine 403 ist keine 401.

Aber heißt das nun das die Verbindung tatsächlich funktioniert, oder das nicht?

Das kann z.B. heißen, dass das Zertifikat die Verbindung absichert, du dich aber zusätzlich als Benutzer einloggen musst, weil sich über das Zertifikat mehrere Benutzer verbinden können.

**mjustin**

Zitat von gmc616:

Aber heißt das nun das die Verbindung tatsächlich funktioniert, oder das nicht?

Ja, denn einen HTTP Statuscode erhält der Client nur wenn eine Verbindung aufgebaut werden konnte und auf der Gegenseite ein HTTP Server läuft.
Wenn die TLS/SSL Verbindung nicht hergestellt werden kann, erhält man Fehler der TLS/SSL Bibliothek.

403 kann man interpretieren als: "ich (der Server) kann Dich anhand des Zertifkats und des Passwort zwar als Benutzer erkennen, aber Dir wurde nicht der Zugriff auf die Resource gegeben":

Zitat:

Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”

https://stackoverflow.com/a/6937030/80901

Anscheinend wird das auch im RFC so beschrieben:

"Forbidden means that the client has authenticated successfully, but is not authorized."

(Kommentar unter der verlinkten Stackoverflow-Antwort)

**gmc616**

@jaenicke
Ich merke schon, du steckst wesentlich Tiefer in der Materie als ich. Begriffe wie z.B. "Hooks" sind mir zwar schon ein paar mal über den Weg gelaufen, habe sie aber links liegen lassen, weil ich nie wirklich eine Verwendung dafür finden konnte.
Ich bin Anwendungsentwickler, eher in Richtung Massendatenverarbeitung, Datenbanken und Co., Datenaustausch (jetzt immer mehr per REST) und einiges mehr.
Hooks (ich verbinde damit im Kopf Tastatur-Hooks) sind eher System-nahe Dinge, mit denen ich eigentlich nie etwas zu tun habe/hatte. Ich kann dir also nicht folgen, so gern ich das auch möchte.
Leider ist es auch so, dass dein Link (oben) nicht funktioniert. Er funktioniert nur, wenn ich den Parameter "filter" weglasse, dann komme ich aber lediglich in den Jira-BugTracker von Emba. Ist aber keine Lösung zu finden.

Deswegen bis ich aktuell etwas irritiert. Und deswegen auch die blöden Fragen.

@DeddyH
Der Hersteller hat auf dem Server eine SwaggerHub-Doku laufen. Diese Doku kann man nur aufrufen, wenn man im Windows-Zertifikatspeicher das P12-Zertifikat importiert hat. Rufe ich dort den gleichen Endpoint auf, bekomme ich einen "Code" "Undocumented" zurück, mit dieser "Erklärung":

markieren

Code:

			Failed to fetch.

Possible Reasons:

* CORS

* Network Failure

* URL scheme must be "http" or "https" for CORS request.

Was auch immer das bedeutet.

Die 403 bekomme ich nur in meinem Code zurück.

@mjustin
Siehst du das genau so wie ich?
Also der SSL-Verbindungsaufbau zum Server steht (ohne P12 hat noch nicht mal das funktioniert), nur der Server (eine Ebene weiter) lässt mich nicht zugreifen?
Wenn das so wäre, wäre ich einen kleinen Schritt weiter.

Ich wollte mich halt nicht als "komplett bescheuert" an den Support wenden, wenn ihr versteht...
Wie gesagt, mit Zertifikaten hatte ich bis eher nicht viel zu tun.

Danke für eure Unterstützung.