Ein Ausdruck des Beitrags mit 1 Antworten ergibt bei 3 Antworten pro Seite ca. 1 DIN A4 Seiten. Das entspricht bei 80 g/m² ca. 4.99 Gramm Papier.
-- Veröffentlicht durch ocinside am 10:43 am 1. Feb. 2023
Problem:
Nach einem Debian Distribution Upgrade oder libssl Update gibt curl die folgende Fehlermeldung aus:
curl: (18) server did not report OK, got 426.
Beschreibung:
Ist vielleicht etwas speziell, aber ich hatte trotz langer Suche keine Lösung für das Problem finden können, dass nach einem Distri Update auf einmal keine größeren Files mehr mit curl zu vsftpd, etc. via ssl übertragen werden konnten.
Die Datei wird mit curl --ssl -u ... zwar übertragen, allerdings meist nur zu ungefähr 99% und nicht zuverlässig mit 100% und das ist natürlich keineswegs wünschenswert.
Als Meldung gibt curl lediglich: curl: (18) server did not report OK, got 426 aus und im ausführlichen verbose output mit -v gibt es bei 426 noch den Hinweis "426 Data connection: No such file or directory.", aber das kann auch alles mögliche heißen ...
Lösung:
Nach einiger Fehlersuche gab es dann endlich einen Lichtblick (womit man sich so die Nächte um die Ohren schlägt), denn anscheinend mag TLSv1.3 nicht mit der libssl 1.1.1n bzw. OpenSSL 1.1.1n zusammenarbeiten, obwohl alles korrekt konfiguriert und TLSv1.3 natürlich in der nginx.conf etc. eingetragen ist und der TLS handshake zwischen Client und Server einwandfrei funktioniert.
Wie kann man aber nun die Übertragung von curl mit TLSv1.2 anstatt TLSv1.3 vorgeben:
Mit der Option --tlsv1.2 kann man in der neuen curl Version nur noch vorgeben, dass mindestens TLSv1.2 verwendet wird (--tlsv1.2 Use TLSv1.2 or greater) und nicht ausschließlich TLSv1.2.
Um das Problem zu umgehen kann man mit --tls-max 1.2 vorgeben, dass maximal TLSv1.2 verwendet wird, et voila, die Übertragung per curl --ssl --tls-max 1.2 -u ... funktioniert wie gewohnt stabil und ganz ohne Fehler bei der Dateiübertragung.
|