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!