Jump to content
Froxlor Forum
  • 0

habe Probleme LE-Zertifikate zu beziehen


rseffner

Question

Hallo,

mit Einführung des begrüßenswerten LE-Supports in FROXLOR schien hier jede dritte Meldung damit zusammenhängen. Eigentlich wollte ich auf den Zug nicht auch noch aufspringen (müssen). Nun komme aber auch ich seit einigen Tagen nicht weiter.

cron führt regelmäßig den froxlor_master_cronjob mit dem Parameter --tasks aus und meldet dabei neuerdings ca. 1x am Tag:

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
/root/.acme.sh/acme.sh: Zeile 6310: gtar: Kommando nicht gefunden.
[Di 31. Mär 02:00:02 CEST 2020] Extraction error.
[Di 31. Mär 02:00:02 CEST 2020] Upgrade failed!

Schaut man sich die Zeile 6310 in der acme.sh an, wird klar, dass nicht das fehlende "gtar" das Problem ist, sondern offenbar ein korruptes Archiv, welches zuvor mittels "tar" versucht wird zu entpacken.

    if ! (tar xzf $localname || gtar xzf $localname); then

Auch ein manueller Aufruf des Task mit --force bleibt seit Tagen am Renew der gleichen Domains hängen.

ns2:~# /usr/bin/php7.3 -q /var/www/webs/its/FROXLOR_DOCROOT/scripts/froxlor_master_cronjob.php --tasks --force
[error] Could not get Let's Encrypt certificate for DOMAIN1.de:
[Di 31. Mär 12:46:08 CEST 2020] Renew: 'DOMAIN1.de'
[Di 31. Mär 12:46:08 CEST 2020] Skip, Next renewal time is: Di 26. Mai 08:20:23 UTC 2020
[Di 31. Mär 12:46:08 CEST 2020] Add '--force' to force to renew.
[error] Could not get Let's Encrypt certificate for DOMAIN2.de:
[Di 31. Mär 12:46:08 CEST 2020] Renew: 'DOMAIN2.de'
[Di 31. Mär 12:46:08 CEST 2020] Skip, Next renewal time is: Do 28. Mai 08:30:24 UTC 2020
[Di 31. Mär 12:46:08 CEST 2020] Add '--force' to force to renew.

Wie kann ich das Problem weiter zu seiner Ursache hin verfolgen? Welche Angaben sind für weitere Hilfe nötig? Am Start ist die 0.10.15 auf Debian Buster.

Danke fürs Lesen, Draufrumdenken und ggf. unterstützen.

  Ronny

Link to comment
Share on other sites

Recommended Posts

  • 0

Ich habe mal das acme.sh mit --renew und DOMAIN1.de ausgeführt, das ging problemlos.

ns1:~/.acme.sh# ./acme.sh -r -d DOMAIN1.de --force
[Di 31. Mär 13:10:37 CEST 2020] Renew: 'DOMAIN13.de'
[Di 31. Mär 13:10:37 CEST 2020] Creating domain key
[Di 31. Mär 13:10:38 CEST 2020] The domain key is here: /root/.acme.sh/DOMAIN1.de/DOMAIN1.de.key
[Di 31. Mär 13:10:38 CEST 2020] Multi domain='DNS:DOMAIN1.de,DNS:www.DOMAIN1.de'
[Di 31. Mär 13:10:39 CEST 2020] Getting domain auth token for each domain
[Di 31. Mär 13:10:42 CEST 2020] Getting webroot for domain='DOMAIN1.de'
[Di 31. Mär 13:10:42 CEST 2020] Getting webroot for domain='www.DOMAIN1.de'
[Di 31. Mär 13:10:42 CEST 2020] DOMAIN1.de is already verified, skip http-01.
[Di 31. Mär 13:10:42 CEST 2020] www.DOMAIN1.de is already verified, skip http-01.
[Di 31. Mär 13:10:42 CEST 2020] Verify finished, start to sign.
[Di 31. Mär 13:10:42 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/70743315/284201xxxx
[Di 31. Mär 13:10:44 CEST 2020] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/04cad67ea8430f8aaf05f4b2784axxxxxxxx
[Di 31. Mär 13:10:45 CEST 2020] Cert success.
-----BEGIN CERTIFICATE-----
MIIGdjCCBV6gAwIBAgISBMrWfqhDD4qvBfSyeEpsZ6IsMA0GCSqGSIb3DQEBCwUA
...
51LtN4Khp6c+z6j134QlCagAUF3OrYVVQyE=
-----END CERTIFICATE-----
[Di 31. Mär 13:10:45 CEST 2020] Your cert is in  /root/.acme.sh/DOMAIN1.de/DOMAIN1.de.cer
[Di 31. Mär 13:10:45 CEST 2020] Your cert key is in  /root/.acme.sh/DOMAIN1.de/DOMAIN1.de.key
[Di 31. Mär 13:10:45 CEST 2020] The intermediate CA cert is in  /root/.acme.sh/DOMAIN1.de/ca.cer
[Di 31. Mär 13:10:45 CEST 2020] And the full chain certs is there:  /root/.acme.sh/DOMAIN1.de/fullchain.cer

Habe ich jetzt ein Problem nur zu bestimmten Zeiten oder macht FROXLOR das Mithilfe der acme.sh in ganz anderen Verzeichnissen mit ganz anderen Parametern?

Link to comment
Share on other sites

  • 0

Ja ich bereu auch immer öfter auf acme.sh gesetzt zu haben und nicht bei der reinen API implementierung geblieben zu sein, irgendwie macht es bei vielen Leuten nur Probleme. Froxlor schaut ja nach ob acme.sh installiert ist und führt auch ggfls ein upgrade via acme.sh aus, damit das immer schön auf dem neuesten stand ist. Das schlug bei dir offenbar aus irgendeinem Grund fehlt. Wieso kann ich leider nicht sagen.

Zweiteres sehe ich leider immer öfter, konnte es allerdings selbst bei mir noch nie feststellen. Hier scheint es ggfls Abweichgungen der Zertifkate unterhalb von /root/.acme.sh/[domain] und denen in der froxlor Datenbank hinterlegten zu geben, so dass es für froxlor eigentlich vom Zeitstempel her ein renew geben sollte, acme.sh aber etwas anderes behauptet. Hier könntest du stichprobenartig bei einer Domain die Zertifikatsdaten aus den beiden Quellen mal vergleichen, sie sollten identisch sein

Link to comment
Share on other sites

  • 0
Just now, rseffner said:

Habe ich jetzt ein Problem

Ja, froxlor weiss nix von dem aktualisierten Zertifikat. Die Art der Implementierung ist hier noch nicht so wie ich sie haben will. Froxlor nimmt sich die Zertfikatsdateien nach dem issue/renew und legt sie in seiner datenbank ab, damit ich sie gleich behandeln kann wie nicht-lets-encrypt zertifikate. Führst du nun ein renew manuell ohne froxlor cron aus, bleibt eine Aktualisierung der Zertifikate in der Froxlor Datenbank aus und du hast unterschiedliche Datenstände

Link to comment
Share on other sites

  • 0
1 minute ago, d00p said:

Ja ich bereu auch immer öfter auf acme.sh gesetzt zu haben und nicht bei der reinen API implementierung geblieben zu sein, irgendwie macht es bei vielen Leuten nur Probleme. Froxlor schaut ja nach ob acme.sh installiert ist und führt auch ggfls ein upgrade via acme.sh aus, damit das immer schön auf dem neuesten stand ist. Das schlug bei dir offenbar aus irgendeinem Grund fehlt. Wieso kann ich leider nicht sagen.

Du vermutest also das Update/Upgrade von acme.sh itself? Das hat die Version und Checksumme, wie das gerade auf github.com verfügbare. Also irgendwann und irgendwie schein das Aktuellhalten auch mal zu funktionieren. Bis hierher habe ich den Eindruck, ich könnte die Cron-Meldungen, sofern sie nur vereinzelt auftauchen, einfach ignorieren.

Link to comment
Share on other sites

  • 0
2 minutes ago, d00p said:

Ja, froxlor weiss nix von dem aktualisierten Zertifikat. Die Art der Implementierung ist hier noch nicht so wie ich sie haben will. Froxlor nimmt sich die Zertfikatsdateien nach dem issue/renew und legt sie in seiner datenbank ab, damit ich sie gleich behandeln kann wie nicht-lets-encrypt zertifikate. Führst du nun ein renew manuell ohne froxlor cron aus, bleibt eine Aktualisierung der Zertifikate in der Froxlor Datenbank aus und du hast unterschiedliche Datenstände

Ok, dann habe ich es durch diesen einen händischen acme.sh-Aufruf schlimmer gemacht. Dafür gibt es ja zum Glück Backups. Und dann vergleiche ich mal Dateisystem mit FROXLOR-DB.

Link to comment
Share on other sites

  • 0
Just now, rseffner said:

Du vermutest also das Update/Upgrade von acme.sh itself?

Ja natürlich, von froxlor kommt das nicht, wir entpacken da nix, siehe https://github.com/Froxlor/Froxlor/blob/master/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php#L430

1 minute ago, rseffner said:

Bis hierher habe ich den Eindruck, ich könnte die Cron-Meldungen, sofern sie nur vereinzelt auftauchen, einfach ignorieren.

Sofern er dabei nicht acme.sh ansich irgendwie kaputtmacht oder nur halb aktualisiert ...je nachdem wie acme.sh's upgrade funktion funktioniert entpackt er das vllt zunächst temporär woanders - dann wär ja alles ok

Link to comment
Share on other sites

  • 0

Das acme.sh --upgrade meint gerade aktuell zu sein und kommt so im Code sicher nicht an die Stelle, wo es wohl sonst scheitert.

Die Inhalte der Zertifikatsdateien (die Version vor meinem Eingriff) im Filesystem und der FROXLOR-DB (panel_domains.id = domain_ssl_settings.domainid) unterscheiden sich bei der Beispieldomain. Kann ich da jetzt einfach aus dem Dateisystem die Inhalte in die DB kopieren um die Gültigkeit  an beiden Orten gleich zu haben? 

Die Stichprobe mit einer noch nicht in den Tasks zum renew geführten Domain zeigt diese Unterschied zwischen Dateisystem und DB aber auch. Ist das jetzt alles asyncron? Kann man FROXLOR "zwingen" sich nochmal am .acme.sh-Verzeichnis zu bedienen?

Link to comment
Share on other sites

  • 0
2 minutes ago, rseffner said:

Kann ich da jetzt einfach aus dem Dateisystem die Inhalte in die DB kopieren um die Gültigkeit  an beiden Orten gleich zu haben? 

Jap das sollte klappen

2 minutes ago, rseffner said:

Ist das jetzt alles asyncron?

Möglich ja

2 minutes ago, rseffner said:

Kann man FROXLOR "zwingen" sich nochmal am .acme.sh-Verzeichnis zu bedienen?

Leider nein, wie bereits gesagt ist da die Implementierung etwas anders - so ist es aber mein Plan für später, so dass froxlor sich nur noch aus dem acme.sh zeug bedient und auch acme.sh's Cronjob sich um das renew kümmern lässt etc. Ist nur leider bisher noch nicht soweit gekommen

Link to comment
Share on other sites

  • 0

Wenn du den entpackungsfehler meinst, dagegen können wir nichts tun. Muss wohl ein Fehler im Upgrade von acme.sh sein oder ähnliches. Ich arbeite schon an einer verbesserten Implementierung - aktuell ist es leider zeitlich sehr schwierig

Link to comment
Share on other sites

  • 0

Bei  mir liegt der ganze acme.sh Krempel unter /root/.acme.sh.

Da sind dann je (Sub-)Domain ein Ordner für die Zertifikate mit einer *.conf in der sich Le_CertCreateTime, Le_CertCreateTimeStr, Le_NextRenewTime und Le_NextRenewTimeStr befinden. Kommentiere ich diese 4 Zeilen aus und starte dann den froxlor_master_cronjob.php läuft die Zertifikatsbeschaffung ohne Fehler durch.

Soweit so gut - man könnte jetzt hoffen einen Zertifikatsasynchronität durch einmaliges Ändern der *.conf's zu beheben, weil dann FROXLOR wieder "gewinnt" mit seinem Request und Glauben an den Zertifikatsablauf.

Allerdings haut mir der Cronjob die eben erneuterten Zertifikate bei einer weitere Iteration wieder um die Ohren. Warum? Schaue ich in die SQL, sehe ich, dass dort noch immer eine "falsche" Expiration drinsteht. Kann es sein, dass wir hier einen Bug haben und die Daten von acme.sh gerade NICHT in die DB wandern bei renews?

Link to comment
Share on other sites

  • 0
2 hours ago, d00p said:

Froxlor aktualisiert nur die Zertifikate die laut der eigenen Datenbank renewed werden....habe ich doch gesagt, es gibt noch keinen Dateiabgleich und daran arbeite ich gerade.

Ich habe die Ursache für den, durch den cron-job angestoßenen renew, ja im Froxlor vermutet.
- in der DB steht, das Zertifikat läuft bald aus - es wird von FROXLOR der renew geplant
- da beim renew acme.sh aber merkt, dass sein Zertifikat noch längst nicht fällig wird verwehrt es den renew -> der Fehler, mit dem ich hier einstieg
= nun habe ich acme.sh um die Kenntnis der Gültigkeit beraubt und der renew durch FROXLOR-cron fand statt, in .acme/ liegt ein neues Zertifikat
? warum ist das nun nicht auch in der DB erneuert

Was verstehe ich hier falsch?

Link to comment
Share on other sites

  • 0
Just now, rseffner said:

- da beim renew acme.sh aber merkt, dass sein Zertifikat noch längst nicht fällig wird verwehrt es den renew -> der Fehler, mit dem ich hier einstieg

DAS wiederrum liegt aber daran, dass offenbar andere Zertifikate auf dem Dateisystem in /root/.acme.sh/ liegen als froxlor bekannt sind 

1 minute ago, rseffner said:

? warum ist das nun nicht auch in der DB erneuert

wenn der normale cronlauf die zertifikate via acme.sh macht, dann übernimmt froxlor die auch in der datenbank. Hilfreich wäre hier mal die ausgabe des crons mit --force --debug parametern

Link to comment
Share on other sites

  • 0

@rseffner habe das nun alles etwas umgebaut und neu strukturiert und auch funktionalität hinzugefügt, um Dateisystem mit froxlor-datenbank zu synchronisieren (cron mit --force), wenn du das testen möchtest (db backup solltest du haben falls...) kannst du die Datei /lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php mit folgender ersetzen (ein diff wär zu groß und unübersichtlich hier im forum):

 

Feedback, gerne :)

Edited by d00p
removed older version of files
Link to comment
Share on other sites

  • 0
3 hours ago, d00p said:

Feedback, gerne :)

Danke für Deine Mühen.

root@ns2:~# /usr/bin/php7.3 -q /var/www/webs/its/froxlor.DOMAIN.de/scripts/froxlor_master_cronjob.php --tasks --force
[error] Could not get Let's Encrypt certificate for bam-****.de:

[error] Could not get Let's Encrypt certificate for angl****.de:

[error] Could not get Let's Encrypt certificate for anti****.de:

....

Rechte? Wobei das php als root lief.

Link to comment
Share on other sites

  • 0
root@ns2:~# /usr/bin/php7.3 -q /var/www/webs/its/froxlor.DOAMIN.de/scripts/froxlor_master_cronjob.php --force --debug
...
[information] Running Let's Encrypt cronjob prior to regenerating webserver config files
[error] Could not get Let's Encrypt certificate for bam-****.de:

[error] Could not get Let's Encrypt certificate for angl****.de:
...
[information] Let's Encrypt certificates have been updated
[information] apache::createIpPort: creating ip/port settings for  xxx.xxx.xxx.xxx:80

Ich nahm an --force ist ein weiterer Parameter zu --tasks. Leider ist die Ausgabe mit --debug an der gesuchten Stelle um keinen Deut umfangreicher.

Link to comment
Share on other sites

  • 0

Dann sind das aber keine neuen Zertifikate oder? Denn sonst gäbe es ja eine ausgabe von acme.sh, normal kommt die meldung wenn kein zertifikat vom dateisystem gelesen wurde.

Ich habe hier die entsprechende Ausgabe hinzugefügt, es sollte helfen die Fehler zu finden

 

Edited by d00p
removed old file
Link to comment
Share on other sites

  • 0

Auch die neue Version ändert an der Ausgabe nichts.

Eine Stichprobe meint zum Zertifikat in /root/.acme CreateTimeStr="Fr 3. Apr ..." bzw. NextRenewTimeStr="Mi 2. Jun ..." und in der DB als expiration="2020-04-26 09:10:21".

Ich weiß ja nicht was Dein Code tun soll, aber in der DB sind noch immer andere Zertifikate wie im Dateisystem.

Link to comment
Share on other sites

  • 0

Ein zweiter Server mit FROXLOR 0.10.15

ns1:~# /usr/bin/php7.3 -q /var/www/webs/its/froxlor.DOMAIN.de/scripts/froxlor_master_cronjob.php --tasks
[error] Could not get Let's Encrypt certificate for a.mein****.de:
[Sa 4. Apr 13:51:20 CEST 2020] Renew: 'a.mein****.de'
[Sa 4. Apr 13:51:20 CEST 2020] Skip, Next renewal time is: Mi 3. Jun 11:45:17 UTC 2020
[Sa 4. Apr 13:51:20 CEST 2020] Add '--force' to force to renew.

Und nun die ausgetauschte Datei und der cronjob mit --force --debug

...
[error] Could not get Let's Encrypt certificate for sola****.de:

[error] Could not get Let's Encrypt certificate for 2019.seff****.de:

[error] Could not get Let's Encrypt certificate for a.mein****.de:

[error] Could not get Let's Encrypt certificate for prof****.at:
...

Im Filesystem Renew auf 26.05. in der DB expiration auf 27.06 - das kann ja passen - ich glaube renew beginnt einen Monat vor Ablauf.

Link to comment
Share on other sites

  • 0

Mit der aktuellen AcmeSh.php hat froxlor nix mehr mit dem renew zu tun, das macht alles acme.sh mittels cronjob selbst. Froxlor gleich nur noch Filesystem mit seiner Datenbank ab. 

So, und wenn du tatsächlich die aktuelle AcmeSh.php von mir hier aus dem Forum benutzt, dann sollte DEFINITIV vor der "Could not get ...." Meldung eine "Could not find file..." Meldung kommen. Es sei denn da ist bei dir was so grundlegend falsch gelaufen, dass es nicht mal den Ordner der Domain gibt, was du aber widerlegst mit der Meldung der "alten" implementierung, dass acme.sh nämlich sagt, er kennt die domain ...

Link to comment
Share on other sites

  • 0
root@ns1 ~/.acme.sh/a.mein****.de # ls -la /root/.acme.sh/a.mein****.de/
insgesamt 36
drwxr-xr-x  2 root root 4096 Jan 27 12:05 .
drwx------ 73 root root 4096 Apr  4 13:45 ..
-rw-r--r--  1 root root 2301 Mär 27 12:15 a.mein****.de.cer
-rw-r--r--  1 root root  652 Mär 27 12:15 a.mein****.de.conf
-rw-r--r--  1 root root 1716 Mär 27 12:15 a.mein****.de.csr
-rw-r--r--  1 root root  242 Mär 27 12:15 a.mein****.de.csr.conf
-rw-r--r--  1 root root 3247 Mär 27 12:15 a.mein****.de.key
-rw-r--r--  1 root root 1648 Mär 27 12:15 ca.cer
-rw-r--r--  1 root root 3949 Mär 27 12:15 fullchain.cer
root@ns1 ~/.acme.sh/a.mein****.de # md5sum /var/www/webs/its/froxlor.DOMAIN.de/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php
59e6855a72207abc330d52db41368489  /var/www/webs/its/froxlor.DOMAIN.de/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php
root@ns1 ~/.acme.sh/a.mein****.de #

Ich verstehe, das solch remotes debugging extrem anstrengend ist - drum gebe ich mir ja alle Mühe, Dir keinen Mist zu liefern.

Link to comment
Share on other sites

  • 0

ich kann dir halt auch nur sagen wie es der code macht, mit --force wird ein abgleich von dateisystem und datenbank vorgenommen; du erhälst fehlermeldungen die laut code eine von zwei dingen bedeutetn: entweder gibt es den ordner nicht, oder es gibt die erwartete .cer Datei nicht. Hast du evtl. zu einem späteren zeitpunkt ECC aktiviert? Dann würde froxlor davon ausgehen dass die daten in /root/.acme.sh/a.mein****.de_ecc/ liegen....

Link to comment
Share on other sites

  • 0
4 minutes ago, d00p said:

Hast du evtl. zu einem späteren zeitpunkt ECC aktiviert? Dann würde froxlor davon ausgehen dass die daten in /root/.acme.sh/a.mein****.de_ecc/ liegen....

DAS ist, was ich gemacht habe, bevor das mit den Fehlern losging.

Wie sieht jetzt Deine Handlungsempfehlung aus?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...