Fehler beim Abrufen des Serverzertifikats

[Sliver18]

Hallo Delphi-Experten,

ich habe da eine Problematik, bei der ich bereits in der Analyse verzweifle...

In der Firma benutzen wir Shipment das API von UPS, um unsere Pakete anzumelden. Dazu habe ich einst die WSDL von UPS importiert. Das klappt seit etlichen Monaten. Nun bin ich auf Delphi 10.3 umgestiegen und es klappt nicht mehr. Beim Ausführen meines Aufrufs erhalte ich die Fehlermeldung "Fehler beim Abrufen des Serverzertifikats". Damit kann ich gar nichts anfangen, denn die Fehlermeldung sagt mir überhaupt nichts und ich weiß auch gar nicht, was ich nun für Analyse-Möglichkeiten habe. Das Verrückte ist: Führe ich den Code auf meiner Entwicklungsmaschine aus (Debug), klappt es - auf allen anderen Maschinen klappt es jedoch nicht (Release). Das macht mich stutzig, denn ich wüsste nicht, was sich da anders verhält. Im Code wird kein Unterschied gemacht, um welchen Build es sich handelt - und so weit ich weiß, muss man eine importierte WSDL doch nicht mit ausliefern, oder? Ich weiß noch nicht einmal, was für ein Zertifikat hierbei gemeint ist. Schicke ich absichtlich "defekte" Daten , erhalte ich auch eine entsprechende Response vom Server, die Kommunikation kommt also zustande.

Kennt jemand diese Problematik? Kann mir jemand erläutern, was für Analyse-Möglichkeiten bestehen?

Vorsichtshalber erwähne ich noch, dass auch ein THTTPRIO hierbei verwendet wird, damit ich den Request und die Response loggen kann. Vielleicht hängt das ja irgendwie damit zusammen. Allerdings läuft der OnBeforeExecute-Event fehlerfrei durch.

[TiGü]

Es gibt eine Vielzahl an Berichten, dass diverse Teile des SOAP-Frameworks und der darin verwendeten Softwarekomponenten Breaking Changes erfahren haben.
Sollte es möglich sein, das Projekt zurück auf Delphi Tokyo 10.2.3. zu bringen, sparst du dir viele graue Haare.
Natürlich nur insofern es daran lag und nicht doch der Fehler in deinen Quelltexten oder dem Zertifikat liegt.
Aber der Versuch ist relativ schnell gemacht.

Es gilt die goldene Regel:
Keine Delphi-Version vor dem Update 1 verwenden.

[Sliver18]

Zitat:

Zitat von TiGü (Beitrag 1424700)

Es gibt eine Vielzahl an Berichten, dass diverse Teile des SOAP-Frameworks und der darin verwendeten Softwarekomponenten Breaking Changes erfahren haben.
Sollte es möglich sein, das Projekt zurück auf Delphi Tokyo 10.2.3. zu bringen, sparst du dir viele graue Haare.

Oha, da habe ich noch gar nichts mitgekriegt. Aber gut, dass Du es erwähnst, danke!

Zitat:

Zitat von TiGü (Beitrag 1424700)

Natürlich nur insofern es daran lag und nicht doch der Fehler in deinen Quelltexten oder dem Zertifikat liegt.
Aber der Versuch ist relativ schnell gemacht.

Ja, ich habe auf der alten Entwicklermaschine noch 10.2.3 drauf. Theoretisch könnte ich mir da ja eine DLL basteln, die das Ganze dann einfach in der 10.2.3er-Version ausgliedert.

Zitat:

Zitat von TiGü (Beitrag 1424700)

Es gilt die goldene Regel:
Keine Delphi-Version vor dem Update 1 verwenden.

Das werde ich mir merken... :/

[Sliver18]

Ich habe noch etwas herausgefunden:

Führe ich das Programm auf meinem Entwicklersystem aus, kann ich die SOAP-Kommunikation fehlerfrei durchführen. Kopiere ich die EXE auf ein anderes System, kommt es weiterhin zu der besagten Fehlermeldung. Es scheint also, als wäre nur der Rechner, mit dem ich das Programm erstellt habe, mit "etwas" ausgestattet, das die Kommunikation gestattet.

Dazu mal die Frage: Von was für einem Zertifikat ist hier überhaupt die Rede? Geht es hier um ein SSL-Zertifikat für die Kommunikation (der Webservice liegt unter einer HTTPS-Adresse)? Kann es sein, dass beim Ausführen aus Delphi heraus eine andere (vielleicht vorinstallierte) Version der SSL-Bibliotheken verwendet wird? Oder werden die freien SSL-Bibliotheken bei einer HTTPRIO bzw. WSDL-Verbindung überhaupt nicht benutzt?

[mkinzler]

Kommt darauf an, welche Delphiversion. Neuere Versionen verwenden die Unterstützung von Windows.

[Sliver18]

Zitat:

Zitat von mkinzler (Beitrag 1424944)

Kommt darauf an, welche Delphiversion. Neuere Versionen verwenden die Unterstützung von Windows.

Die verwendete Delphiversion ist 10.3 auf einem Rechner mit Windows 10.

EDIT: Das System, auf dem die Kopie getestet wurde ist übrigens Windows 7

[generic]

Zitat:

Zitat von Sliver18 (Beitrag 1424943)

Ich habe noch etwas herausgefunden:

Dazu mal die Frage: Von was für einem Zertifikat ist hier überhaupt die Rede? Geht es hier um ein SSL-Zertifikat für die Kommunikation (der Webservice liegt unter einer HTTPS-Adresse)? Kann es sein, dass beim Ausführen aus Delphi heraus eine andere (vielleicht vorinstallierte) Version der SSL-Bibliotheken verwendet wird? Oder werden die freien SSL-Bibliotheken bei einer HTTPRIO bzw. WSDL-Verbindung überhaupt nicht benutzt?

An so etwas glaube ich auch. Die haben bestimmt auf ein SHA256 Zertifikat umgestellt oder einige alte Methoden wie RC4, MD5 abgeschaltet.
Vielleicht kann daher dein Delphi nicht mehr mit dem Server kommunizieren, weil die SSL-Bib. zu alt ist?

[Sliver18]

Zitat:

Zitat von generic (Beitrag 1424964)

An so etwas glaube ich auch. Die haben bestimmt auf ein SHA256 Zertifikat umgestellt oder einige alte Methoden wie RC4, MD5 abgeschaltet.
Vielleicht kann daher dein Delphi nicht mehr mit dem Server kommunizieren, weil die SSL-Bib. zu alt ist?

Dann wäre der nächste Ansatz also, neue SSL-Bibliotheken herunterzuladen und es damit zu versuchen?

Noch was: Die ausgelieferten Bibliotheken sind auf beiden Systemen identisch. Werden in Delphi mittlerweile bei der Erstinstallation Bibliotheken mitgeliefert? Das war meines Wissens nach früher nicht so...? Das würde zumindest erklären, warum es auf dem Entwicklungssystem mit frisch installiertem neuen Delphi funktioniert und auf dem "alten" System mit den alten Bibliotheken nicht. Außerdem sind die Bibliotheken im Order der EXE identisch - die werden doch als erstes verwendet, oder?

[TiGü]

Kannst du auf den Windows 7 System was installieren?

Wenn ja, schau doch mal bitte, wie weit du in der Unit Soap.SOAPHTTPTRans in der Methode THTTPReqResp.Send kommst, indem du die Windowsfunktionen:
HttpOpenRequest,
InternetSetOption,
HttpAddRequestHeaders,
HttpSendRequest,
WinHttpReceiveResponse und HttpEndRequest
mit diesen Tool loggst:
http://www.rohitab.com/apimonitor

[Sliver18]

Zitat:

Zitat von TiGü (Beitrag 1424981)

Kannst du auf den Windows 7 System was installieren?

Japp.

Zitat:

Zitat von TiGü (Beitrag 1424981)

Wenn ja, schau doch mal bitte, wie weit du in der Unit Soap.SOAPHTTPTRans in der Methode THTTPReqResp.Send kommst, indem du die Windowsfunktionen:
HttpOpenRequest,
InternetSetOption,
HttpAddRequestHeaders,
HttpSendRequest,
WinHttpReceiveResponse und HttpEndRequest
mit diesen Tool loggst:
http://www.rohitab.com/apimonitor

Ui, mächtiges Tool.

Tatsächlich gehen die Aufrufe in den Bereich der WinHttp.dll:

WinHttpOpenRequest
WinHttpAddRequestHeaders
WinHttpSetOption
WinHttpSendRequest

Dabei wird mir auf dem nicht funktionierenden System direkt die Fehlermeldung "12175 - Die Inhaltscodierung ist fehlgeschlagen." im Tool an der Methode WinHttpSendRequest mit angezeigt. Das sieht mir stark nach der Fehlerursache aus.

Kommen wir damit weiter?