cURL / PHP an einer REST API und die SSL Authentifikation.

[Rene K. (xdraconix)]

Ich bin gerade ein wenig am verzweifeln! :-D

Ich habe hier eine opnsense mit ntopng auf einem FreeBSD (als VM auf 
Proxmox) am laufen. Nun möchte ich die Rest API von ntopng nutzen. Das 
funktioniert auch soweit, allerdings sind einige Daten ausschließlich 
SSL Verschlüsselt (HTTPS) abrufbar.

Das alles ist ja soweit ganz gut. Auf dem Webserver (Debian 13 als 
Container auf Proxmox), auf dem ich die Daten abrufen mag funktioniert 
soweit auch alles, bis auf SSL.

Per bash funktioniert die Abfrage auf dem Webserver mit -k zum 
ignorieren der Authentifkation auch tadellos und er gibt das zu 
erwartende JSON aus.

draco@WebServer:~# curl -u user:pass -k "https://192.168.174.1:3090/lua/rest/v2/get/host/active.lua?ifid=1&sortColumn=thpt&sortOrder=desc&mode=local"

Auf der gleichen Maschine mit Apache2 als Webserver und php8.4 wirft mir 
curl mit der Verwendung der Optionen CURLOPT_SSL_VERIFYPEER und 
CURLOPT_SSL_VERIFYHOST auf false (Was ja das Equivalent zu -k ist) ein 
Fehler aus:

$ntopng_url = "https://192.168.174.1:3090/lua/rest/v2/get/host/active.lua?ifid=1&sortColumn=thpt&sortOrder=desc&mode=local";
$username = "user";
$password = "pass";

$curl = curl_init();

curl_setopt_array($curl, [
    CURLOPT_URL => $ntopng_url,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_USERPWD => "$username:$password",
    CURLOPT_SSL_VERIFYPEER => false,
    CURLOPT_SSL_VERIFYHOST => false,
    //CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2,
    //CURLOPT_SSL_CIPHER_LIST => "AES256+EECDH:AES256+EDH",
    CURLOPT_HTTPAUTH => CURLAUTH_BASIC,
]);

$response = curl_exec($curl);

if (curl_errno($curl)) {
    echo "cURL Fehler: " . curl_error($curl);
    exit;
}

// Stream schließen
curl_close($curl);

// JSON dekodieren
$data = json_decode($response, true);

// Ergebnis anzeigen
print_r($data);

?>

Der Fehler den das PHP Script bringt:

cURL Fehler: OpenSSL SSL_read: OpenSSL/3.5.4: error:0A000126:SSL routines::unexpected eof while reading, errno 0

Okay, dachte ich mir, probiere ich halt ein SSL Zertifikat aus und mache 
es "ordentlich". Aber da scheitere ich am Zertifikat. Wenn ich das 
Zerifikat des Servers übernehmen mag, dann schreit mich Curl an das es 
ein selbst Zertifiziertes ist und er dies nicht aktzeptiert.

Die Abfrage von curl -v auf dem opnsense Server sieht wie folg aus:

draco@WebServer:~# curl -v https://opnsense.home
* Host opnsense.home:443 was resolved.
* IPv6: (none)
* IPv4: 192.168.174.1, 192.168.178.4
*   Trying 192.168.174.1:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self-signed certificate in certificate chain
* closing connection #0
curl: (60) SSL certificate problem: self-signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

Auf dem opnsense Server habe ich ein Root-CA, ein Intermediate-CA und 
das Leaf-CA erstellt.

Wie bekomme ich Curl dazu diese Zertifikaten (oder das Root-CA) als 
Glaubwürdig zu erkennen?

Oder wie bekomme ich curl in php dazu die SSL Zertfizierung (wie curl 
über die bash) einfach zu ignorieren? Das System läuft sowieso nur 
intern und ist von außerhalb nicht zu erreichen.

Ich bin auf euer Schwarmwissen angwiesen :-D

[Roland P. (pram)]

SSL mit self signed Zertifikaten ist so ne Sache und erfordert viele 
Klimmzüge...

Tu dir einen Gefallen, besorg dir ein echtes Zertifikat.

Entweder kostenlos von letsencrypt. Da musst vielleicht ein bisschen 
basteln, dass die automatische Aktualisierung klappt, wenn das System 
von außen nicht erreichbar ist. Oder du kaufst dir eins, ggf sogar ein 
Wildcard. (und nach 2 Jahren den Wechsel nicht vergessen)

Du brauchst auf jeden Fall auch eine Domain wo du DNS Einträge anlegen 
kannst. Die kannst dann auch auf 10.x.x.x zeigen lassen.


Gruß Roland

[Richie (mikro123)]

Roland P. schrieb:
> SSL mit self signed Zertifikaten ist so ne Sache und erfordert viele
> Klimmzüge...

So ein Quark...

> Entweder kostenlos von letsencrypt. Da musst vielleicht ein bisschen
> basteln, dass die automatische Aktualisierung klappt, wenn das System

Ahso, Klimmzüge mit selfsigned, aber Basteln mit letsencrypt.
Prima Idee...


@Rene K.:

Kopier Deine selbst erstellten Zertifikate, z.B. das der Root CA von 
OpnSense auf Deinem Linux-System nach:
/usr/local/share/ca-certificates/
und ruf dann

update-ca-certificates

auf. Dann sollte es funktionieren.
Ebenso kannst Du natürlich Deine eigenen Zertifikate in Deine Browser 
importieren. Der akzeptiert die dann auch.
Ist echt nicht schwer und erfordert weder Klimmzüge noch Gebastel noch 
Geldausgeben.

[Alexander (alecxs)]

Warum hast Du CURL_SSLVERSION_TLSv1_2 auskommentiert...

[Fred F. (fred08151)]

Hier gab es die Frage auch schon:
https://unix.stackexchange.com/questions/451207/how-to-trust-self-signed-certificate-in-curl-command-line

[Mario M. (thelonging)]

Alexander schrieb:
> Warum hast Du CURL_SSLVERSION_TLSv1_2 auskommentiert...

Und warum CURLOPT_SSL_CIPHER_LIST? Wenn der Handshake fehlschlägt, ist 
genau die obige Fehlermeldung die Folge.

[Alexander (alecxs)]

Könnte man abschalten

CURLOPT_SSL_CIPHER_LIST => 'DEFAULT:@SECLEVEL=0',

[Gerd E. (robberknight)]

Roland P. schrieb:
> SSL mit self signed Zertifikaten ist so ne Sache und erfordert viele
> Klimmzüge...

So ein Quark.

> Tu dir einen Gefallen, besorg dir ein echtes Zertifikat.

Das funktioniert auch innerhalb eines lokalen Netzes für einen rein 
lokalen Hostnamen ganz toll...

> (und nach 2 Jahren den Wechsel nicht vergessen)

Mit dem Wissen aus dem letzten Jahrzehnt kommst Du heute nicht weiter 
und 2027 oder spätestens 2029 fällt Dir Dein ganzes Konzept kolossal auf 
die Füße.

@TO:

Entweder wie Richie geschrieben hatte das Cert Deines Servers im 
Betriebssystem installieren und dann update-ca-certificates.

Die andere Variante ist dass Du dieses eine Cert explizit im curl aus 
einer Datei lädst. Dafür packst Du das in etwa so in Dein setopt-array:

CURLOPT_CAINFO => "/pfad/servercert.pem",

Wenn Du es auf der Kommandozeile probierst, dann aktivierst Du diese 
Funktion mit dem "--cacert [file]"-Parameter.

[Harald K. (kirnbichler)]

Wenn curl auf der Kommandozeile funktioniert, aber in einem Programm 
eingebunden nicht, werden irgendwelche Optionen falsch gesetzt sein.

Praktischerweise bietet curl auf der Kommandozeile die Möglichkeit, 
passend zu genau dem jeweiligen Kommandozeilenaufruf C-Quelltext zu 
erzeugen, in dem die jeweiligen Optionen passend gesetzt sind.

Das sieht im wesentlichen so aus:

curl http://example.com --libcurl example.c

Für den Aufruf oben gibt es diesen Code hier:

/********* Sample code generated by the curl command line tool **********
 * All curl_easy_setopt() options are documented at:
 * https://curl.se/libcurl/c/curl_easy_setopt.html
 ************************************************************************/
#include <curl/curl.h>

int main(int argc, char *argv[])
{
  CURLcode ret;
  CURL *hnd;

  hnd = curl_easy_init();
  curl_easy_setopt(hnd, CURLOPT_BUFFERSIZE, 102400L);
  curl_easy_setopt(hnd, CURLOPT_URL, "https://192.168.174.1:3090/lua/rest/v2/get/host/active.lua\?ifid=1&sortColumn=thpt&sortOrder=desc&mode=local");
  curl_easy_setopt(hnd, CURLOPT_NOPROGRESS, 1L);
  curl_easy_setopt(hnd, CURLOPT_USERPWD, "user:pass");
  curl_easy_setopt(hnd, CURLOPT_USERAGENT, "curl/8.7.1");
  curl_easy_setopt(hnd, CURLOPT_MAXREDIRS, 50L);
  curl_easy_setopt(hnd, CURLOPT_HTTP_VERSION, (long)CURL_HTTP_VERSION_2TLS);
  curl_easy_setopt(hnd, CURLOPT_SSL_VERIFYPEER, 0L);
  curl_easy_setopt(hnd, CURLOPT_SSL_VERIFYHOST, 0L);
  curl_easy_setopt(hnd, CURLOPT_FTP_SKIP_PASV_IP, 1L);
  curl_easy_setopt(hnd, CURLOPT_TCP_KEEPALIVE, 1L);

  /* Here is a list of options the curl code used that cannot get generated
     as source easily. You may choose to either not use them or implement
     them yourself.

  CURLOPT_WRITEDATA was set to an object pointer
  CURLOPT_INTERLEAVEDATA was set to an object pointer
  CURLOPT_WRITEFUNCTION was set to a function pointer
  CURLOPT_READDATA was set to an object pointer
  CURLOPT_READFUNCTION was set to a function pointer
  CURLOPT_SEEKDATA was set to an object pointer
  CURLOPT_SEEKFUNCTION was set to a function pointer
  CURLOPT_ERRORBUFFER was set to an object pointer
  CURLOPT_STDERR was set to an object pointer
  CURLOPT_HEADERFUNCTION was set to a function pointer
  CURLOPT_HEADERDATA was set to an object pointer

  */

  ret = curl_easy_perform(hnd);

  curl_easy_cleanup(hnd);
  hnd = NULL;

  return (int)ret;
}
/**** End of sample code ****/

[Nemopuk (nemopuk)]

Rene K. schrieb:
> routines::unexpected eof while reading

Scheint mir anzudeuten, dass der Server die Verbindung abgebrochen. 
Schau in dessen Log, um den Grund dafür zu finden.

[Ein T. (ein_typ)]

Richie schrieb:
> Kopier Deine selbst erstellten Zertifikate, z.B. das der Root CA von
> OpnSense auf Deinem Linux-System nach:
> /usr/local/share/ca-certificates/
> und ruf dann
>

> update-ca-certificates
>

> auf. Dann sollte es funktionieren.
> Ebenso kannst Du natürlich Deine eigenen Zertifikate in Deine Browser
> importieren. Der akzeptiert die dann auch.
> Ist echt nicht schwer und erfordert weder Klimmzüge noch Gebastel noch
> Geldausgeben.

Das ist die einzige absolut richtige Antwort in diesem Thread, danke.

[Alexander (alecxs)]

Es waren aber zwei Fragen.

[Nemopuk (nemopuk)]

Ein T. schrieb:
> Das ist die einzige absolut richtige Antwort in diesem Thread, danke.

Sehe ich nicht so. Der TO möchte sein selbst erstelltes Zertifikat 
ungeprüft verwenden. Das ist bei SSL generell ein vorgesehenes 
Szenario und ich weiß mit Sicherheit, daß libcurl das auch kann.

Unabhängig davon möchte ich noch was zu gekauften Zertifikaten los 
werden:

Selbst erstellte Zertifikate müssen nicht zwingend unsicher sein, wenn 
man das Zertifikat auf anderem Weg prüft (z.B wie von Richie 
aufgezeigt). Manche machen es alternativ durch Kontrolle eines Hashes. 
In beiden Fällen ist man nicht gezwungen, Firmen zu vertrauen, die vom 
Verkauf der Zertifikate leben und denen man im Fall des Missbrauchs 
bestenfalls den Allerwertesten lecken darf.

[Rene K. (xdraconix)]

Mario M. schrieb:
> Alexander schrieb:
>> Warum hast Du CURL_SSLVERSION_TLSv1_2 auskommentiert...
>
> Und warum CURLOPT_SSL_CIPHER_LIST? Wenn der Handshake fehlschlägt, ist
> genau die obige Fehlermeldung die Folge.

Auch mit diesen zwei Optionen gibt es:

cURL Fehler: OpenSSL SSL_read: OpenSSL/3.5.4: error:0A000126:SSL routines::unexpected eof while reading, errno 0

Ein T. schrieb:
> Richie schrieb:
>> Kopier Deine selbst erstellten Zertifikate, z.B. das der Root CA von
>> OpnSense auf Deinem Linux-System nach:
>> /usr/local/share/ca-certificates/
>> und ruf dann
>>> update-ca-certificates
>>
>> auf. Dann sollte es funktionieren.
>> Ebenso kannst Du natürlich Deine eigenen Zertifikate in Deine Browser
>> importieren. Der akzeptiert die dann auch.
>> Ist echt nicht schwer und erfordert weder Klimmzüge noch Gebastel noch
>> Geldausgeben.
>
> Das ist die einzige absolut richtige Antwort in diesem Thread, danke.

Habe ich, also ich habe sowohl das root-CA, den Intermediate-CA und das 
Zertifikat als PEM Datei auf den Webserver (der mit Curl auf ntopng 
zugreifenn soll) in /usr/local/share/ca-certificates/ gezogen (0644 als 
Rechte) danach auf dem Webserver ein update-ca-certificates ausgeführt:

draco@WebServer:~# update-ca-certificates
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

Er hat quasi, keine neuen Zertifikate hinzugefügt. Auch ein Kopieren der 
Zertifikate in /etc/ssl/certs/ hat selbige Ausgabe.

Nemopuk schrieb:
> Rene K. schrieb:
>> routines::unexpected eof while reading
>
> Scheint mir anzudeuten, dass der Server die Verbindung abgebrochen.
> Schau in dessen Log, um den Grund dafür zu finden.

Mag sein, da dies aber eine Webanwendung ist (ntopng) habe ich keine 
Ahnung ob / wie und wo dort überhaupt Logs geschrieben werden.


Ich habe mir jetzt nochmal die Bash Ausgabe mit ... angeschaut:

curl -u user:pass -k "https://192.168.174.1:3090/lua/rest/v2/get/host/active.lua?ifid=1&sortColumn=thpt&sortOrder=desc&&perPage=5&mode=local"

Dort wird auch das zu erwartende Ergebnis gebracht... aaaaaber... mitten 
in der Ausgabe finde ich dann folgendes:

....
t":15},"last_seen":1765650726,"is_localhost":tcurl: (56) OpenSSL SSL_read: OpenSSL/3.5.4: error:0A000126:SSL routines::unexpected eof while reading, errno 0
rue,"bytes":{"total":584429356,"sent":21090170,"recvd":563339186},"is_broad
....

Der Datensatz geht dann weiter und es kommt dann irgendwann nochmalig 
genau das selbe. Bei mehreren Durchgängen ist der error:0A0000126 immer 
an Unterschiedlichen, nicht reproduzierbaren Stellen.

[Alexander (alecxs)]

Rene K. schrieb:
> Auch mit diesen zwei Optionen gibt es:

zeig mal

[Rene K. (xdraconix)]

Auf dem Hostsystem (opnsense) (funktioniert die Abfrage tadellos) sind 
folgende Versionen:

curl 8.17.0 (amd64-portbld-freebsd14.3) libcurl/8.17.0 OpenSSL/3.0.18

auf dem Webserver, der nicht funktioniert:

curl 8.14.1 (x86_64-pc-linux-gnu) libcurl/8.14.1 OpenSSL/3.5.4

auf einem weiteren Server, der funktioniert läuft folgende Version:

curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.17

Kann es sein das es da ein Problem mit der OpenSSL 3.5 gibt?!

[Rene K. (xdraconix)]

Alexander schrieb:
> Rene K. schrieb:
>> Auch mit diesen zwei Optionen gibt es:
>
> zeig mal

Was willst du denn da sehen?! Ich habe ein Bild angefügt.

[Alexander (alecxs)]

Ich wollte sehen ob Du Security level auf 0 gesetzt hast wie 
vorgeschlagen. Aber wurde schon mit OpenSSL 3.0.0+ auf SECLEVEL=2 
gehoben, also vor 3.0.17. Du könntest auch TLS 1.1/1.0 erzwingen.

[Bernd H. (geeky)]

Bei "unexpected eof" müsste man auf jedenfall eigentlich in den Logs des 
aufgerufenen Webservers schauen. Der hat die Verbindung vermutlich 
einfach geschlossen, sobald er gemerkt hat das man mit dem Client nicht 
auf einen gemeinsamen Nenner kommt.

ggf. kann man auch mit CURLOPT_VERBOSE+CURLOPT_STDERR noch an 
irgendetwas hilfreiches ran kommen.

Bei debian/ubuntu könnte man ggf. versuchen ob es ggf. mit den 
PHP-Paketen von sury statt den Debian-eigenen klappt:
https://deb.sury.org/
https://wiki.debian.org/AdditionalPHPVersions

[Rene K. (xdraconix)]

Aaaalso... ich habe mir nun fix einen Container mit Debian 11 
aufgesetzt. PHP7 und curl sowie openssl in folgenden Versionen:

curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1w

Damit funktioniert die Abfrage tadellos. Nach Recherchen ist dies 
tatsächlich ein Fehler seit OpenSSL 3. Diesen kann man zwar beheben in 
den man Curl, OpenSSL modifiziert und kompiliert - das kann ich aber 
nicht :-D

Für meine Zwecke reicht diese Kombination erstmal vollkommen aus.

[Alexander (alecxs)]

Das ist kein Bug das ist ein Feature. Was willst Du da modifizieren?

[Rene K. (xdraconix)]

Alexander schrieb:
> Das ist kein Bug das ist ein Feature.

Das ist kein Feature sondern ein Bug in Verbindung mit cURL / php-curl 
und ist bekannt:

https://github.com/openssl/openssl/discussions/22690

Alexander schrieb:
> Was willst Du da modifizieren?

OpenSSL via SSL_OP_IGNORE_UNEXPECTED_EOF mitteilen das er ein eof 
ignorieren soll, was aber nicht bei php-curl funktioniert, da dies ihre 
eigene Version mitbringt. Dann bleibt einem nur übrig php-curl / OpenSSL 
mit eben dieser Funktion neu zu kompilieren.

[Alexander (alecxs)]

Liest Du Dir auch durch was Du verlinkst? Da steht so ziemlich das 
Gegenteil!

[Ein T. (ein_typ)]

Nemopuk schrieb:
> Ein T. schrieb:
>> Das ist die einzige absolut richtige Antwort in diesem Thread, danke.
>
> Sehe ich nicht so. Der TO möchte sein selbst erstelltes Zertifikat
> ungeprüft verwenden.

Entschuldige, aber das ist nicht der Punkt. Der Punkt ist, daß der TO 
Daten von einem TLS-gesicherten Server abrufen möchte.

> Das ist bei SSL generell ein vorgesehenes Szenario

Das wiederum wäre mir neu, hast Du dazu eine Quelle?

> und ich weiß mit Sicherheit, daß libcurl das auch kann.

Ja, kann es. Nichtsdestotrotz halte ich es für ein No-Go, Benutzer dazu 
zu erziehen, TLS-Warnungen zu ignorieren oder TLS-Prüfungen zu 
deaktivieren.

[Ein T. (ein_typ)]

Rene K. schrieb:
> Habe ich, also ich habe sowohl das root-CA, den Intermediate-CA und das
> Zertifikat als PEM Datei auf den Webserver (der mit Curl auf ntopng
> zugreifenn soll) in /usr/local/share/ca-certificates/ gezogen (0644 als
> Rechte) danach auf dem Webserver ein update-ca-certificates ausgeführt:
>
>

> draco@WebServer:~# update-ca-certificates
> Updating certificates in /etc/ssl/certs...
> 0 added, 0 removed; done.
> Running hooks in /etc/ca-certificates/update.d...
> done.
>

Wenn das Zertifikat Deiner root-CA mit 0644 im PEM-Format vorliegt und 
seine Dateinamenerweiterung .crt ist und es trotzdem nicht klappt... 
merkwürdig.

[Gerd E. (robberknight)]

Ein T. schrieb:
>>

>> draco@WebServer:~# update-ca-certificates
>> Updating certificates in /etc/ssl/certs...
>> 0 added, 0 removed; done.
>> Running hooks in /etc/ca-certificates/update.d...
>> done.
>>

>
> Wenn das Zertifikat Deiner root-CA mit 0644 im PEM-Format vorliegt und
> seine Dateinamenerweiterung .crt ist und es trotzdem nicht klappt...
> merkwürdig.

Vielleicht hat er es mehrfach hintereinander aufgerufen und die Ausgabe 
eines der späteren Aufrufe gepostet. Das "added" kommt ja nur beim 
allerersten Aufruf wenn eine neue CA hinzukommt.

[Ein T. (ein_typ)]

Rene K. schrieb:
>

> cURL Fehler: OpenSSL SSL_read: OpenSSL/3.5.4: error:0A000126:SSL 
> routines::unexpected eof while reading, errno 0
>

NB: Diesen Fehler kenne ich eigentlich nur, wenn versucht wird, eine 
Seite mit TLS abzurufen, die kein TLS hat... seltsam das. Vielleicht mal 
mit tcpdump(8), dumpcap(1), sslsniff(8) oder Wireshark auf die 
Kommunikation schauen?

[Nemopuk (nemopuk)]

Ein T. schrieb:
> Nichtsdestotrotz halte ich es für ein No-Go, Benutzer dazu zu erziehen,
> ... TLS-Prüfungen zu deaktivieren.

Da bin ich bei dir. Sollte man nur im Notfall tun.

[Rene K. (xdraconix)]

Nemopuk schrieb:
> Ein T. schrieb:
>> Nichtsdestotrotz halte ich es für ein No-Go, Benutzer dazu zu erziehen,
>> ... TLS-Prüfungen zu deaktivieren.
>
> Da bin ich bei dir. Sollte man nur im Notfall tun.

Völlig korrekt, da bin ich vollkommen bei euch!

Da es sich hierbei aber nur um ein Test / kurzfristige Überwachung 
handelt. Dies nur intern ist, und kein Zugriff von außerhalb stattfinden 
kann sehe ich da aktuell keine Probleme dies über eine ungesicherte 
Verbindung laufen zu lassen (somal das eh für andere völlig irrelevante 
Daten wären).


Alexander schrieb:
> Liest Du Dir auch durch was Du verlinkst? Da steht so ziemlich das
> Gegenteil!

Lass einfach gut sein. Ich habe eine persönliche Abneigung gegen dich. 
Von dir möchte ich keine Ratschläge und auch keine Hilfe - Dankeschön.

[Ein T. (ein_typ)]

Rene K. schrieb:
> https://github.com/openssl/openssl/discussions/22690

Oh, spannend.

> Dann bleibt einem nur übrig php-curl / OpenSSL
> mit eben dieser Funktion neu zu kompilieren.

Das ist jedenfalls nicht schön. Wäre es nicht möglich, Deinen Client in 
einem Container laufen zu lassen? Darin kannst Du dann auch die alte 
Debian-Version 11 benutzen, mit der Du die Funktion erfolgreich getestet 
hast.

[Alexander (alecxs)]

Rene K. schrieb:
> Lass einfach gut sein. Ich habe eine persönliche Abneigung gegen dich.
> Von dir möchte ich keine Ratschläge und auch keine Hilfe - Dankeschön.

Komm mal runter von deinem hohen Ross und fang an zu lesen. Der 
Handshake schlägt fehl, daran ändert auch das Unterdrücken der eof 
Fehlermeldung nichts.

> - SSL_OP_IGNORE_UNEXPECTED_EOF
>
> Some TLS implementations do not send the mandatory close_notify alert on
> shutdown. If the application tries to wait for the close_notify alert
> but the peer closes the connection without sending it, an error is
> generated. When this option is enabled the peer does not need to send
> the close_notify alert and a closed connection will be treated as if the
> close_notify alert was received.
>
> You should only enable this option if the protocol running over TLS can
> detect a truncation attack itself, and that the application is checking
> for that truncation attack.
>
> For more information on shutting down a connection, see SSL_shutdown(3).

Du kannst den Handshake deaktivieren durch Herabsetzen des (mit 3.0.0+ 
angehobenen) Security levels und/oder Herabstufen der SSL version 
mittels Parameter in deinen auskommentierten curl Optionen.

CURLOPT_SSL_VERIFYPEER => false,
CURLOPT_SSL_VERIFYHOST => false,
CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_0,
CURLOPT_SSL_CIPHER_LIST => 'DEFAULT:@SECLEVEL=0',

Das wäre das Equivalent zu -k und die Antwort auf Deine 2. Frage 
gewesen, hättest ja einfach mal ausprobieren können würde Dir deine 
persönliche Abneigung nicht im Weg stehen.

Rene K. schrieb:
> Oder wie bekomme ich curl in php dazu die SSL Zertfizierung (wie curl
> über die bash) einfach zu ignorieren? Das System läuft sowieso nur
> intern und ist von außerhalb nicht zu erreichen.

[Roland P. (pram)]

Richie schrieb:
> Roland P. schrieb:
>> SSL mit self signed Zertifikaten ist so ne Sache und erfordert viele
>> Klimmzüge...
>
> So ein Quark...
>

Also der Verlauf des Threads zeigt mir was anderes...
Mit einem echten Zertifikat würde die Abfrage vermutlich schon 
funktionieren.

[Rene K. (xdraconix)]

Alexander schrieb:
> Du kannst den Handshake deaktivieren durch Herabsetzen des (mit 3.0.0+
> angehobenen) Security levels und/oder Herabstufen der SSL version
> mittels Parameter in deinen auskommentierten curl
> Optionen.CURLOPT_SSL_VERIFYPEER => false,
> CURLOPT_SSL_VERIFYHOST => false,
> CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_0,
> CURLOPT_SSL_CIPHER_LIST => 'DEFAULT:@SECLEVEL=0',
>
> Das wäre das Equivalent zu -k und die Antwort auf Deine 2. Frage
> gewesen, hättest ja einfach mal ausprobieren können würde Dir deine
> persönliche Abneigung nicht im Weg stehen.

Meine Gütem, echt... Nein! Man kann in php-curl den EOF Fehler nicht 
über eine CURLOPT weg bekommen. Und ja, natürlich habe ich das selbst 
schon probiert, selbst bevor DU mir das erzählt hast. Warum denkst du 
denn war das auskommentiert? Das war nen Copy&Paste - und ja auch da 
hatte ich den Security Level auf 0 gesetzt.

Bitte...! Bitte!!! Lass es einfach...

EDIT: Fehler.png ignorieren, war falsch hochgeladen. Fehler2.png 
beachten!

[Alexander (alecxs)]

Rene K. schrieb:
> Meine Gütem, echt... Nein! Man kann in php-curl den EOF Fehler nicht
> über eine CURLOPT weg bekommen.

SSL_OP_IGNORE_UNEXPECTED_EOF natürlich nicht - aber die Ursache 
beseitigen für den Abbruch. Und die kommt nun mal vom fehlschlagenden 
Handshake durch Inkompatibilität in den Versionen. Hast Du auch TLS alle 
Versionen durchgetestet, nicht nur 1.0?

[Ein T. (ein_typ)]

Roland P. schrieb:
> Also der Verlauf des Threads zeigt mir was anderes...
> Mit einem echten Zertifikat würde die Abfrage vermutlich schon
> funktionieren.

Aufgrund der Konflikte hinsichtlich close_notify zwischen den beiden 
OpenSSL-Versionen, die der oben beschriebene github-Link beschreibt, ist 
das leider eher unwahrscheinlich. Wenn die eine Seite ein close_notify 
erwartet und die andere die Verbindung ohne close_notify schließt, dann 
werden möglicherweise zwar die Daten korrekt übertragen, aber die 
Fehlermeldung wird es vermutlich trotzdem geben.

[Ein T. (ein_typ)]

Rene K. schrieb:
> Meine Gütem, echt... Nein! Man kann in php-curl den EOF Fehler nicht
> über eine CURLOPT weg bekommen.

Es ist nur so eine Idee, aber vielleicht funktioniert der Golang-Client 
im Anhang, schließlich ist das eine ganz andere TLS-Implementierung, und 
beim resp.Body.Close() werden eventuelle Fehler ignoriert.

Mit "docker compose create" im Wurzelverzeichnis des Archivs kannst Du 
einen Container "downloader-downloader-1" erzeugen, ohne die Go-Tools 
installieren zu müssen. Dann kannst Du mit "docker start -ai 
downloader-downloader-1" den Container starten -- oder mit "docker cp 
downloader-downloader-1:/otx ." das Executable "otx" aus dem erzeugten 
Container heraus kopieren.

[Oliver S. (oliverso)]

Eine alternative SSL-Implementierung aus einem Forum runterladen und 
installieren. Genau mein Humor ;)

Oliver

[Ein T. (ein_typ)]

Oliver S. schrieb:
> Eine alternative SSL-Implementierung aus einem Forum runterladen und
> installieren. Genau mein Humor ;)

Nichtmal reingeschaut, kleiner Held. Das wiederum genau mein Humor.

Die verwendete (und alternative) TLS-Implementierung ist -- Überraschung 
-- die aus den Standardlibraries von Golang, und zum Bauen wird das 
offizielle Golang-Image "golang:latest" vom Docker Hub benutzt.

Angelegentlich reden wir über 27 Zeilen Code in Golang, dazu ein 
Makefile, das Dockerfile zum Bauen eines Docker-Image, und eine 
compose.yml zum Erzeugen des Docker-Containers. Insgesamt reden wir über 
64 Zeilen Code, wenn die 10 Zeilen YAML in der compose.yml als Code 
durchgehen lassen wollen.

Vielen Dank für Deinen "klugen" "Beitrag". :-)