SOAP THttpReqResp mit Certificate (Windows CertStore scsUser)

[atari1040]

Moin,

ich habe die Instandhaltung für ein altes Delphi XE8 Projekt mit SOAP-Client übernommen.
Ich habe nur den SourceCode und die alte Exe aber leider nicht die passende IDE. Die Exe war mit Delphi XE8 compiliert worden und scheinbar hat mein Vorgänger Änderungen in der Original soap.SOAPHTTPTrans.pas vorgenommen, um den Client in Verbindung mit dem Windows CertStore zum Laufen zu bringen.
Ich habe das Projekt jetzt unter Delphi 11 zum laufen bekommen aber leider öffnet der Client nun bei jedem Request den Dialog um ein Zertifikat aus dem CertStore=scsUser und CertType:'MY' auszuwählen, was bei Verwendung als CronJob natürlich nicht so nett ist.

Ich kann leider verdammt wenig zu Delphi, SOAP und Zertifikaten finden. Ältere Beiträge sind auch nicht hilfreich, weil sich scheinbar irgendwann zwischen XE8 und Delphi 11 etwas grundlegendes geändert hat.

Hat vielleicht hier jemand eine Idee, wie man den Client dazu bewegen kann, das richtige Zertifikat aus dem Windows CertStore zu übernehmen, ohne einen Dialog zu öffnen?

Danke schonmal :-)

[himitsu]

https://www.embarcadero.com/de/produ...vious-versions


Vieles baut auf Indy auf und dort hatte sich inzwischen Massig geändert.

[atari1040]

Danke.
Ich habe alle Versionen seit Delphi 1.
Mein Problem sind die Änderungen, die mein Vorgänger in der Original soap.SOAPHTTPTrans.pas gemacht hat, denn die habe ich nicht bekommen.

Es muss doch irgendwie möglich sein ein bestimmtes Zertifikat über die Seriennummer oder den Fingerprint zu definieren und automatisiert dem Request zuzuweisen, ohne das immer der blöde Dialog kommt. Wir können natürlich auch 24/7 jemanden daneben setzen :-)
Es muss ja auch nicht der Store sein. Kann man nicht einfach wie unter Linux auf ein Zertifikat in einem bestimmten Pfad verweisen?

[himitsu]

Achso, klang so als wenn du die nur nicht ins aktuelle Delphi rein bekommst und dann fehlt die passende XE8. :oops:


Vielleicht hilft das?
https://docwiki.embarcadero.com/Libr...entCertificate
https://entwickler-ecke.de/topic_SOA...ate_74665.html
https://blog.marcocantu.com/blog/201...p-clients.html


Nja, falls sich nichts direkt für diese Komponente findet:

Da drin wird ja bestimmt sowas wie TIdHTTP oder TIdTCPClient benutzt, bzw. im aktuellen Delphi vielleicht auch THTTPRIO, TNetHTTPClient oder TNetHTTPRequest,
und dafür sollten sich Beispiele finden lassen, wie man ihnen ein Zertifikat gibt.

Dann nur noch schauen, wie man das wo am Besten in die SOAP-Komponente rein bekommt.

[edit] neeeee, die gehen wohl direkt auf WinInet :stupid:

Zitat:

Note: THTTPReqResp uses WinInet to establish a connection to the server.

Sollte sich das nicht eigentlich selbstständig ein Zertifikat aus dem Store ziehen können, wenn es Eines benötigt? :gruebel:
WinInet Certificate Store

[mjustin]

Zitat:

Zitat von atari1040 (Beitrag 1518220)

leider öffnet der Client nun bei jedem Request den Dialog um ein Zertifikat aus dem CertStore=scsUser und CertType:'MY' auszuwählen, was bei Verwendung als CronJob natürlich nicht so nett ist.

Kann es an fehlenden Berechtigungen liegen?
Ist das Zertifikat in einem Zertifikatsspeicher abgelegt, auf den das Konto des CronJobs Zugriff hat?
(Eventuell kann man das testen, indem man sich als eben dieser Benutzer am System anmeldet)

[atari1040]

Zitat:

Zitat von mjustin (Beitrag 1518236)

Zitat:

Zitat von atari1040 (Beitrag 1518220)

leider öffnet der Client nun bei jedem Request den Dialog um ein Zertifikat aus dem CertStore=scsUser und CertType:'MY' auszuwählen, was bei Verwendung als CronJob natürlich nicht so nett ist.

Kann es an fehlenden Berechtigungen liegen?
Ist das Zertifikat in einem Zertifikatsspeicher abgelegt, auf den das Konto des CronJobs Zugriff hat?
(Eventuell kann man das testen, indem man sich als eben dieser Benutzer am System anmeldet)

Ich starte das Programm mit dem User unter dem der CronJob läuft.
Mit der alten Exe, die unter XE8 compiliert wurde, läuft es auch so wie gewünscht. Das Programm zieht sich das Zertifikat ohne Auswahldialog aus dem Store.
Die neue Exe mit Delphi 11 compiliert macht auch alles was sie soll, nur leider öffnet sie immer den Dialog und man muss das Zertifikat erst mit Mausklick bestätigen.
Die Ursache liegt irgendwo in der soap.SOAPHTTPTrans.pas und THTTPReqResp, die von XE8 auf Delphi11 erhebliche Unterschiede aufweist.

Hat vielleicht jemand einen SOAP Client gebaut, der sich automatisch und ohne das Auswahlfenster ein Zertifikat aus dem Store holt. Was mit XE8 funktionierte muss doch auch mit Delphi11 möglich sein?

[atari1040]

Zitat:

Zitat von himitsu (Beitrag 1518235)

Achso, klang so als wenn du die nur nicht ins aktuelle Delphi rein bekommst und dann fehlt die passende XE8. :oops:

sorry, habe mich wohl missverständlich ausgedrückt. Ich meinte damit, dass ich nicht die aufgesetzte Entwicklungsumgebung XE8 meines Vorgängers zur Verfügung habe. Der hat leider THTTPReqResp in den Delphi Sourcen um den Zugriff auf den Store erweitert. Leider hat er nicht abgeleitet sondern direkt die Sourcen geändert und die sind nie im Sourcecode Repo gelandet sondern mit seinem Rechner gelöscht worden.
Mit Delphi11 würde ich den Teil des Codes vermutlich sowieso nicht zum laufen bekommen, weil die so viel geändert haben. Ich hatte die leise Hoffnung, dass mit einer neuen Delphi Version der direkte Zugriff auf den CertStore irgendwie einfacher geworden ist.

[EmWieMichael]

Zitat:

Zitat von atari1040 (Beitrag 1518239)

...
Hat vielleicht jemand einen SOAP Client gebaut, der sich automatisch und ohne das Auswahlfenster ein Zertifikat aus dem Store holt. ...

Ja: https://www.delphipraxis.net/1321277-post22.html

[jaenicke]

Zitat:

Zitat von atari1040 (Beitrag 1518240)

Ich hatte die leise Hoffnung, dass mit einer neuen Delphi Version der direkte Zugriff auf den CertStore irgendwie einfacher geworden ist.

In Delphi 11 gibt es aufgrund meines Tickets neue Eigenschaften für die Clientzertifikat-Authentifikation:
https://quality.embarcadero.com/browse/RSP-34451

Mit Zertifikaten aus dem Store ging es über das entsprechende Event aber auch vorher problemlos (HTTPRIO.HTTPWebNode.OnNeedClientCertificate). Ich wollte die Zertifikate aber nicht in den Store packen müssen.

[atari1040]

Vielen Dank schon mal für die guten Hinweise. Ich schaue mir die an und versuche sie in die vorhandenen Sourcen zu implementieren. Wenn jemand noch gute Ideen hat, gerne immer her damit. :-)

[atari1040]

Ich habe nur die Methode OnNeedClientCertificate hinzugefügt und zugewiesen und jetzt kommt die Abfrage nicht mehr. Ich habe bis auf einen Kommentar aber noch nicht einmal Code innerhalb der Methode geschrieben. Läuft... aber komisch ist das schon, oder? :-)

[mjustin]

Zitat:

Zitat von atari1040 (Beitrag 1518276)

Ich habe nur die Methode OnNeedClientCertificate hinzugefügt und zugewiesen und jetzt kommt die Abfrage nicht mehr. Ich habe bis auf einen Kommentar aber noch nicht einmal Code innerhalb der Methode geschrieben. Läuft... aber komisch ist das schon, oder? :-)

Ja - da würde ich gleich das Zertifikat im Zertifikatsspeicher löschen und testen, ob die DHL API auch dann noch aufgerufen werden kann. :)

[jaenicke]

Zitat:

Zitat von atari1040 (Beitrag 1518276)

Ich habe nur die Methode OnNeedClientCertificate hinzugefügt und zugewiesen und jetzt kommt die Abfrage nicht mehr. Ich habe bis auf einen Kommentar aber noch nicht einmal Code innerhalb der Methode geschrieben. Läuft... aber komisch ist das schon, oder? :-)

Vielleicht ist AnIndex standardmäßig schlicht 0 (erster Eintrag) und nicht -1 (muss zugewiesen werden)?

[atari1040]

Zitat:

Zitat von mjustin (Beitrag 1518280)

Zitat:

Zitat von atari1040 (Beitrag 1518276)

Ich habe nur die Methode OnNeedClientCertificate hinzugefügt und zugewiesen und jetzt kommt die Abfrage nicht mehr. Ich habe bis auf einen Kommentar aber noch nicht einmal Code innerhalb der Methode geschrieben. Läuft... aber komisch ist das schon, oder? :-)

Ja - da würde ich gleich das Zertifikat im Zertifikatsspeicher löschen und testen, ob die DHL API auch dann noch aufgerufen werden kann. :)

Nix DHL, das ist Firmenintern und geht auf eine SAP Schnittstelle. Das geht wirklich nicht ohne Zertifikat. :-)

[himitsu]

Er meinte wohl, wenn du direkt das Zertifikat rein gibst, anstatt es im Store zu speichern.

[atari1040]

Zitat:

Zitat von himitsu (Beitrag 1518295)

Er meinte wohl, wenn du direkt das Zertifikat rein gibst, anstatt es im Store zu speichern.

ja stimmt, es wäre mir sowieso am liebsten auf den Store zu verzichten und das Zertifikat direkt als Datei zu laden, so wie ich es unter Linux gewohnt bin.

[jaenicke]

Zitat:

Zitat von atari1040 (Beitrag 1518298)

ja stimmt, es wäre mir sowieso am liebsten auf den Store zu verzichten und das Zertifikat direkt als Datei zu laden, so wie ich es unter Linux gewohnt bin.

Das geht mit der aktuellen Delphiversion direkt, siehe Ticket. Vorher musste man sich über Pointer das Handle zu der Verbindung angeln und tricksen.

Zitat:

Zitat von EmWieMichael (Beitrag 1518242)

Ja: https://www.delphipraxis.net/1321277-post22.html

Das geht zwar, aber dann muss man auf THTTPRIO verzichten.

[atari1040]

Zitat:

Zitat von jaenicke (Beitrag 1518302)

Zitat:

Zitat von atari1040 (Beitrag 1518298)

ja stimmt, es wäre mir sowieso am liebsten auf den Store zu verzichten und das Zertifikat direkt als Datei zu laden, so wie ich es unter Linux gewohnt bin.

Das geht mit der aktuellen Delphiversion direkt, siehe Ticket. Vorher musste man sich über Pointer das Handle zu der Verbindung angeln und tricksen.
...

an das Ticket komme ich nicht ran obwohl ich das gleiche Passwort verwende wie bei my.embarcadero.com und dort funktioniert es. Der Support konnte oder wollte mir auch nicht helfen. Hast Du ein Code Snippet?

[himitsu]

Bei My kann man sich mit Mail oder Name einloggen ... in Quality nicht. :stupid:

[atari1040]

Zitat:

Zitat von himitsu (Beitrag 1518310)

Bei My kann man sich mit Mail oder Name einloggen ... in Quality nicht. :stupid:

ich wusste gar nicht, dass ich noch einen Login Namen habe, so lange habe ich das alles nicht mehr benutzt. Mit Email ging irgendwie immer.
Danke, jetzt komme ich rein :-)

[atari1040]

Zitat:

Zitat von jaenicke (Beitrag 1518243)

Zitat:

Zitat von atari1040 (Beitrag 1518240)

Ich hatte die leise Hoffnung, dass mit einer neuen Delphi Version der direkte Zugriff auf den CertStore irgendwie einfacher geworden ist.

In Delphi 11 gibt es aufgrund meines Tickets neue Eigenschaften für die Clientzertifikat-Authentifikation:
https://quality.embarcadero.com/browse/RSP-34451

Mit Zertifikaten aus dem Store ging es über das entsprechende Event aber auch vorher problemlos (HTTPRIO.HTTPWebNode.OnNeedClientCertificate). Ich wollte die Zertifikate aber nicht in den Store packen müssen.

Gibt es eigentlich irgendwo Beispiele zum laden eines Zertifikats als File? Ich lese in Deinem Ticket, dass es jetzt funktionieren soll, finde aber nicht ein Beispiel wie es geladen wird.

[jaenicke]

Zitat:

Zitat von atari1040 (Beitrag 1521051)

Gibt es eigentlich irgendwo Beispiele zum laden eines Zertifikats als File? Ich lese in Deinem Ticket, dass es jetzt funktionieren soll, finde aber nicht ein Beispiel wie es geladen wird.

Was sollte das für ein Beispiel sein? Du setzt die dafür neu hinzugekommene Property (ich glaube die heißt ClientCertFilename oder so, kann gerade nicht nachschauen) und das war es.

Das war leider die einfallsloseste Variante, um das Ticket zu lösen. Mit etwas mehr Einfallsreichtum hätte man auch meinen Hinweisen folgend eine umfassende und deutlich schönere Lösung machen können. Aber ich bin schon froh, dass es nun das gibt.

[atari1040]

Zitat:

Zitat von jaenicke (Beitrag 1521088)

Zitat:

Zitat von atari1040 (Beitrag 1521051)

Gibt es eigentlich irgendwo Beispiele zum laden eines Zertifikats als File? Ich lese in Deinem Ticket, dass es jetzt funktionieren soll, finde aber nicht ein Beispiel wie es geladen wird.

Was sollte das für ein Beispiel sein? Du setzt die dafür neu hinzugekommene Property (ich glaube die heißt ClientCertFilename oder so, kann gerade nicht nachschauen) und das war es.

Das war leider die einfallsloseste Variante, um das Ticket zu lösen. Mit etwas mehr Einfallsreichtum hätte man auch meinen Hinweisen folgend eine umfassende und deutlich schönere Lösung machen können. Aber ich bin schon froh, dass es nun das gibt.

Es liegt sicherlich an mir und ich bin total blind. Wir sprechen von Delphi 11.3 und HTTPRIO? Ich finde nix mit ClientCertFilename oder einer ähnlich lautenden Property. Auch Google verrät mir nichts über das neue und bestens gehütete Geheimnis dieses neuen Features.

Nachtrag: über Code Completion wird mir HTTPRIO1.HTTPWebNode.ClientCertificate.Filename natürlich nicht angezeigt aber im Objektinspektor habe ich es schon mal gefunden. Danke

[jaenicke]

Zitat:

Zitat von atari1040 (Beitrag 1521091)

Nachtrag: über Code Completion wird mir HTTPRIO1.HTTPWebNode.ClientCertificate.Filename natürlich nicht angezeigt aber im Objektinspektor habe ich es schon mal gefunden. Danke

Ich habe auch nachgeschaut:

Delphi-Quellcode:

uses
  Soap.SOAPHTTPTrans;

procedure TForm21.Test;
begin
  TClientCertExt(HTTPRIO1.HTTPWebNode.ClientCertificate).FileName := 'blub';
end;

Wie gesagt, schön finde ich die Lösung nicht, auch wenn sie viel neu implementiert haben. Dass es z.B. Interfaces gibt, wird aber leider an einigen Stellen, an denen es sehr sinnvoll wäre, vergessen. Und an das Handle der Verbindung kommt man weiterhin nicht heran, so dass andere Dinge weiter nur über dreckigere Wege gehen.

[atari1040]

Vielen Dank!!!!

[Bbommel]

Hi zusammen,

ich muss mal dieses etwas ältere Thema aufmachen, weil mir gerade auch zum ersten Mal ein Webservice über den Weg läuft, der mit Client-Zertifikaten arbeitet. Allerdings geht es bei uns um einen REST-, nicht um einen SOAP-Service.

Sehe ich das richtig, dass die in D11 offenbar umgesetzte Lösung zwar für SOAP funktionieren würde, aber es für REST nichts vergleichbares gibt und man ein Zertifikat in den Zertifikatsspeicher laden müsste? Oder übersehe ich in den REST-Komponenten irgendwas?

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

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

Zitat von Bbommel (Beitrag 1529943)

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. :-)