#10054 (die Verbindung wurde vom Peer zurückgesetzt ) - tidhttp https tls 1.2

[Emwykey]

Zitat:

Zitat von Thomas Horstmann (Beitrag 1399556)

Welche OpenSSL DLLs werden denn benutzt? 1.1.0 oder 1.0.2? Soweit ich weiß unterstützt Indy nur 1.0.2.

Aktuell 1.1.0 ich versuche es mal mit 1.0.2 und berichte


EDIT: Ok, funktioniert leider nicht...

[Emwykey]

Zitat:

Zitat von HolgerX (Beitrag 1399559)

.....
Ich denke auch, da ist was mit dem Server nicht OK ;)
.....

Hatte ich mir auch überlegt, gerade da auch der Aufruf anderer https services bei mir ebenfalls keine probleme verursacht hat, allerdings finde ich es doch seltsam, dass es in C# generell und auch unter delphi tokyo in kombination mit WIN10 ohne weiteres klappt :((( echt zum verzweifeln

[Bbommel]

Seltsam ist das nicht unbedingt. Wenn du den TRESTClient in Tokyo nutzt, dann nutzt der ja normalerweise kein Indy mehr, sondern lässt das HTTPS-Zeugs von Windows regeln. Genauso könnte es ja mit C# sein. Diese anderen SSL-Implementierungen können z.B. andere Zetrifaktslisten haben von bekannten Zertifizierungsstellen und brauchen daher z.B. ein Intermediate-Zertifikat nicht, welches ein anderer braucht.

Ich hatte das z.B. mal mit einem eigenen Server. Bei 1&1 damals ein Zertifikat gekauft und versucht es einzurichten. Bei Chrome lief dann auch https problemlos, mit Firefox kam ich aber nicht weiter. Bei mir war es dann nämlich genau so ein Problem mit dem Intermediate-Zertifikat, welches Firefox offenbar brauchte, wovon ich aber das falsche eingespielt hatte. Wenn ich das alles noch richtig rekonstruiert bekomme. :-)

[Emwykey]

Zitat:

Zitat von Bbommel (Beitrag 1399576)

.... Wenn du den TRESTClient in Tokyo nutzt, dann nutzt der ja normalerweise kein Indy mehr,...

Danke für die Antwort, aber auch mit TRESTClient funktioniert es in XE5 und vor allem unter Windows 7 sowieso garnicht :O
hab auch schon bereits versucht in der Registry TLS 1.1 und TLS 1.2 als Default Secure Protocols (https://support.microsoft.com/en-au/...e-protocols-in) zu hinterlegen geht leider trotzdem nicht auf Windows 7, auf 10 immernoch nur die in Tokyo compipierte EXE des selben Projekts


Bin zwischenzeitlich von dem Versuch mit Indy abgekommen da es einfach nicht klappen wollte

[Bbommel]

Wie gesagt - warum sich unterschiedliche Systeme unterschiedlich verhalten (Win 7 vs. Win 10, Indy vs. Windows selbst), hatte ich ja grob versucht zu beschreiben.

Aus meiner Sicht liegt der Fehler nicht beim Client, also deinem Programm, egal ob nun mit Indy oder nicht, sondern beim Server. Falls das deiner ist, müsstest du da vielleicht noch mal schauen, wo es bei den Zertifikaten oder anderen Teilen der Konfiguration hakt oder du müsstest den Admin mal darauf hinweisen. Teste es einfach selber mal mit dem Firefox.

Viel Glück. :-)

[Emwykey]

Zitat:

Zitat von Bbommel (Beitrag 1399590)

... Teste es einfach selber mal mit dem Firefox.

Viel Glück. :-)

Habe ich, und danke nochmal für die Antwort. Der Aufruf funktioniert in Chrome und Firefox ABER Firefox meldet, dass es sich nicht um eine sichere Verbindung handelt und ich muss vorerst eine Ausnahme zufügen. Ich werde das so an den Betreiber weiterleiten :)

[Olli73]

Wenn es nur am Zertifikat hängt, kannst du evtl. Mit idssliohandlersocketopenssl.onverifypeer eingreifen.

[mjustin]

Die Validierung durch https://www.ssllabs.com/ssltest/index.html ergibt Trust-Probleme und ein Problem mit der Zertifikatskette.

Dem Zertifikat wird nicht von den Trust Stores von Mozilla, Apple, Android und Java vertraut. Das erklärt, dass Chrome keinen Zertifikatsfehler anzeigt (Chrome verwendet den Windows Zertifikatsspeicher, Firefox einen eigenen).

Zur Diagnose von OpenSSL Verbindungsfehlern kann man mit openssl s_client -connect example.com:443 einen Verbindungsaufbau testen.

Das gibt zum Beispiel auf einem Linux-Client diesen Fehler aus: unable to get local issuer certificate

Zitat:

CONNECTED(00000003)
depth=1 C = AT, O = ..., OU = ..., CN = ...
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
...
---

Auf verschiedenen Computern und mit verschiedenen Frameworks kann es unterschiedliche Ergebnisse geben, je nachdem ob das Zertifikat jeweils im lokalen Zertifikatsspeicher vorhanden ist oder (noch) nicht.

Vielleicht hilft das ja weiter.

[Emwykey]

Zitat:

Zitat von Olli73 (Beitrag 1399652)

Wenn es nur am Zertifikat hängt, kannst du evtl. Mit idssliohandlersocketopenssl.onverifypeer eingreifen.

Es klappt!!!!!!! Viele vielen Dank!!!!!!!