Jump to content
Froxlor Forum
  • 0

Es werden keine neuen Let's Encrypt Zertfikate mehr erstellt


SCD

Question

Hallo,

seit dem Update auf 0.10  werden keine neuen Let's Encrypt Zertfikate mehr erstellt:

[information] Creating certificate for xxx
[information] Adding SAN entry: xxx
[debug] [Do 10. Okt 16:24:01 CEST 2019] Renew: 'xxx'
[Do 10. Okt 16:24:01 CEST 2019] 'xxx' is not a issued domain, skip.

Wieso wird da ein Renew durchgeführt ?

Anderes Thema:

Mir ist aufgefallen, dass die renews nun über den acme  Cron Job erfolgen.
Wie kommen die neuen Zertifikate ins Froxlor-System, wenn es keine Änderungen innerhalb von Froxlor vorgenommen werden ?
(Soweit ich das System verstehe werden die Zertifikate beim System-Task 1 eingelesen, wenn die Gültigkeit nicht ausgefüllt ist oder nur noch 30 Tage beträgt)

Stefan

Link to comment
Share on other sites

24 answers to this question

Recommended Posts

  • 0
1 minute ago, SCD said:

[debug] [Do 10. Okt 16:24:01 CEST 2019] Renew: 'xxx'
[Do 10. Okt 16:24:01 CEST 2019] 'xxx' is not a issued domain, skip.

Wieso wird da ein Renew durchgeführt ?

Eigentlich löscht das update von 0.9.40.1 auf 0.10.0 alle bisherigen Let's Encrypt Zertifikate, da wir von lescript auf acme.sh umgestellt haben. Ein Renew dürfte gar nicht vorkommen.

2 minutes ago, SCD said:

Mir ist aufgefallen, dass die renews nun über den acme  Cron Job erfolgen.
Wie kommen die neuen Zertifikate ins Froxlor-System, wenn es keine Änderungen innerhalb von Froxlor vorgenommen werden ?

argh, dummes acme.sh richtet seinen eigenen cronjob ein...eigentlich ruft froxlor das in seinem eigenen cronjob auf und regelt da alles, da muss ich wohl noch sicherstellen, dass da kein eigener cronjob von acme.sh eingerichtet wird, danke

Link to comment
Share on other sites

  • 0
+-----+---------------+---------+------------+-------------+----------------------------------+--------------+---------------+------------+------------------+-------------------+---------------+----------+------+---------+--------------+-------------+----------------+----------------+------------+-------------+------------------+----------------+--------------+-----------------+-------------+------------+----------+--------+-------------------+------------------+--------------+-------------------+-----------------------+----------------+-------------+----------+----------+--------------+---------------+-------+------------+----------------+---------------+
| id  | domain        | adminid | customerid | aliasdomain | documentroot                     | isbinddomain | isemaildomain | email_only | iswildcarddomain | subcanemaildomain | caneditdomain | zonefile | dkim | dkim_id | dkim_privkey | dkim_pubkey | wwwserveralias | parentdomainid | phpenabled | openbasedir | openbasedir_path | speciallogfile | ssl_redirect | specialsettings | deactivated | bindserial | add_date | period | registration_date | termination_date | phpsettingid | mod_fcgid_starter | mod_fcgid_maxrequests | ismainbutsubto | letsencrypt | hsts     | hsts_sub | hsts_preload | ocsp_stapling | http2 | notryfiles | writeaccesslog | writeerrorlog |
+-----+---------------+---------+------------+-------------+----------------------------------+--------------+---------------+------------+------------------+-------------------+---------------+----------+------+---------+--------------+-------------+----------------+----------------+------------+-------------+------------------+----------------+--------------+-----------------+-------------+------------+----------+--------+-------------------+------------------+--------------+-------------------+-----------------------+----------------+-------------+----------+----------+--------------+---------------+-------+------------+----------------+---------------+
|   1 | hauptdomain      |       1 |          1 |        NULL | URL (Weiterleitung)        |            1 |             1 |          0 |                0 |                 0 |             1 |          |    0 |       0 |              |             |              1 |              0 |          1 |           1 |                0 |              0 |            0 |                 |           0 | 2019101004 |        0 |     12 | 2014-08-17        | NULL             |            1 |                -1 |                    -1 |              0 |           1 | 31536000 |        0 |            0 |             0 |     0 |          0 |              1 |             1 |
| 251 | sub.hauptdomain |       1 |          1 |        NULL | PFAD |            0 |             0 |          0 |                0 |                 0 |             1 |          |    0 |       0 | NULL         | NULL        |              1 |              1 |          1 |           1 |                0 |              0 |            0 |                 |           0 | 2000010100 |        0 |     12 | NULL              | NULL             |            1 |                -1 |                    -1 |              0 |           1 | 0        |        0 |            0 |             0 |     0 |          0 |              1 |             1 |
+-----+---------------+---------+------------+-------------+----------------------------------+--------------+---------------+------------+------------------+-------------------+---------------+----------+------+---------+--------------+-------------+----------------+----------------+------------+-------------+------------------+----------------+--------------+-----------------+-------------+------------+----------+--------+-------------------+------------------+--------------+-------------------+-----------------------+----------------+-------------+----------+----------+--------------+---------------+-------+------------+----------------+---------------+

Nichts besonderes, oder stört eventuell HSTS bei der Hauptdomain

Link to comment
Share on other sites

  • 0

nö, hsts is ssl und für die validierung wird ja kein ssl angefragt. Und hsts für subdomains hast du ja bei der hauptdomain auch nicht aktiviert.

Folgendes mal prüfen:

1) gibt es ein Zertifikat in "SSL Zertifikate" für diese domain (in froxlor)? Wenn ja, löschen

2) /root/.acme.sh/acme.sh remove [sub.hauptdomain] (auch wenns vllt keins gibt, sicher is sicher)

danach nochmal:

php /var/www/froxlor/scripts/froxlor_master_cronjob.php --force --debug

 

Link to comment
Share on other sites

  • 0

Habe den Fehler: Vor der neuen Domain gab es eine andere Domain, wo ein RENEW fällig war, der nie geklappt hat. Nach eine Manipulation des Datums in der DB gingen die neuen Domain durch.

Dabei ist mir aber ein großer Fehler aufgefallen: Bevor die neuen Zertifikate durch acme erstellt werden, werden die FCGI Konfigurationen gelöscht. Dadurch gibt es Internal Server Error bei allen Froxlor Domains weil der Starter nicht mehr da ist ...

Link to comment
Share on other sites

  • 0
Just now, SCD said:

Nach eine Manipulation des Datums in der DB gingen die neuen Domain durch.

also doch manuell gefummelt :) Klassiker

Just now, SCD said:

Dabei ist mir aber ein großer Fehler aufgefallen: Bevor die neuen Zertifikate durch acme erstellt werden, werden die FCGI Konfigurationen gelöscht. Dadurch gibt es Internal Server Error bei allen Froxlor Domains weil der Starter nicht mehr da ist ...

hm, ja das macht der cron so, vor erstellung der configs werden die alten halt gelöscht - dauert der cronjob, z.B. durch zertifikatserstellung - länger. Aber jetzt wo du es sagst, ja bei FCGID ist das natürlich ein problem, bei den anderen beiden (mod_php und php-fpm) wäre es nur spürbar wenn die Dienste neugestartet werden.

Ich schau mal ob ich da was drehen kann um die "config-lose" zeit zu minimieren

Link to comment
Share on other sites

  • 0

Manuell gefummelt habe ich nur, weil ich das Zertifikat  nicht löschen wollte.  Der Fehler war vorher schon da.

Kann man nicht erst die Zertifikat erstellen und dann die Konfiguration löschen?

Es waren jetzt nur drei Domains. Möchte aber nicht dran denken,  wenn alle Domains auf einmal ein Renew bekommen. Und da die beim Upgrade ja alle neu erstellt wurden,  laufen die ja auch gemeinsam ab.

Edit: Eine andere Möglichkeit. Bei neuen Zertfikaten nur den acme aufrufen aber nicht warten. In der DB die Domain schon unter ssl-settings ohne Gültigkeit eintragen. 

Der Froxlor Cron guckt dann im nächsten Lauf nach,  ob schon ein Zertifikat da ist und übernimmt es dann.

Den Renew komplett über acme laufen lassen (Den Cron gibt es ja fehlerweise schon) und beim Wartungsjob nachsehen ob es neue Zertifikate gibt ...

Edited by SCD
Link to comment
Share on other sites

  • 0
43 minutes ago, SCD said:

Kann man nicht erst die Zertifikat erstellen und dann die Konfiguration löschen?

ich sagte ja ich schaue was ich machen kann

44 minutes ago, SCD said:

Edit: Eine andere Möglichkeit. Bei neuen Zertfikaten nur den acme aufrufen aber nicht warten. In der DB die Domain schon unter ssl-settings ohne Gültigkeit eintragen.

und welche ssl settings soll ich eintragen wenn ich kein zertifikat habe??? das geht halt so nicht. Ich kann ja auch erst den ssl-vhost erstellen wenn ich ein zertifikat habe

44 minutes ago, SCD said:

Der Froxlor Cron guckt dann im nächsten Lauf nach,  ob schon ein Zertifikat da ist und übernimmt es dann.

das them gabs es vor einiger zeit schon, da wurde bemängelt, dass man 2 oder 3 durchläufe auf sein zertifikat warten muss - man kann es nunmal nicht alles recht machen

45 minutes ago, SCD said:

Den Renew komplett über acme laufen lassen (Den Cron gibt es ja fehlerweise schon) und beim Wartungsjob nachsehen ob es neue Zertifikate gibt ...

Ja dachte ich auch schon dran; also die Daten von acme.sh selbst zum Abgleich immer zu benutzen - dafür müsste man das ganze Zertifikats-Zeug komplett neuschreiben - bei der "migration" von lescript auf acme.sh war das die "einfachste" methode - heisst ja nicht das es ewig so bleibt

Link to comment
Share on other sites

  • 0

Ich habe als Workaround erstmal das Löschen der FCGI-Datein in der ConfigIO.php auskommentiert.

Beim Testen sind mir noch zwei weitere Fehler aufgefallen:

  • Es werden ja erst die Let's Encrypt Zertifikate erstellt und anschließend Bind neugestartet.
    So sind die neuen Sub-Domains noch nicht in der DNS bekannt und damit schlägt die Generierung fehl.
    Zum Nachvollziehen einfach eine Sub-Domain anlegen und sofort ein Zertifikat mit anfordern.
  • Die htpasswd Dateien werden ja auch sofort gelöscht. Hier gibt es dann auch einen 500 Internal Server Error
    (2)No such file or directory: AH01620: Could not open password file: /etc/apache2/froxlor-htpasswd/1-303b8defc8fb743668b7f584053ffd8a.htpasswd

Im neuen GIT ist noch folgender Fehler

PHP Notice: Array to string conversion in /var/www/froxlor/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php on line 392
PHP Warning: implode(): Invalid arguments passed in /var/www/froxlor/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php on line 393

Link to comment
Share on other sites

  • 0
18 minutes ago, SCD said:
  • Es werden ja erst die Let's Encrypt Zertifikate erstellt und anschließend Bind neugestartet.
    So sind die neuen Sub-Domains noch nicht in der DNS bekannt und damit schlägt die Generierung fehl.
    Zum Nachvollziehen einfach eine Sub-Domain anlegen und sofort ein Zertifikat mit anfordern.

okay, bei eigener DNS nutzung wäre das mölich, schau ich mir an (am besten bitte ein issue auf github dazu aufmachen)

19 minutes ago, SCD said:

Die htpasswd Dateien werden ja auch sofort gelöscht. Hier gibt es dann auch einen 500 Internal Server Error
(2)No such file or directory: AH01620: Could not open password file: /etc/apache2/froxlor-htpasswd/1-303b8defc8fb743668b7f584053ffd8a.htpasswd

ja, thema gab es schon, configs werden vor dem erstellen der configs gelöscht, bei längeren aufgaben ist das ungünstig.

20 minutes ago, SCD said:

Im neuen GIT ist noch folgender Fehler

PHP Notice: Array to string conversion in /var/www/froxlor/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php on line 392
PHP Warning: implode(): Invalid arguments passed in /var/www/froxlor/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php on line 393

Gefunden und behoben (beim nächsten push)

 

Link to comment
Share on other sites

  • 0
vor 11 Stunden schrieb d00p:

okay, bei eigener DNS nutzung wäre das mölich, schau ich mir an (am besten bitte ein issue auf github dazu aufmachen)

Kann ich da in Deutsch schreiben ?
Mein Englisch ist nicht so besonders

vor 11 Stunden schrieb d00p:

Gefunden und behoben (beim nächsten push)

Leider nicht, mit array_merge($acmesh_result, $acmesh_result2); geht es

Link to comment
Share on other sites

  • 0
7 minutes ago, SCD said:

Kann ich da in Deutsch schreiben ?
Mein Englisch ist nicht so besonders

Bevorzugt natürlich englisch, aber geht natürlich auch auf deutsch

7 minutes ago, SCD said:

Leider nicht, mit array_merge($acmesh_result, $acmesh_result2); geht es

jetzt aber, auf ganz nummer sicher: https://github.com/Froxlor/Froxlor/commit/9410356bc7f05055f9bacbb21325f2a536c70c3f

Link to comment
Share on other sites

  • 0

Könntest du folgenden aktuellen patch testen ob da nun alles rennt, zum einen:

- erst dns configs, dann web-vhosts

- configs erst kurz vor neuerstellung löschen

diff --git a/lib/Froxlor/Cron/System/TasksCron.php b/lib/Froxlor/Cron/System/TasksCron.php
index f836e1dd..24a3f8a4 100644
--- a/lib/Froxlor/Cron/System/TasksCron.php
+++ b/lib/Froxlor/Cron/System/TasksCron.php
@@ -30,8 +30,9 @@ class TasksCron extends \Froxlor\Cron\FroxlorCron
                 */
                self::$cronlog->logAction(\Froxlor\FroxlorLogger::CRON_ACTION, LOG_INFO, "TasksCron: Searching for tasks to do");
                // no type 99 (regenerate cron.d-file) and no type 20 (customer backup)
+               // order by type descending to re-create bind and then webserver at the end
                $result_tasks_stmt = Database::query("
-                       SELECT `id`, `type`, `data` FROM `" . TABLE_PANEL_TASKS . "` WHERE `type` <> '99' AND `type` <> '20' ORDER BY `id` ASC
+                       SELECT `id`, `type`, `data` FROM `" . TABLE_PANEL_TASKS . "` WHERE `type` <> '99' AND `type` <> '20' ORDER BY `type` DESC, `id` ASC
                ");
                $num_results = Database::num_rows();
                $resultIDs = array();
@@ -120,10 +121,6 @@ class TasksCron extends \Froxlor\Cron\FroxlorCron
 
        private static function rebuildWebserverConfigs()
        {
-               // get configuration-I/O object
-               $configio = new \Froxlor\Cron\Http\ConfigIO();
-               // clean up old configs
-               $configio->cleanUp();
 
                if (Settings::Get('system.webserver') == "apache2") {
                        $websrv = '\\Froxlor\\Cron\\Http\\Apache';
@@ -142,6 +139,9 @@ class TasksCron extends \Froxlor\Cron\FroxlorCron
                        }
                }
 
+               // get configuration-I/O object
+               $configio = new \Froxlor\Cron\Http\ConfigIO();
+               // get webserver object
                $webserver = new $websrv();
 
                if (isset($webserver)) {
@@ -149,6 +149,8 @@ class TasksCron extends \Froxlor\Cron\FroxlorCron
                        $webserver->createIpPort();
                        $webserver->createVirtualHosts();
                        $webserver->createFileDirOptions();
+                       // clean up old configs right before writing the new ones to minimize "downtime"
+                       $configio->cleanUp();
                        $webserver->writeConfigs();
                        $webserver->createOwnVhostStarter();
                        $webserver->reload();

 

Link to comment
Share on other sites

  • 0

hmmm ja mist, die php configs / starter werden schon im createVirtualHosts() erstellt - muss das $configio->cleanUp(); doch vor $webserver->createIpPort(); (im $webserver->init(); macht er die zertifikate, das ist das was lange dauert)

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