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

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

Es geht um ein komplett neues Let's Encrypt Zertifikat, welches erstmalig mit / unter 0.10 angelegt werden soll.
Bei Upgrade von 0.9 auf 0.10rc gabe es in der Hinsicht keine Probleme.

Hm, das kann eigentlich nicht sein. Neue Domain und Häkchen bei "Let's Encrypt nutzen"? Oder irgendwelche anderen settings? 

Neue Sub-Domain einer bereits mit Let's Encrypt geschützten Domain. Und nur das Häkchen bei "Let's Encrypt nutzen"

Die letzte Tage mehrfach selbst gemacht und nie ein Problem gehabt. Sicher das es keine Alias-Domains oder sowas sind?

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

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

 

Keine Änderung.

Bei einer neuen Sub-Domain unter einer komplett anderen Domain funktioniert es auch nicht.
Der will immer ein Renew machen.

ausgabe des crons bitte...

Hat hier wunderbar geklappt: https://scd.froxlor.org/ - gerade angelegt, häkchen dran, und fertig, Zertifikat erstellt

Could not get Let's Encrypt certificate for xxx: [Do 10. Okt 17:02:00 CEST 2019] Renew: 'xxx' [Do 10. Okt 17:02:00 CEST 2019] 'xxx' is not a issued domain, skip.

Just now, SCD said:

Could not get Let's Encrypt certificate for xxx: [Do 10. Okt 17:02:00 CEST 2019] Renew: 'xxx' [Do 10. Okt 17:02:00 CEST 2019] 'xxx' is not a issued domain, skip.

das ist bei weitem nicht alles...

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

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

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 October 10, 20196 yr by SCD

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

Was halt am meisten dagegen spricht es auszulagern - ich kann dann nixmehr im --debug cron anzeigen - man bekommt ggfls nicht mit wenn es renew fehler gibt - fiel mir nur grad so ein

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

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)

 

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

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

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();

 

Bind funktioniert. Jedoch der Reload von Apache nicht:

Wrapper xxx/php-fcgi-starter cannot be accessed: (2)No such file or directory

(Ein apache2 restart per Hand hilft dann auch nicht)

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)