ich versuche mich seit geraumer Zeit daran, die Autoarchivierung von Matomo zum Laufen zu bringen, leider bislang ohne Erfolg.
Ich betreibe eine Matomo-Installation auf einem SharedHosting von HostEurope. Dort kann ich Cronjobs (nur) über das Kundeninformationssystem ausführen. Daher bin ich wie unter „Web Cron When Your Web Host Does Not Support Cron Tasks“ beschrieben vorgegangen. Wenn ich im Browser jedoch die entsprechende URL http://example.org/path/to/piwik/misc/cron/archive.php?token_auth=XYZ aufrufe, erhalte ich folgende Fehlermeldung:
ERROR CoreAdminHome […] [8295e] Empty or invalid response 'Got invalid response from API request: https://[…]&trigger=archivephp&token_auth=removed. Response was 'curl_exec: SSL certificate problem: unable to get local issuer certificate. Hostname requested was: […]
Ich habe das nachgeschlagen, es wird empfohlen, in der php.ini einen Eintrag curl.cainfo – mit dem Ziel einer .pem-Datei zu ergänzen. Das ist mir bei meinem Webpaket so aber nicht möglich. Wer hat eine Idee?
Ich kann mir zwei Probleme vorstellen und beide liegen am Hoster.
Entweder HTTPS is bei dir nicht ganz richtig eingerichtet (intermediate certificates werden nicht mitgeschickt)
Das lässt sich leicht überprüfen, indem du die URL bei SSL Server Test (Powered by Qualys SSL Labs) überprüfst und nach Fehlermeldungen dort suchst.
Oder HTTPS ist richtig eingerichtet und die curl-version, die am Server läuft, glaubt, dass es trotzdem ungültig ist, da die vielleicht zu alt ist.
In beiden Fällen würde ich ne E-Mail an HostEurope schreiben und das erklären.
besten Dank für die ausführliche und das Problem eingrenzende Antwort!
Also, ich habe das Zertifikat überprüft. Ergebnis ist “B”, es kommt der Hinweis “Chain issues: Incomplete” sowie “Session resumption (caching): No (IDs assigned but not accepted)”. Kann es daran liegen? Oder vielleicht, dass meine Matomo-Istanz nicht als “Common name” sonder als “Alternative name” aufgeführt ist. (Ich verwende das Zertifikat für mehrere Subdomains.) Vermutlich müssten dann aber mehr Leute Probleme haben, oder?
Ich vermute daher erher den zweiten Ansatz, würde den ersten aber gerne möglichst weitgehend ausschließen …
Session resumption (caching): No (IDs assigned but not accepted) klingt recht unwichtig, aber Chain issues: Incomplete ist genau worauf ich hinauswollte.
Das ist egal, genau dafür gibt es die Funktion ja.
Wie du vermutlich weißt, gibt es root certifikate, die im Browser (oder Betriebsystem) mitgeliefert werden und denen immer vertraut wird.
Aber natürlich wird dein SSL-Zertifikat nicht direkt von dem root certfikat ausgestellt, sondern es gibt mehrere Zertifikate dazwischen die jeweils vom vorherigen signiert wurden.
Nun sollte man aber seinen Webserver konfigurieren, dass dieser dem Webseitenbesucher nicht nur das Zertifikat der Seite, sondern auch die anderen intermediate certificates senden. (also bei Let’s Encrypt die fullchain.pem und nicht die cert.pem verwenden)
Also solltest du dem Serverhost sagen, dass sie ihre SSL-config richtigstellen sollten.
Die Antwort kam schnell, war aber leider nicht zufriedenstellend:
Bitte haben Sie dafür Verständnis dass wir keinen Support für fremde Zertifikate leisten können und an von uns administrierten Systemen keine Systemänderungen vorgenommen werden können.
Hm, gibt es noch irgendein überzeugenden Argument, dass es nicht am Zertifikat sondern an der Serverkonfiguration liegt bzw. kann ich da noch etwas anderes testen?
Ich habe noch mal recherchiert. Auch andere haben bei Zertifikaten von Let’s Encrypt Probleme mit chain issues / intermediate certificates …
Ich habe daher noch mal bei HostEurope geschaut, dort kann man - etwas versteckt - ein Zwischenzertifikat angeben. Ich habe mir hier eines heruntergeladen und installiert.
Und siehe da: Zwar meldet der SSL-Tester noch immer „Chain issues: Incomplete“, dies aber nur noch für „Certificate #2“. (Ok, verstehe ich jetzt nicht zu 100%, aber egal …) Jedenfalls läuft jetzt der CURL-Befehl durch und das Skript endet mit Success:ok. JUHU.
