Datei aus dem Internet herunterladen - geht nicht mehr!

[DieDolly]

Zitat:

Diese Dinge musst Du einmal zum Laufen bringen in einer neuen Version. Vor allem, wenn Du Altcode hast.

Das ist klar. Aber willst du dich wirklich weiter mit solchen Altlasten abgeben? Eine OpenSSL-Version aus 2017 zu benutzen ist nicht gerade gut finde ich. Es gibt nicht umsonst SSL Updates.

Dann doch lieber einmal alles richtig nach 10.3 bringen und Ruhe haben.

[NicoleWagner]

Ich habe Monate gebraucht, die jetzigen Komponenten in deren jeweiligen Versionen und dem vorhandenen Code zum Laufen zu bringen.
Wirklich Monate. Nur rumgemacht statt irgendwas Produktives zu arbeiten. Jetzt habe ich das in ein VM gegossen und will es nie wieder rausholen.

Ich denke, dass die eine Zeile des Downloads zwar sehr lästig ist, doch die kleinere Arbeit.

Hast Du noch Ideen, wie ich dieses SSL-Bibliothek laden könnte?
Das scheint mir wirklich das Plausibelste: Sie haben irgendeine Sicherheitsrichtilie im Protokoll hochgesetzt und meine Sachen können die noch nicht.

[Delphi.Narium]

Was bedeutet denn die Fehlermeldung error: 1409442E: SSL routines:ssl3_read_bytes:tlsv1 alert protocol version'?

Du scheinst eventuell eine Protokollversion zu nutzen, die der Server nicht unterstützt.

Prüfe doch bitte erstmal, ob das vom Server, auf dem die abzuholende Datei liegt, unterstützt wird.

Da kannst Du u. a. auf dieser Seite prüfen: https://www.ionos.de/tools/ssl-check

Schau dort bitte nach, was von TSL 1, TSL 1.1, TSL 1.2, SSLv 2, SSLv 3 unterstützt wird. Und eine der unterstützten Varianten konfigurierst Du in der entsprechenden Komponente.

Die Fehlermeldung besagt jedenfalls schonmal, dass die DLLs geladen wurden und prinzipiell funktionieren, nur (noch) nicht im konkreten Kontext.

[jaenicke]

Der SSL Fehler zeigt, dass die DLL zu alt ist. Konfiguriert werden muss das normalerweise nicht. Für die neuesten TLS-Versionen braucht man aber OpenSSL DLLs von 2018. Diese finden sich z.B. hier in fertig kompilierter Form:
https://indy.fulgan.com/SSL/

[Delphi.Narium]

Der Fehler ist aber mit den neuesten DLLs (aus https://www.delphipraxis.net/1421201-post70.html) aufgetreten.

Auch wenn man das normalerweise nicht konfigurieren muss, so kann es im Problemfall nicht schaden, wenn man 'ne TIdSSLIOHandlerSocketOpenSSL-Komponnete nutzt und bei der in SSLOptions.Method mal eine Methode konfiguriert, von der man weiß, dass sie unterstützt wird.

Immerhin haben wir hier ein sehr diffuses "Gehtnichmehrproblem", dann kann es nicht schaden, wenn man explizt die unterschiedlichen Möglichkeiten zur Fehlereingrenzung durchgeht, um konkret sagen zu können:

Beim dem bekomme ich diese Fehlermeldung.
Bei diesem jene ...

[NicoleWagner]

Danke für die Antworten:

Die Tool-Seite 'ionos' zeigt bei Eingabe des vertraulichen Links selbst es als tadellos an, cit:
SSL Zertifikat ist richtig installiert, 0 Warnungen, 0 Fehler.
Das Ziel sieht mir sauber also aus.

Was meine dll Dateien betrifft. Ich habe alle Versionen davon durch: 2013, 2017 zwei davon und 2018. Daran liegt es eher nicht.
Kann es sein, dass es nicht alle wären? Dass ich noch eine dll brauche, die noch fehlt?

Was genau bedeutet "SSL-Bibliothek kann nicht geladen werden'? Was sollte da passieren?

[Delphi.Narium]

Zitat:

Zitat von NicoleWagner (Beitrag 1421667)

Danke für die Antworten:

Die Tool-Seite 'ionos' zeigt bei Eingabe des vertraulichen Links selbst es als tadellos an, cit:
SSL Zertifikat ist richtig installiert, 0 Warnungen, 0 Fehler.
Das Ziel sieht mir sauber also aus.

Was meine dll Dateien betrifft. Ich habe alle Versionen davon durch: 2013, 2017 zwei davon und 2018. Daran liegt es eher nicht.
Kann es sein, dass es nicht alle wären? Dass ich noch eine dll brauche, die noch fehlt?

Was genau bedeutet "SSL-Bibliothek kann nicht geladen werden'? Was sollte da passieren?

Und was von diesen hier wird nun unterstützt?

TSL 1, TSL 1.1, TSL 1.2, SSLv 2, SSLv 3?

Der Fehler besagt:

Delphi-Quellcode:

error: 1409442E: SSL routines:ssl3_read_bytes:tlsv1 alert protocol version

Was ist mit den vier übrigen? Schon probiert, sofern sie unterstützt werden?

Bei einigen meiner Programme muss ich explizit die "richtige" Version angeben, damit Indy und der Server der Gegenseite sich unterhalten können.

Mein Vorschlag, eine der unterstützten Versionen explizit anzugeben, kommt nicht nur so aus dem Bauch.

Funktioniert ein Ping von der Kommandozeile auf den Server, der die PDF liefern soll?

DLL kann nicht geladen werden, bedeutet, dass sie nicht gefunden wird, dass eine Schnittstelle in ihr angesprochen wird, die sie nicht enthält ...

Die SSL-Dlls werden zwar immer aktuallisiert (wenn erforderlich), aber dass sie mit den Indykomponenten nicht geladen werden können, habe ich in den letzten (gefühlten Jahrzehnten) noch nicht erlebt.

Da Du aber eine Fehlermeldung der DLLs erhalten hast, kannst Du davon ausgehen, dass sie geladen wurden, andernfalls können sie keinen Protokollfehler ausgeben.

Und wenn Du schon alle Dir vorliegenden Versionen der DLLs "durchhast", kannst Du davon ausgehen, dass das Problem nicht in den Dlls liegt und auch nicht in der Kombination mit den Indykomponenten, sondern irgendwo anders.

Da andere Software ja auch nicht an die PDF kommt, liegt das Problem (vermutlich) sehr viel tiefer.

Mal als Vorschlag:

Eine neue Anwendung erstellen.
'ne TidHTTP-Komponente auf's Formular pappen.
Doppelklick auf's Formular.
Im erzeugten FormCreate ein paar Zeilen Quelltext einfügen:

Delphi-Quellcode:

procedure Form1.FormCreate(Sender: TObject);
begin
  ShowMessage(idHTTP1.Get('https://www.delphipraxis.net/'));
end;

Programm starten.

Was kommt dabei raus?

Inhalt von ShowMessage kann per Strg+C kopiert und hier zwischen Code-Tags eingefügt werden.

Alternativ als Screenshot hier anhängen.

[NicoleWagner]

So eine Komponente habe ich nicht. (Delphi XE 3)
Wenn ich die Komponenten in der Design-Zeit Ansicht listen lasse, so finde ich unter Internet lediglich: TWebBrowser.

Klingt nach einer heißen Spur.

TSL 1, TSL 1.1, TSL 1.2, SSLv 2, SSLv 3.... ich konnte das aus dem Link nicht ablesen.

[Delphi.Narium]

Zitat:

Zitat von NicoleWagner (Beitrag 1421667)

Die Tool-Seite 'ionos' zeigt bei Eingabe des vertraulichen Links selbst es als tadellos an, cit:
SSL Zertifikat ist richtig installiert, 0 Warnungen, 0 Fehler.

Kurz dadrunter gib's 'nen Button Details anzeigen.

Wenn man den anklickt, gibt es sehr detailreiche Informationen zur Seite.

Im Abschnitt Serverkonfiguration sind dann u. a. Aktive Protokolle zu finden.

Und was ist jetzt bitte aus dem Ping geworden, funktioniert das?

TIdHttp ist nicht unter Internet zu finden, sondern unter Indy-Clients. Und die waren schon unter Delphi 7 vorhanden. Würd' mich wundern, wenn Delphi XE3 die nicht kennt, ggfls. mal bei den Packages schauen, ob und was da so installiert ist.

[NicoleWagner]

jawoll, dort isse.
Ich hatte die ganze Indy-Sache ausgeblendet, daher fand es auch die Suche durch die Komponenten nicht.
Also die Komponente klebt jetzt, doch die Laufzeit will nocht nicht.

Ich kann damit auch so gar nicht umgehen, weil ich sie nie nutzte.
Ratlos lese ich bei dieser Zeile:
ShowMessage(idHTTP1.Get('https://www.delphipraxis.net/'));
=> 'Im Project_donwlad_Url ist eine Exception der Klasse EIdIOHandlerropInvelid mit der Meldung 'Wert für IOHander ist ungültig' aufgetreten.'


ad 'Details anzeigen' / berifft die andere Seite:
Dort kam ich entweder nicht weiter oder es standen dort Daten meines Partners, die ich hier nicht posten kann. Sein Zertifikat und Firmendaten etc.

Ich hoffe, wir kommen bei der Komponente weiter.


ad ping: es lässt sich die Domain anbingen, nicht jedoch die Datei selbst oder deren Oberverzeichnis. Doch das will nichts heißen, denke ich. Vom pingenden Rechner kann FF die Datei anzeigen. Also ist sie da.