Fehler beim Abrufen des Serverzertifikats

[Sliver18]

Zitat von TiGü:

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

Ja, genau. Das Shipment API von UPS.

[Sliver18]

Zitat von 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.

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

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

Zitat von Delphi.Narium:

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 von Delphi.Narium:

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 von Delphi.Narium:

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 von Delphi.Narium:

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

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.

[Sliver18]

Zitat von 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.

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