SOAP THttpReqResp mit Certificate (Windows CertStore scsUser)

[jaenicke]

Das sollte auch mit Rest gehen. Die Umsetzung passierte in den Http-Komponenten dahinter.

In jedem Fall geht es manuell, wenn man via Pointer das Handle der Verbindung extrahiert und dort das Zertifikat manuell setzt. So habe ich es bei 10.4 gelöst.

[Bbommel]

Danke dir für die schnelle Antwort. Mit dem TRESTClient geht das dann leider nicht so einfach, weil der zugehörige eigentliche HTTP-Client "doppelt" in "private"-Feldern steckt. Doppelt, weil im TRESTClient zunächst im private-Bereich ein eigenes TRESTHTTP steht und erst das hat dann, auch wieder im "private", das eigentliche THTTPClient. Ist auch immer ein großer und etwas verwirrender Spaß beim Debuggen. Aber da kommt man so einfach nicht dran, wenn man nicht mit einer gepatchen Version der REST.HttpClient-Unit arbeiten will.

Vielleicht würde die von dir erwähnte Variante mit dem Pointer auf das Handle der Verbindung gehen, aber irgendwie stehe ich da gerade ehrlich gesagt etwas auf dem Schlauch - an das Handle der Verbindung käme ich ja auch nicht, wenn das alles so private ist, oder?

Naja, es wird wohl auch erstmal damit gehen, dass wir im konkreten Fall die Zertifikate in den Winodws-Zertifikatsspeicher kippen. Aber anders wäre schon schöner. Und die Linux-Seite habe ich mir noch gar nicht angeschaut.

[jaenicke]

Das meinte ich mit Pointern. Die konkrete Implementierung liegt leider unter implementation in System.Net.HttpClient.Win.pas, so dass man mit RTTI usw. nicht so einfach weiter kommt (ja, man könnte den ClassType verwenden, aber am Ende habe ich es lieber manuell gemacht). Man kann aber im Debugger ausrechnen oder im Speicher manuell nachschauen, wie viele Bytes das Feld von der Adresse des Objekts entfernt ist. Dann kann man das Feld an der Adresse auslesen. So kommt man dann darüber an das Handle in diesem Objekt. Um an den HttpClient zu kommen, kann man auch so vorgehen oder es dort mit der RTTI machen, denn die sollte dort verfügbar sein.

Natürlich muss man solche Tricks gut dokumentieren und per IFDEF auf geprüfte Delphiversionen absichern, so dass es bei einer neuen Version an der Stelle einen Fehler gibt. Dann muss man die Position der Felder mit der Version zuerst prüfen.

Ab Delphi 11 kann man dann einfach TRESTHTTPExt statt TRESTHTTP verwenden, wo man entsprechende Felder zum Übergeben des Zertifikats hat. Die entsprechende Funktionalität war bereits in Delphi 10.4 vorhanden, aber leider nicht erreichbar...

[Bbommel]

Hm, TRESTHTTPExt kann ich bei mir nicht finden. Ist das ein Record Helper, den die erst in D11.3 eingebaut haben? Wir sind noch mit 11.2 unterwegs. Oder ich stelle mich zu blöd an.

Aber in D12 ist "ClientCertificatePath", "ClientCertificatePassword" und "ClientCertificateStream" tatsächlich eine public Eigenschaft vom TRESTClient - die scheinen da also etwas aufgeräumt zu haben. Insofern Danke, dass du damals das Ticket erstellt und mich gerade in die richtige Richtung geschubst hast.

[TiGü]

Zitat von Bbommel:

Hm, TRESTHTTPExt kann ich bei mir nicht finden. Ist das ein Record Helper, den die erst in D11.3 eingebaut haben? Wir sind noch mit 11.2 unterwegs. Oder ich stelle mich zu blöd an.

In D11.3 beginnt die Definition in Zeile 261 der Unit REST.HttpClient.

Delphi-Quellcode:

  TRESTHTTPExt = class(TRESTHTTP)
  private
    FClientCertificatePassword: string;
    FClientCertificatePath: string;
    FClientCertificateStream: TStream;
    procedure SetClientCertificatePath(const AValue: string);
    procedure SetClientCertificateStream(const AValue: TStream);
  public
    property ClientCertificateStream: TStream read FClientCertificateStream write SetClientCertificateStream;
    property ClientCertificatePath: string read FClientCertificatePath write SetClientCertificatePath;
    property ClientCertificatePassword: string read FClientCertificatePassword write FClientCertificatePassword;
  end;

[Bbommel]

So, bei uns wurde das Thema mit den Clientzertifikaten nun auch noch ernster. Bis das bei uns alles wie gewünscht lief, waren allerdings noch so einige Eingriffe in den Delphi-Bibliotheken nötig. Unser Szenario war und ist dabei, dass wir aus dem System, das wir anbinden wollen, eine pfx-Datei geliefert bekommen haben. Ich habe für die ganzen Probleme, die dabei unter Windows und unter Linux aufgetreten sind, mal in QC neue Einträge erstellt:

• Unter Windows wird das falsche Zertifikat aus einer pfx-Datei benutzt
• Die Umsetzung unter Windows und unter Linux/Curl verhalten sich genau gegensätzlich bezüglich pfx-Dateien
• pfx-Dateien werden unter Linux/Curl überhaupt nicht erkannt
• Wenn unter Linux/Curl gleichzeitig Clientzertifikate und selbst signierte Serverzertifikate zum Einsatz kommen, funktioniert eigentlich gar nicht mehr

Wenn ihr dazu Feedback für mich oder Emba habt, dann gerne. Ich habe halt auch keinen Haufen von zig verschiedenen Zertifikatsdateien aus verschiedenen Systemen und ich vermute, dass es Emba genauso geht, insofern kann ich schon nachvollziehen, dass das Entwickeln und Testen hier etwas schwieriger ist. Ich weiß jetzt auch nur, dass das, was ich oben geschrieben war, nötig war, damit es bei uns läuft. Falls ihr Zeit habt, könnt ihr ja mal kritisch drüber schauen und prüfen, ob es zumindest für euch nichts kaputtmachen würde, was ich da vorgeschlagen habe.