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?

[TiGü]

Kommt drauf an.
Kannst du in der Hex Buffer Ansicht sehen, was für ein Inhalt lpOptional hat?
Im Anhang bspw. ein SOAP-Request. Hier sieht man in der Textansicht (rot umkringelt) den XML-Text des Requests.

Weiter oben ist bei HttpOpenRequest die Resource zu sehen (also die Adresse des Webservice ohne IP-Adresse/Domain und Port) und dann später bei HttpAddRequestHeadersW wird bspw. der Content-Type gesetzt.
Stehen denn bei dir da sinnvolle Werte drin? Und wie sieht der Vergleich zu deinem Entwicklersystem aus?

Hake auch mal alles unter dem Treenode "Security and Identity" an und schaue, ob das irgendwas mit Zertifkaten und Verschlüssung passiert. Wieder ist der Vergleich zwischen deinem System und dem Windows 7 System zielführend.

[Sliver18]

Zitat:

Zitat von TiGü (Beitrag 1424990)

Kannst du in der Hex Buffer Ansicht sehen, was für ein Inhalt lpOptional hat?
Im Anhang bspw. ein SOAP-Request. Hier sieht man in der Textansicht (rot umkringelt) den XML-Text des Requests.

Leider nein, wenn ich die Zeile markiere (oder lpOptional), passiert gar nichts in dem Hex-Fenster (Bedienungsfehler?).

Zitat:

Zitat von TiGü (Beitrag 1424990)

Weiter oben ist bei HttpOpenRequest die Resource zu sehen (also die Adresse des Webservice ohne IP-Adresse/Domain und Port) und dann später bei HttpAddRequestHeadersW wird bspw. der Content-Type gesetzt.
Stehen denn bei dir da sinnvolle Werte drin? Und wie sieht der Vergleich zu deinem Entwicklersystem aus?

Ja, Werte sind vorhanden und sehen auch plausibel aus. Dabei sind die Werte auf beiden Systemen identisch.

Zitat:

Zitat von TiGü (Beitrag 1424990)

Hake auch mal alles unter dem Treenode "Security and Identity" an und schaue, ob das irgendwas mit Zertifkaten und Verschlüssung passiert. Wieder ist der Vergleich zwischen deinem System und dem Windows 7 System zielführend.

Da haben wir eine Fehlerkolonne... Auf dem funktionierenden Win 10 System läuft alles sauber durch, aber auf dem Win 7 System hagelt es 1008er-Fehlermeldungen bei zahlreichen OpenThreadToken-Aufrufen: "Es wurde versucht, auf ein Token zuzugreifen, das nicht vorhanden ist."

Ich hänge ein paar Bilder an:

- Den leeren Hexbereich
- Die Abteilung mit den gesetzten AddRequestHeader-Werten
- Der neue Fehler 1008 aus dem Bereich Security und Identity

[TiGü]

Bei dem Windows 10 gibt es demzufolge nur einen oder nur wenige OpenThreadToken() Aufrufe?

[Sliver18]

Zitat:

Zitat von TiGü (Beitrag 1425014)

Bei dem Windows 10 gibt es demzufolge nur einen oder nur wenige OpenThreadToken() Aufrufe?

Das überrascht mich jetzt - es gibt nicht einen Einzigen...

Ich hänge hier mal die "Logs" der Ausführung an. Darin sieht man, dass die Prozedur unter Windows 10 offenbar völlig anders durchlaufen wird.

[EmWieMichael]

Welche IE-Version ist auf den Win7-Rechnern installiert?

[Sliver18]

Zitat:

Zitat von EmWieMichael (Beitrag 1425027)

Welche IE-Version ist auf den Win7-Rechnern installiert?

Es ist Version 11.0.9600.19236.

[TiGü]

Zitat:

Zitat von Sliver18 (Beitrag 1425032)

Zitat:

Zitat von EmWieMichael (Beitrag 1425027)

Welche IE-Version ist auf den Win7-Rechnern installiert?

Es ist Version 11.0.9600.19236.

Vergleiche mal im jeweiligen Internet Explorer auf beiden Systemen per Einstellungen (Zahnrad) -> Internetoptionen die genaue Konfiguration im Tab Verbindungen (hier auch Button "LAN-Einstellungen") und unter dem Tab Erweitert ganz unten unter dem Knoten Sicherheit.

Vielleicht gibt es einen Unterschied.
Man kann da ja so Sachen wie "SSL 3.0/TLS 1.0/TLS 1.1/TLS 1.2 verwenden" an- und abwählen.
Wahrscheinlich wirkt sich das auch auf die Aufrufe der Systemfunktionen aus.

[Sliver18]

Zitat:

Zitat von TiGü (Beitrag 1425035)

Vergleiche mal im jeweiligen Internet Explorer auf beiden Systemen per Einstellungen (Zahnrad) -> Internetoptionen die genaue Konfiguration im Tab Verbindungen (hier auch Button "LAN-Einstellungen") und unter dem Tab Erweitert ganz unten unter dem Knoten Sicherheit.

Ein Unterschied in den LAN-Einstellungen: Auf dem Win-7-System ist der Haken "Einstellungen automatisch erkennen" gesetzt.

Zitat:

Zitat von TiGü (Beitrag 1425035)

Man kann da ja so Sachen wie "SSL 3.0/TLS 1.0/TLS 1.1/TLS 1.2 verwenden" an- und abwählen.
Wahrscheinlich wirkt sich das auch auf die Aufrufe der Systemfunktionen aus.

Hm... hier sind nicht wirklich Unterschiede vorhanden. Nur die Einstellung für "Do-not-Track", aber das wird hier ja wohl kaum verwendet werden.

[Delphi.Narium]

Keine Ahnung, ob mein Vorgehen hier jetzt sinnvoll ist oder nicht:

Irgendwo gibt es ja 'ne Url https:/wasauchimmer.xyz/und dann mehr oder weniger weiteres.

Nimm bitte dieses https:/wasauchimmer.xyz/ und gib es auf dem nicht funktionierenden Rechner im Internetexplorer ein.

Was passiert dann?

'ne sinnvoile Anzeige, 'ne Fehlermeldung, oder kommt dort dann auch der Zertifikatsfehler?
Folgt dem eventuell ein Dialog, in dem Du entscheiden kannst, ob das Zertifikat importiert werden soll, verworfen oder was auch immer?

Hast Du auf dem Problemrechner auch noch 'nen anderen Browser? Was macht der bei der Eingabe der Url? Alles ok oder irgendeine Fehlermeldung?

https://praxistipps.chip.de/internet...-was-tun_28343

https://support.microsoft.com/de-de/...ate-when-you-t

https://www.hnee.de/de/Service/IT-Se...igen-E6520.htm Sinngemäß den Inhalt der verlinkten PDF befolgen: https://www.hnee.de/_obj/82BF38A8-E2...stallieren.pdf

Auf dieser Seite https://www.ionos.de/tools/ssl-check mal Deine Url eingeben und prüfen lassen, wie es da so mit dem Zertifikat aussieht. Du solltest da erfahren, ob das Zertifikat in Ordnung ist, ob es richtig installliert ist ...

Eventuell bekommst Du so etwas konkretere Informationen, mit denen wir dann hier gezielt weitersuchen /-helfen können.

Erst wenn alle obigen "Tests" fehlerfrei beendet werden und dann das Problem bestehen bleibt, müssen wir uns Sorgen um Deine Implementierung und/oder Deine Delphiversion machen.

[TiGü]

Geht es hierum?
https://www.ups.com/upsdeveloperkit/...urce?loc=en_DE

[Sliver18]

Zitat:

Zitat von TiGü (Beitrag 1425052)

Geht es hierum?
https://www.ups.com/upsdeveloperkit/...urce?loc=en_DE

Ja, genau. Das Shipment API von UPS.

[Sliver18]

Zitat:

Zitat von Delphi.Narium (Beitrag 1425043)

Keine Ahnung, ob mein Vorgehen hier jetzt sinnvoll ist oder nicht:

Irgendwo gibt es ja 'ne Url https:/wasauchimmer.xyz/und dann mehr oder weniger weiteres.

Nimm bitte dieses https:/wasauchimmer.xyz/ und gib es auf dem nicht funktionierenden Rechner im Internetexplorer ein.

Was passiert dann?

'ne sinnvoile Anzeige, 'ne Fehlermeldung, oder kommt dort dann auch der Zertifikatsfehler?
Folgt dem eventuell ein Dialog, in dem Du entscheiden kannst, ob das Zertifikat importiert werden soll, verworfen oder was auch immer?

Hast Du auf dem Problemrechner auch noch 'nen anderen Browser? Was macht der bei der Eingabe der Url? Alles ok oder irgendeine Fehlermeldung?

https://praxistipps.chip.de/internet...-was-tun_28343

https://support.microsoft.com/de-de/...ate-when-you-t

https://www.hnee.de/de/Service/IT-Se...igen-E6520.htm Sinngemäß den Inhalt der verlinkten PDF befolgen: https://www.hnee.de/_obj/82BF38A8-E2...stallieren.pdf

Auf dieser Seite https://www.ionos.de/tools/ssl-check mal Deine Url eingeben und prüfen lassen, wie es da so mit dem Zertifikat aussieht. Du solltest da erfahren, ob das Zertifikat in Ordnung ist, ob es richtig installliert ist ...

Eventuell bekommst Du so etwas konkretere Informationen, mit denen wir dann hier gezielt weitersuchen /-helfen können.

Erst wenn alle obigen "Tests" fehlerfrei beendet werden und dann das Problem bestehen bleibt, müssen wir uns Sorgen um Deine Implementierung und/oder Deine Delphiversion machen.

Da habe ich jetzt ein paar Hausaufgaben ;) Ich melde mich, wenn ich die Tests abgeschlossen habe - eventuell heute nicht mehr.

Generell möchte ich mich bei Euch allen aber schon einmal ganz dicke für Eure umfangreichen Analyse-Ideen bedanken! Ich hätte gar nicht mit so vielen Ideen (und soviel Geduld) gerechnet.

[Sliver18]

Ok, das ging jetzt doch schneller als gedacht.

Zitat:

Zitat von Delphi.Narium (Beitrag 1425043)

Keine Ahnung, ob mein Vorgehen hier jetzt sinnvoll ist oder nicht:

Irgendwo gibt es ja 'ne Url https:/wasauchimmer.xyz/und dann mehr oder weniger weiteres.

Die betreffende Adresse ist https://onlinetools.ups.com/webservices/Ship

Zitat:

Zitat von Delphi.Narium (Beitrag 1425043)

Nimm bitte dieses https:/wasauchimmer.xyz/ und gib es auf dem nicht funktionierenden Rechner im Internetexplorer ein.

Was passiert dann?

'ne sinnvoile Anzeige, 'ne Fehlermeldung, oder kommt dort dann auch der Zertifikatsfehler?
Folgt dem eventuell ein Dialog, in dem Du entscheiden kannst, ob das Zertifikat importiert werden soll, verworfen oder was auch immer?

Hast Du auf dem Problemrechner auch noch 'nen anderen Browser? Was macht der bei der Eingabe der Url? Alles ok oder irgendeine Fehlermeldung?

"Leider" funktioniert das tadellos. Im Internet Explorer wird die Seite fehlerfrei dargestellt, wie auf dem funktionierenden System (und auch in anderen Browsern). Man erhält dann eine Seite, auf der die folgenden Daten angegeben sind (das ist von UPS so gewollt und in der Dokumentation auch so beschrieben).

Service Name: ShipWS
Remote User: null
Server Port: 443
Server Name: onlinetools.ups.com
Servlet Path: /Ship

Zitat:

Zitat von Delphi.Narium (Beitrag 1425043)

https://praxistipps.chip.de/internet...-was-tun_28343

https://support.microsoft.com/de-de/...ate-when-you-t

https://www.hnee.de/de/Service/IT-Se...igen-E6520.htm Sinngemäß den Inhalt der verlinkten PDF befolgen: https://www.hnee.de/_obj/82BF38A8-E2...stallieren.pdf

Einen Zertifikatsfehler erhalte ich "leider" nicht.

Zitat:

Zitat von Delphi.Narium (Beitrag 1425043)

Auf dieser Seite https://www.ionos.de/tools/ssl-check mal Deine Url eingeben und prüfen lassen, wie es da so mit dem Zertifikat aussieht. Du solltest da erfahren, ob das Zertifikat in Ordnung ist, ob es richtig installliert ist ...

Eventuell bekommst Du so etwas konkretere Informationen, mit denen wir dann hier gezielt weitersuchen /-helfen können.

Sieht auch alles gut aus - siehe Anhang.

Zitat:

Zitat von Delphi.Narium (Beitrag 1425043)

Erst wenn alle obigen "Tests" fehlerfrei beendet werden und dann das Problem bestehen bleibt, müssen wir uns Sorgen um Deine Implementierung und/oder Deine Delphiversion machen.

Wie kann ich da helfen? Mein Aufruf geht ja über den Standard-WSDL-Aufruf, den Delphi beim Import einer WSDL anlegt:

Code:

procedure _ProcessShipment(out sresp: ShipmentResponse; const RequestStream, ResponseStream: TMemoryStream);
var
  prio: THTTPRIO;
  port: ShipPortType;
  h: TUPSWebServiceHandler;
begin
  h := TUPSWebServiceHandler.Create(RequestStream, ResponseStream);
  try
    prio := THTTPRIO.Create(nil);
    prio.OnBeforeExecute := h.UPSShipmentSOAPBeforeExecute; // speichert eine Kopie des Requests für Log-Zwecke
    prio.OnAfterExecute := h.UPSShipmentSOAPAfterExecute; // speichert eine Kopie der Response für Log-Zwecke

    port := GetShipPortType(False, UPSWEBSERVICE_SHIPMENT_URL, prio);

    sresp := port.ProcessShipment(nil, nil); // diese Zeile wirft den Fehler
  finally
    h.Free;
  end;
end;

Im Log sehe ich, dass UPSShipmentSOAPBeforeExecute durchlaufen wird, das SOAP-Request sieht auch in Ordnung aus.

[Sliver18]

Woran liegt es eigentlich, dass auf der Win10-Maschine ein anderes Verfahren benutzt wird, als auf der Win7-Maschine (wie mit dem API-Monitor beobachtet)? Liegt es an Windows selbst, an der Delphiversion, den Indy-Komponenten, den verwendeten Indy-Dlls? Kann diese Steuerung eventuell auf das alte Verfahren umgestellt werden?

[ennymaniac]

Mit Delphi 10.3 wurden umfangreiche Änderungen realisiert. Die SOAP Komponenten bauen jetzt auf THTTPClient auf, einer Embarcadero eigenen Implementierung. Das ist eigentlich gut, scheint aber manchmal doch noch betriebssystemabhängig zu sein.
Es scheint auch so zu sein, dass der Fehler nur in Verbindung mit bestimmten Zertifikaten auftritt. Anscheinend, wird dann ein Protokoll ausgewählt, was der Server ablehnt.

Workaround:

Delphi-Quellcode:

procedure TForm1.ProcessShipment(out sresp: ShipmentResponse; const RequestStream, ResponseStream: TMemoryStream);
var
  prio: THTTPRIO;
  port: ShipPortType;
  h: TUPSWebServiceHandler;
begin
  h := TUPSWebServiceHandler.Create(RequestStream, ResponseStream);
  try
    prio := THTTPRIO.Create(nil);
    prio.HTTPWebNode.OnBeforePost:=SoapBeforePost; //Vor jedem Post ausführen
    port := GetShipPortType(False, UPSWEBSERVICE_SHIPMENT_URL, prio);

    sresp := port.ProcessShipment(nil, nil); // diese Zeile wirft den Fehler
  finally
    h.Free;
  end;
end; 

procedure TForm1.SoapBeforePost(const HTTPReqResp: THTTPReqResp; Client: THTTPClient);
begin
  Client.SecureProtocols:=[THTTPSecureProtocol.TLS11, THTTPSecureProtocol.TLS12];
end;

SoapBeforePost wird dann vor jeder Operation aufgerufen und dort kann der THTTPClient direkt beeinflusst werden. THTTPSecureProtocol.TLS12 verwendet dann TLS12 was von vielen Servern akzeptiert wird.

[Sliver18]

Zitat:

Zitat von ennymaniac (Beitrag 1425964)

Mit Delphi 10.3 wurden umfangreiche Änderungen realisiert. Die SOAP Komponenten bauen jetzt auf THTTPClient auf, einer Embarcadero eigenen Implementierung. Das ist eigentlich gut, scheint aber manchmal doch noch betriebssystemabhängig zu sein.
Es scheint auch so zu sein, dass der Fehler nur in Verbindung mit bestimmten Zertifikaten auftritt. Anscheinend, wird dann ein Protokoll ausgewählt, was der Server ablehnt.

Hallelujah! Dieser Workaround ist Gold wert. Es funktioniert auf beiden Systemen. Vielen Dank Dir!

Gilt das oben zitierte eigentlich nur für die SOAP-Komponenten? Oder berührt das auch andere Dinge, z.B. SSL-Kommunikation ohne Indy-SSL-Bibliotheken?

[ennymaniac]

Das gilt für ziemlich viele Teile. Der Vorteil ist, die Unabhängigkeit von INDY. Wäre natürlich schön, wenn es auch funktionieren würde. :-D

[Sliver18]

Zitat:

Zitat von ennymaniac (Beitrag 1425981)

Das gilt für ziemlich viele Teile. Der Vorteil ist, die Unabhängigkeit von INDY. Wäre natürlich schön, wenn es auch funktionieren würde. :-D

Haha, ja stimmt. Du hast nicht zufällig einen hilfreichen Link zum Nachlesen dieser Veränderungen?