Websites haben keinen HTTP-Zugriff auf andere Websites

Prinzpiell ja, aber die Fehlermeldungen davor weisen eindeutig darauf hin, dass das Zertifikat der Webseite nicht überprüft werden konnte - und dann schlägt die Operation ja ebenfalls fehl. Außerdem würde es auch eine entsprechende Fehlermeldung im error-Log geben, wenn allow_url_fopen nicht aktiviert wäre. allow_url_fopen muss aktiviert sein, denn die Verbindung wurde ja aufgebaut und ist dann beim Zertifikat gescheitert - sonst wären wir nicht soweit gekommen. Außerdem wurde das weiter oben schon geprüft und ist aktiviert.
 
Ich würde erst mal prüfen warum die Zertifikatsprüfung fehl schlägt.
Wie alt die OpenSSL libs bei der PHP sind weiß ich nicht. Aber es wäre noch interessant was in den PHP-Variablen für die OpenSSL lib drin stent.
openssl.cafile
openssl.capath
 
Last edited:
Ich hab keine Ahnung wie bei deinem Uralt-Ubuntu die OpenSSL Libs und die Zertifikate aktuell sein können.

Ansonsten zu file_get_contents, es gibt da den Parameter context, der erlaubt für den stream Optionen zu setzen.
https://www.php.net/manual/en/function.file-get-contents.php

Ungetestets PHP:
Code: 
$contextOptions = array(
    'ssl' => array(
        'verify_peer' => true,
        'cafile' => '/etc/ssl/certs/cacert.pem',
        'CN_match' => 'fk-web.de', 
        'ciphers' => 'HIGH:!SSLv2:!SSLv3',
        'disable_compression' => true,
    )
);

$context = stream_context_create($contextOptions);

$xml = file_get_contents("https://fk-web.de/index.html", FALSE, $context);
 
Die Aktualität des "Uralt-Ubuntus" dürfte über den regulären Lifetime-Support seitens Cannonical gegeben sein:

... auch wenn LTS von Ubuntu sich nur auf die AFAIR Main-Repos bezieht, aber die Cert-Bundles sollten da hoffentlich drin enthalten sein.
 
marce said:
... auch wenn LTS von Ubuntu sich nur auf die AFAIR Main-Repos bezieht, aber die Cert-Bundles sollten da hoffentlich drin enthalten sein.
Click to expand...
Tja, nur sind fehlende oder zurückgezogene oder nicht mehr vertrauenswürdige Zertifikate keine Security-Bugs in dem Paket und somit wird das Paket definitiv nicht aktuell sein, LTS hin oder her...
 
Dann wäre *buntu in dem Bereich noch schlechter als befürchtet.

Bei den anderen LTS-Distris, die ich so kenne, erfahren die Cert-Bundles jedenfalls Updates.
 
Ubuntu ist ein wenig mit Vorsicht zu geniessen. Die 5 Jahre bei der LTS gelten nur für das Repo main (und mit Einschränkungen auch für das Repo restrikted), w#hrend der Support-Zeitraum für universe und multiverse nicht feststeht (nach meinem Empfinden: Hängt vom Paket-Maintainer ab). Letzteres wird aber kaum publik gemacht, obwohl diese beiden Repos sich sehr einfach z.B. in Synaptic aktivieren lassen.
Im Falle des Pakets ca-certificates hat es für das o.g. Ubuntu 16.04 im Sommer 2017 ein Update gegeben - das ist aber mit Security markiert, wobei das Changelog sich über die geschlossene Lücke ausschweigt und nur auf einen Backport von Ubuntu 17.10. verweist.
Aber es ist immer noch die Frage offen, ob der TE das Paket überhaupt installiert hat (schließlich wird es z.B. von openssl nicht zwingend vorausgesetzt) - das ist ja mit einem einfachen
Code: 
sudo apt-get install ca-certificates
innerhalb von zwei Minuten erledigt (entweder es wird installiert oder es kommt die Meldung, dass es schon installiert ist).
 
danton said:
Im Falle des Pakets ca-certificates hat es für das o.g. Ubuntu 16.04 im Sommer 2017 ein Update gegeben - das ist aber mit Security markiert, wobei das Changelog sich über die geschlossene Lücke ausschweigt und nur auf einen Backport von Ubuntu 17.10. verweist.
Aber es ist immer noch die Frage offen, ob der TE das Paket überhaupt installiert hat (schließlich wird es z.B. von openssl nicht zwingend vorausgesetzt) - das ist ja mit einem einfachen
Code: 
sudo apt-get install ca-certificates
innerhalb von zwei Minuten erledigt (entweder es wird installiert oder es kommt die Meldung, dass es schon installiert ist).
Click to expand...

Dieses Security Update ist installiert: "ca-certificates ist schon die neueste Version (20170717~16.04.2)."

GwenDragon said:
Ich würde erst mal prüfen warum die Zertifikatsprüfung fehl schlägt.
Wie alt die OpenSSL libs bei der PHP sind weiß ich nicht. Aber es wäre noch interessant was in den PHP-Variablen für die OpenSSL lib drin stent.
openssl.cafile
openssl.capath
Click to expand...

Dort stehen gar keine Werte drin.
 

Attachments

  • Unbenannt.jpg
    Unbenannt.jpg
    31.7 KB · Views: 151
Last edited:
Ich gehe mal davon aus, dass auch Ubuntu die CA-Certs aus Mozillas NSS verwendet und dort sind seit dem Release 3.31.0 vom 08.06.2017 etliche Zertifikate hinzugekommen, erneuert oder entfernt worden: https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport

Also selbst wenn Ubuntu nicht nur den Security-Bug gefixt hat, sondern auch die Certs aktualisiert hat, so ist das Paket dennoch hoffnungslos veraltet und das Validieren aktueller Zertifikate teilweise nicht möglich, wodurch dann Fehler wie beim TE nicht verwunderlich sind...


Es gibt halt viele gute Gründe gegen Binary-Distros und insbesondere deren LTS-Versionen, dies ist ein ganz erheblicher davon...
 
Auf Debian 9.9 klappt es mit SSL zu fkweb.

Sieht so aus als sei das Ubuntu des TE bezüglich Aktualität scheintot und nicht mehr brauchbar.
 
Sollte eigentlich nicht notwendig sein, denn bei mir sind die auch leer und es funktioniert trotzdem (allerdings Debian und nicht Ubuntu).
Bitte mal prüfen, ob in /etc/ssl/certs die Symlinks zu den Zertifikaten vorhanden sind. Falls nicht, mal mit
Code: 
sudo update-ca-certificates
neu generieren lassen.
 
motK said:
Kannst du mir sagen, wo ich den Pfad nachtagen kann?
Click to expand...
Schau in die deiner jeweiligen für die Domain verwendeten php.ini in z.B. /var/www/vhosts/system/DOMAIN.TLD/etc/
oder in der globalen php.ini deines mit Plesk installierten PHP /opt/plesk/php/VERSION/etc/.
In der php.ini ist ein Abschnitt openssl zu finden.
 
You must log in or register to reply here.
Back
Top