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

[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.

[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":

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.

[jaenicke]

Zitat von gmc616:

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?

Danach sieht es aus, ja.

Zitat von gmc616:

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 Same-Origin-Policy soll verhindern, dass Skripte Daten von fremden Servern nachladen. Mit CORS kann man im Header angeben, dass Inhalte bestimmter Server erlaubt sind.

Was genau dabei dort das Problem ist, lässt sich aus der Fehlermeldung aber nicht ersehen. Dafür müsste man schauen, welche Requests dort abgesendet werden usw.

Zitat von gmc616:

Ich kann dir also nicht folgen, so gern ich das auch möchte.

Das ist gar nicht so schwer. Man muss lediglich wissen, dass die virtuellen Methoden einer Klasse in einer Tabelle im Speicher liegen, die direkt hinter dem Pointer auf die Klasse selbst liegt.
Castet man also die Klasse auf Pointer und schaut an der Stelle in den Speicher (in der CPU-Ansicht), kann man dahinter nach der Adresse der Methode suchen, die man ersetzen möchte. Die Differenz zwischen dieser Speicherstelle und der der Klasse muss man dann zum Pointer auf die Klasse addieren.

An die Stelle kann man dann die Adresse der neuen Methode schreiben und schon wird diese statt der ursprünglichen Methode ausgeführt.

Erschwerend kommt hier hinzu, dass die Klasse TWinHTTPClient unterhalb von implementation steht, so dass ich an die Klasse gar nicht heran kam. Deshalb musste ich die Klassenadresse über die an das BeforePost übergebene Clientinstanz ermitteln (Client.ClassType). So konnte ich dann TWinHTTPClient.DoGetClientCertificates überschreiben.

DoGetClientCertificates wiederum bekommt den Request übergeben und so konnte ich im Speicher nach dem Handle der Verbindung suchen und fand es 164 Byte hinter dem Pointer auf das Objekt. Auf diesem Wert konnte ich dann mit WinHttpSetOption(<Handle>, WINHTTP_OPTION_CLIENT_CERT_CONTEXT, ...) den Zertifikatskontext als Clientzertifikat setzen.

Den Kontext wiederum konnte ich erhalten, indem ich im Speicher mit PFXImportCertStore einen temporären Zertifikats-Store erstellt habe und darin mit CertFindCertificateInStore den passenden Kontext ermittelt habe.

Das führt an der Stelle vielleicht zu weit, aber vielleicht interessiert es ja jemanden, wie man das bis Delphi 10.4 umgehen kann. Ab Delphi 11 gibt es einfach Properties, so dass man den Dateinamen oder einen Stream mit den Zertifikatsdaten angeben kann.

[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)