Jump to content
Froxlor Forum
  • 0

acme holt keine neuen Zertifikate von Letsencrypt - Froxlor 0.10.34.1


Question

Posted

Bis dato gab es nie Probleme mit Letsencrypt und Froxlor. Ich habe zwei Server mit Froxlor laufen, es werden praktisch ständig Zertifikate erneuert. Die Ursache des Problems kann also nicht Monate alt sein. Symptom:

In den Froxlor Logs taucht auf

[Do 5. Mai 00:07:10 CEST 2022] Please add '--debug' or '--log' to check more details.
[Do 5. Mai 00:07:10 CEST 2022] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
[Do 5. Mai 00:07:10 CEST 2022] Error renew mydomain1.xxx.
[Do 5. Mai 00:07:15 CEST 2022] Please add '--debug' or '--log' to check more details.
[Do 5. Mai 00:07:15 CEST 2022] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
[Do 5. Mai 00:07:15 CEST 2022] Error renew mydomain2.xxx.

Also habe ich mal geschaut was der manuelle acme-Lauf ergibt und finde da folgendes:

...
[Do 5. Mai 06:59:35 CEST 2022] Using CA: https://acme.zerossl.com/v2/DV90
[Do 5. Mai 06:59:35 CEST 2022] No EAB credentials found for ZeroSSL, let's get one
[Do 5. Mai 06:59:35 CEST 2022] acme.sh is using ZeroSSL as default CA now.
[Do 5. Mai 06:59:35 CEST 2022] Please update your account with an email address first.
[Do 5. Mai 06:59:35 CEST 2022] acme.sh --register-account -m my@example.com
[Do 5. Mai 06:59:35 CEST 2022] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA
[Do 5. Mai 06:59:35 CEST 2022] Please add '--debug' or '--log' to check more details.
[Do 5. Mai 06:59:35 CEST 2022] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
[Do 5. Mai 06:59:35 CEST 2022] Error renew mydomain1.xxx.
...

Mit --debug sieht das so aus:

...
[Do 5. Mai 08:08:35 CEST 2022] config file is empty, can not read CA_KEY_HASH
[Do 5. Mai 08:08:35 CEST 2022] Using config home:/root/.acme.sh
[Do 5. Mai 08:08:35 CEST 2022] ACME_DIRECTORY='https://acme.zerossl.com/v2/DV90'
[Do 5. Mai 08:08:35 CEST 2022] _init api for server: https://acme.zerossl.com/v2/DV90
[Do 5. Mai 08:08:35 CEST 2022] RSA key
[Do 5. Mai 08:08:35 CEST 2022] config file is empty, can not read CA_EAB_KEY_ID
[Do 5. Mai 08:08:35 CEST 2022] config file is empty, can not read CA_EAB_HMAC_KEY
[Do 5. Mai 08:08:35 CEST 2022] config file is empty, can not read CA_EMAIL
[Do 5. Mai 08:08:35 CEST 2022] No EAB credentials found for ZeroSSL, let's get one
...

 

Gibt es da was neues? Muss ich mich bei Letsencrypt irgendwie neu legitimieren? Das taucht wie gesagt bei zwei unabhängigen Servern auf...

Recommended Posts

  • 0
Posted

Das acme.sh laut deiner Meldung jetzt ZeroSSL als default CA nutzt ist ja nichts neues, Froxlor setzt den Server beim issue command explizit auf das in der einstellung gesetzte (default lets encrypt).

Obwohl überall explizit Let's Encrypt angegeben ist, habe ich diese Meldung auch schon gesehen. Der Befehl zum Registrieren des Accounts schlägt fehl (Can not resolve _eab_id). Lösche ich das Zertifikat und lasse es via cron neuerstellen funktioniert das wunderbar. Nicht vergessen, dass froxlor mit dem cron auch ggfls acme.sh aktualisiert (acme.sh --upgrade)

Es wurde schon öfter erkannt das acme.sh hier auf https://github.com/acmesh-official/acme.sh/archive/master.tar.gz zurückgreift und nicht auf den neuesten Release o.Ä. (der übrigens vor ~19 Stunden erst war, version 3.0.3).

Ich kann nur schätzen, dass es hier vllt tatsächlich um einen Fehler in acme.sh handelte, weil mit ZeroSSL habe ich pers. auf meinen Server nichts zu tun, es ist alles explizit auf letsencrypt gesetzt

  • 0
Posted

/root/.acme.sh/acme.sh --version zeigt bei mir:

/root/.acme.sh/acme.sh --version
https://github.com/acmesh-official/acme.sh
v3.0.3

Die Fehlermeldung wegen der nicht erneuerten Zertifikate habe ich schon seit ein paar Tagen (länger als das letzte Update von acme). Ich habe mir die ersten drei Tage nichts daraus gemacht - ab und an hakt etwas wegen Netzwerkproblemen und Timeouts - kein Grund zur Sorge. Diesmal ist ie Ursache aber definitiv kein Timeout.

  • 0
Posted

Ist dennoch keine froxlor Sache - zumindest nicht das ich nachvollziehen könnte. Wir führen im grunde nur ein issue aus, das renew macht acme.sh selbst und froxlor gleicht die dateien nur ab

  • 0
Posted

Das hatte ich auch so gesehen. Sollte es aber ein Problem von acme sein dürften ja mehr User von Froxlor betroffen sein und hier könnten weitere Reports aufschlagen. Die betreffenden Zertifikate laufen noch 1 Monat - ich werde das erstmal weiter beobachten.

  • 0
Posted

Weitere Ergebnisse:

Es waren 5 Domains verteilt auf die zwei Server betroffen. Die letzten erfolgreichen Zertifikatserneuerungen waren am 30.04.

Ich habe die 5 Domains jetzt mit

acme.sh --renew -d mydomain1.xxx --server letsencrypt
acme.sh --renew -d mydomain2.xxx --server letsencrypt
...

erneuert: das lief ohne Fehler durch. Woher bekommt acme die Information dass es letsencrypt benutzen soll? Denn daran scheint es zu haken.

  • 0
Posted

hmmmm.... Die Einstellungen sind nach wie vor alle korrekt. Ich ging bislang davon aus dass das zwei verschiedene Mechanismen sind:

1) acme pflegt die Zertifikate autark in /root/.acme.sh/ mit Hilfe des cron-Jobs von root.

2) Froxlor kopiert eventuell neu geholte Zertifikate um

 

Ich habe in der Crontab von root geschaut - da steht ein Standardaufruf von acme.sh drin. Woher weiß dieser Standardaufruf dass er nicht zerossl benutzen soll? Oder ist der root-acme-Cronjob obsolet/kontraproduktiv und Froxlor kaskadiert einen selbst initialisierten acme-Lauf mit seinem Teil der Zertifikatsübernahme?

  • 0
Posted
Just now, df8oe said:

1) acme pflegt die Zertifikate autark in /root/.acme.sh/ mit Hilfe des cron-Jobs von root.

2) Froxlor kopiert eventuell neu geholte Zertifikate um

Das ist im Grunde so ja, froxlor ruft acme.sh auf für ein ISSUE bzw. beim cleanup/remove. sonst macht acme.sh da alles autark (renew mittels eigenem cronjob)
Froxlor gleicht dann lediglich die Zertifikate in /root/.acme.sh/ mit denen die er in der Datenbank hat ab

2 minutes ago, df8oe said:

Woher weiß dieser Standardaufruf dass er nicht zerossl benutzen soll?

weil der ein renew-all macht und dann pro certificate in die certificate-config schaut

2 minutes ago, df8oe said:

Oder ist der root-acme-Cronjob obsolet/kontraproduktiv und Froxlor kaskadiert einen selbst initialisierten acme-Lauf mit seinem Teil der Zertifikatsübernahme?

nein, der macht die renews, der ist nicht obsolet oder kontraproduktiv, froxlor selbst macht KEINE renew aufrufe

  • 0
Posted
2 minutes ago, d00p said:

weil der ein renew-all macht und dann pro certificate in die certificate-config schaut

Danke - der Anker führt mich weiter! Ich schaue mir mal die certificate-configs an.

  • 0
Posted

Hier bei mir habe ich dasselbe Problem. In den Froxlor-Einstellungen steht alles wie gehabt schön brav auf "letsencrypt" (zur Sicherheit auch in der DB panel_settings['letsencryptca'] geprüft).

In den .conf Dateien der betroffenen Domains unter /root/acme.sh steht nun allerdings abweichend zu allen anderen bei Le_API "zerossl" drin. Wie kann ich das wieder korrigieren bzw. von wem werden denn diese conf-Files geschrieben?
Vom Froxlor-Cronjob oder vom acme.sh-Cronjob? Dem Zeitstempel nach eher von zweitem...

  • 0
Posted

die config erstellt acme.sh beim issue-command den froxlor mit explizitem server auruft...kann also nur wiederholen und vermuten das acme.sh selbst da irgendeinen fehler drin hat/hatte der dort nicht den endpoint einträgt der es sein soll

  • 0
Posted

Auf einigen meiner Server steht es korrekt in den configs wie froxlor es beim anlegen auch übergibt:
 

Le_API='https://acme-v02.api.letsencrypt.org/directory'

 

  • 0
Posted

Kann ich bestätigen - irgendwas (ich kann nicht sagen was) hat zerossl in die jeweiligen .conf Dateien geschrieben. Bei den letzten Domains die ich vor ca. 4 Wochen angelegt habe ist es vorgekommen. Nach dem Löschen und Neuanlegen der Zertifikate ging es wieder mit LE.

  • 0
Posted

Selbst wenn man in den .confs der betroffenen und für ein Renewal ausstehenden Domains Le_API wieder auf 'https://acme-v02.api.letsencrypt.org/directory' ändert, macht der acme.sh-Cronjob diese bei seinem nächsten Lauf wieder kaputt.

Momentan scheint also nur zu bleiben, wie df8oe geschrieben hat, den Aufruf für renew manuell mit --server auszuführen oder die Zertifkate Löschen und Neuanlegen zu lassen (bis sie halt das nächste Mal fällig sind und der Fehler in acme.sh noch nicht gefixt sein sollte).

  • 0
Posted

Man kann auch die Default CA von acme.sh setzen, dann funktioniert das --renew-all auch ohne löschen der Zertifikate oder manuellem anpassen der configs:

achtung, 'letsencrypt' natürlich nur setzen, wenn das auch in den Einstellungen genutzt wird [default], sonst natürlich entsprechend der gewählten CA anpassen

/root/.acme.sh/acme.sh --set-default-ca --server letsencrypt

 

  • 0
Posted

Ich bin mir inzwischen nicht mehr sicher ob der Fehler wirklich bei acme liegt. Ich habe auf meinen Servern nach dem letzten Problem geschaut ob in irgendeiner conf noch zerossl steht: nein, da stand überall letsencrypt - und das seit dem 5.Mai. Heute morgen bekomme ich wieder mit dass nun bei sieben Domains wieder zerossl drinsteht und der renew fehlschlägt... Die confs wurde gestern morgen um 00:07 neu geschrieben - dabei ist es passiert. Die Meldung vom Froxlor-Cronjob dass das Renew fehlgeschlagen ist datiert von heute 00:07. Ist es ein Zufall dass die Änderungen an den confs beim Froxlor-cron-Lauf um 00:07 gestern geschahen - und exakt um die gleiche Zeit am nächsten Tag können deswegen keine Zertifikate erneuert werden? Für mich ist die Wahrscheinlichkeit hoch dass Froxlor selbst bei seinem cron-Lauf gestern die confs neu geschrieben hat - und dabei ist be denen wo die Zertifikate erneuert werden sollen zerossl reingekommen. Bei allen anderen confs (bei denen die Zertifikate noch länger gültig sind) ist nichts böses passiert.

  • 0
Posted

Aber vielleicht triggert er das Schreiben? Ich finde die Tatsache dass das Modifikationsdatum der conf-Dateien exakt mit dem Werfen der Cron-Mail 24 Stunden später übereinstimmt eigenartig.

  • 0
Posted

Ergänzung: der Cronjob von acme läuft um 00:07... Damit ist die Sache mit der Wahrscheinlichkeit wieder obsolet. Vielmehr sieht es jetzt so aus als wenn acme die in der conf vorhandene Einstellung für Le_API mit zerossl überschreibt. Vielleicht hilft ja das Log von dem Cron-Lauf bei dem die Config neu (falsch) geschrieben wurde: 

[Sa 14. Mai 00:07:06 CEST 2022] di='/root/.acme.sh/domain.xyz/'
[Sa 14. Mai 00:07:06 CEST 2022] d='domain.xyz'
[Sa 14. Mai 00:07:06 CEST 2022] Using config home:/root/.acme.sh
[Sa 14. Mai 00:07:06 CEST 2022] ACME_DIRECTORY='https://acme.zerossl.com/v2/DV90'
[Sa 14. Mai 00:07:06 CEST 2022] DOMAIN_PATH='/root/.acme.sh/domain.xyz'
[Sa 14. Mai 00:07:06 CEST 2022] Renew: 'domain.xyz'
[Sa 14. Mai 00:07:06 CEST 2022] Le_API='https://acme-v02.api.letsencrypt.org/directory'
[Sa 14. Mai 00:07:06 CEST 2022] Using config home:/root/.acme.sh
[Sa 14. Mai 00:07:06 CEST 2022] ACME_DIRECTORY='https://acme.zerossl.com/v2/DV90'
[Sa 14. Mai 00:07:06 CEST 2022] _main_domain='domain.xyz'
[Sa 14. Mai 00:07:06 CEST 2022] _alt_domains='www.domain.xyz'
[Sa 14. Mai 00:07:06 CEST 2022] Le_NextRenewTime='1652396849'
[Sa 14. Mai 00:07:06 CEST 2022] Using ACME_DIRECTORY: https://acme.zerossl.com/v2/DV90
[Sa 14. Mai 00:07:06 CEST 2022] _init api for server: https://acme.zerossl.com/v2/DV90
[Sa 14. Mai 00:07:06 CEST 2022] GET
[Sa 14. Mai 00:07:06 CEST 2022] url='https://acme.zerossl.com/v2/DV90'
[Sa 14. Mai 00:07:06 CEST 2022] timeout=
[Sa 14. Mai 00:07:06 CEST 2022] _CURL='curl --silent --dump-header /root/.acme.sh/http.header  -L '
[Sa 14. Mai 00:07:10 CEST 2022] ret='0'
[Sa 14. Mai 00:07:10 CEST 2022] ACME_KEY_CHANGE='https://acme.zerossl.com/v2/DV90/keyChange'
[Sa 14. Mai 00:07:10 CEST 2022] ACME_NEW_AUTHZ
[Sa 14. Mai 00:07:10 CEST 2022] ACME_NEW_ORDER='https://acme.zerossl.com/v2/DV90/newOrder'
[Sa 14. Mai 00:07:10 CEST 2022] ACME_NEW_ACCOUNT='https://acme.zerossl.com/v2/DV90/newAccount'
[Sa 14. Mai 00:07:10 CEST 2022] ACME_REVOKE_CERT='https://acme.zerossl.com/v2/DV90/revokeCert'
[Sa 14. Mai 00:07:10 CEST 2022] ACME_AGREEMENT='https://secure.trust-provider.com/repository/docs/Legacy/20201020_Certificate_Subscriber_Agreement_v_2_4_click.pdf'
[Sa 14. Mai 00:07:10 CEST 2022] ACME_NEW_NONCE='https://acme.zerossl.com/v2/DV90/newNonce'
[Sa 14. Mai 00:07:11 CEST 2022] Using CA: https://acme.zerossl.com/v2/DV90
[Sa 14. Mai 00:07:11 CEST 2022] _on_before_issue
[Sa 14. Mai 00:07:11 CEST 2022] _chk_main_domain='domain.xyz'
[Sa 14. Mai 00:07:11 CEST 2022] _chk_alt_domains='www.domain.xyz'
[Sa 14. Mai 00:07:11 CEST 2022] Le_LocalAddress
[Sa 14. Mai 00:07:11 CEST 2022] d='domain.xyz'
[Sa 14. Mai 00:07:11 CEST 2022] Check for domain='domain.xyz'
[Sa 14. Mai 00:07:11 CEST 2022] _currentRoot='/var/www/froxlor'
[Sa 14. Mai 00:07:11 CEST 2022] d='www.domain.xyz'
[Sa 14. Mai 00:07:11 CEST 2022] Check for domain='www.domain.xyz'
[Sa 14. Mai 00:07:11 CEST 2022] _currentRoot='/var/www/froxlor'
[Sa 14. Mai 00:07:11 CEST 2022] d
[Sa 14. Mai 00:07:11 CEST 2022] config file is empty, can not read CA_KEY_HASH
[Sa 14. Mai 00:07:11 CEST 2022] Using config home:/root/.acme.sh
[Sa 14. Mai 00:07:11 CEST 2022] ACME_DIRECTORY='https://acme.zerossl.com/v2/DV90'
[Sa 14. Mai 00:07:11 CEST 2022] _init api for server: https://acme.zerossl.com/v2/DV90
[Sa 14. Mai 00:07:11 CEST 2022] RSA key
[Sa 14. Mai 00:07:11 CEST 2022] config file is empty, can not read CA_EAB_KEY_ID
[Sa 14. Mai 00:07:11 CEST 2022] config file is empty, can not read CA_EAB_HMAC_KEY
[Sa 14. Mai 00:07:11 CEST 2022] config file is empty, can not read CA_EMAIL
[Sa 14. Mai 00:07:11 CEST 2022] No EAB credentials found for ZeroSSL, let's get one
[Sa 14. Mai 00:07:11 CEST 2022] acme.sh is using ZeroSSL as default CA now.
[Sa 14. Mai 00:07:11 CEST 2022] Please update your account with an email address first.
[Sa 14. Mai 00:07:11 CEST 2022] acme.sh --register-account -m my@example.com
[Sa 14. Mai 00:07:11 CEST 2022] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA
[Sa 14. Mai 00:07:11 CEST 2022] _on_issue_err
[Sa 14. Mai 00:07:11 CEST 2022] Please check log file for more details: /root/.acme.sh/acme.sh.log
[Sa 14. Mai 00:07:11 CEST 2022] Return code: 1
[Sa 14. Mai 00:07:11 CEST 2022] Error renew domain.xyz.

 

  • 0
Posted
4 minutes ago, tmuecksch said:

Gibt es schon einen Workaround? Ich blicke nicht so ganz durch.

Betroffene Zertifikate löschen (in froxlor und via acme.sh --remove) und froxlor cron abwarten oder mit --force --debug manuell ausführen.

  • 0
Posted

I also encountered this problem a couple of weeks ago, suddenly acme.sh was trying to renew one of my domains using ZeroSSL, when in all my settings I explicitly had Letsencrypt as CA.

I managed to fix the problem by registering and account with ZeroSSL, it's just a command which registers an account bu using an email, as it's explained here https://stackoverflow.com/questions/68538044/why-cant-write-certificate-crt-with-acme

acme.sh --register-account -m yyyy@yahoo.com

Once I did that then I was be able to create a new certificate with ZeroSSL, then because I didn't want to change Letsencrypt I forced a new certificate renewal by specifying

/root/.acme.sh/acme.sh --home "/root/.acme.sh" --renew-all --debug 2 --log --server letsencrypt --force

I still have no idea why acme.sh was trying to use ZeroSSL to issue new certificates, but it's been working fine since then.

  • 0
Posted

Ich habe es so gelöst:

sed -i 's|^Le_API=.*|Le_API=https://acme-v02.api.letsencrypt.org/directory|g' */*.conf

direkt in /root/.acme.sh

Ich lass gerade den renew durchlaufen und es sieht bisher ganz gut aus. Angefangen hat das mit dem ZeroSSL am 23.05.22, also muss da irgendetwas die Config verändert haben. Fast alle meine Domains waren umgestellt. Find ich ein wenig beunruhigend das acme.sh scheinbar einfach so spezifische configs umschreibt...

  • 0
Posted

hatten eben das selbe problem, von mehreren hundert Domains waren ca 50 auf einmal auf Zero SSL umgestellt.

1.) Mit dem registrieren des Accounts bei ZeroSSL hat es dann geklappt, da wurden jetzt Zero SSL Zerts ausgestellt
2.) Das mit dem löschen der Zertifikate in Froxlor und ACME funktioniert wie beschrieben auch, dann sind es wieder lets encrypt Zertifikate.

Wirklich spooky.
Classic Friday - dachte ich habe endlich mal Zeit um einige Dinge aufzuarbeiten 😉
 

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...