Apache startet nach Update auf 0.10.0 und Aktualisierung der SSL-Zertifikate nicht mehr

[Guest]

Guten Tag!

Ich habe Froxlor per tar.gz manuell auf die Version 0.10.0 geupdated und anschließend über die Web-App auch entsprechend aktualisiert.

Das Update hatte ich gemacht, da sich meine Lets-Encrypt SSL-Zertifikate nicht mehr aktualisiert haben und ich mir so eine Besserung erhofft habe.

Anschließend habe ich mit 

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

die Zertifikate aktualisieren lassen. Lief bei allen Domains rund. Bei einer Domain und einer dazugehörenden Subdomain gab es Warnings o.ä.

Als ich dann den Server neustarten wollte kam folgender Fehler:

Job for apache2.service failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details.

"systemctl status apache2.service" liefert folgenden Fehler:

systemctl status apache2.service -l
* apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled)
   Active: failed (Result: exit-code) since Thu 2019-10-10 14:32:15 CEST; 2min 13s ago
  Process: 15448 ExecStop=/usr/sbin/apachectl stop (code=exited, status=0/SUCCESS)
  Process: 15367 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCESS)
  Process: 23169 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE)
 Main PID: 1854 (code=exited, status=1/FAILURE)

Oct 10 14:32:15 **** apachectl[23169]: Action 'start' failed.
Oct 10 14:32:15 **** apachectl[23169]: The Apache error log may have more information.
Oct 10 14:32:15 **** systemd[1]: apache2.service: control process exited, code=exited status=1
Oct 10 14:32:15 **** systemd[1]: Failed to start The Apache HTTP Server.
Oct 10 14:32:15 **** systemd[1]: Unit apache2.service entered failed state.

Der error.log unter /var/log/apache2/ sagt folgendes:

[Thu Oct 10 12:38:24.538928 2019] [http2:warn] [pid 1612] AH10034: The mpm module (prefork.c) is not supported by mod_http2. The mpm determines how things are processed in your server. HTTP/2 has more demands in this regard and the currently selected mpm will just not do. This is an advisory warning. Your server will continue to work, but the HTTP/2 protocol will be inactive.
[Thu Oct 10 12:38:24.668681 2019] [mpm_prefork:notice] [pid 1612] AH00163: Apache/2.4.25 (Debian) OpenSSL/1.0.2t configured -- resuming normal operations
[Thu Oct 10 12:38:24.668752 2019] [core:notice] [pid 1612] AH00094: Command line: '/usr/sbin/apache2'
[Thu Oct 10 12:39:31.014389 2019] [mpm_prefork:notice] [pid 1612] AH00169: caught SIGTERM, shutting down
[Thu Oct 10 12:39:31.123137 2019] [ssl:warn] [pid 1853] AH01906: ****.bestsrv.de:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Thu Oct 10 12:39:31.123152 2019] [ssl:warn] [pid 1853] AH01909: ****.bestsrv.de:443:0 server certificate does NOT include an ID which matches the server name
[Thu Oct 10 12:39:31.172216 2019] [ssl:warn] [pid 1854] AH01906: ****.bestsrv.de:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Thu Oct 10 12:39:31.172235 2019] [ssl:warn] [pid 1854] AH01909: ****.bestsrv.de:443:0 server certificate does NOT include an ID which matches the server name
[Thu Oct 10 12:39:31.172373 2019] [http2:warn] [pid 1854] AH10034: The mpm module (prefork.c) is not supported by mod_http2. The mpm determines how things are processed in your server. HTTP/2 has more demands in this regard and the currently selected mpm will just not do. This is an advisory warning. Your server will continue to work, but the HTTP/2 protocol will be inactive.
[Thu Oct 10 12:39:31.285475 2019] [mpm_prefork:notice] [pid 1854] AH00163: Apache/2.4.25 (Debian) OpenSSL/1.0.2t configured -- resuming normal operations
[Thu Oct 10 12:39:31.291243 2019] [core:notice] [pid 1854] AH00094: Command line: '/usr/sbin/apache2'
[Thu Oct 10 12:41:30.858648 2019] [mpm_prefork:notice] [pid 1854] AH00171: Graceful restart requested, doing restart
[Thu Oct 10 12:41:31.099045 2019] [:emerg] [pid 1854] AH00020: Configuration Failed, exiting
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed

Aufgrund des Fehlers "AH00016: Configuration Failed" habe ich mit "apachectl configtest" die Syntax überprüft. Diese ist wohl okay.

Mit "strace -f apache2ctl start &> log.txt" habe ich geschaut, ob ein fehlerhaftes Zertifikat zu finden ist.

[pid 21058] rt_sigprocmask(SIG_SETMASK, [INT TERM], NULL, 8) = 0
[pid 21058] signalfd4(-1, [INT TERM], 8, SFD_CLOEXEC|SFD_NONBLOCK) = 5
[pid 21058] open("/run/systemd/ask-password", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
[pid 21058] fstat(6, {st_mode=S_IFDIR|0755, st_size=40, ...}) = 0
[pid 21058] getdents(6, /* 2 entries */, 32768) = 48
[pid 21058] getdents(6, /* 0 entries */, 32768) = 0
[pid 21058] close(6)                    = 0
[pid 21058] poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1 <unfinished ...>
[pid 21057] <... ppoll resumed> )       = 1 ([{fd=3, revents=POLLIN}])
[pid 21057] getpid()                    = 21057
[pid 21057] recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1O\0\0\0\10\0\0\0z\0\0\0\1\1o\0\31\0\0\0", iov_len=24}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=1, uid=0, gid=0}}], msg_controllen=32, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24
[pid 21057] recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1\0\0\0\0\0\0\0"..., iov_len=199}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=1, uid=0, gid=0}}], msg_controllen=32, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 199
[pid 21057] writev(2, [{iov_base="Job for apache2.service failed. "..., iov_len=104}, {iov_base="\n", iov_len=1}], 2Job for apache2.service failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details.
) = 105
[pid 21057] kill(21058, SIGTERM <unfinished ...>
[pid 21058] <... poll resumed> )        = 1 ([{fd=5, revents=POLLIN}])
[pid 21057] <... kill resumed> )        = 0
[pid 21058] close(4 <unfinished ...>
[pid 21057] kill(21058, SIGCONT <unfinished ...>
[pid 21058] <... close resumed> )       = 0
[pid 21057] <... kill resumed> )        = 0
[pid 21057] waitid(P_PID, 21058,  <unfinished ...>
[pid 21058] --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=21057, si_uid=0} ---
[pid 21058] close(5)                    = 0
[pid 21058] close(3)                    = 0
[pid 21058] exit_group(0)               = ?
[pid 21058] +++ exited with 0 +++
[pid 21057] <... waitid resumed> {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21058, si_uid=0, si_status=0, si_utime=0, si_stime=0}, WEXITED, NULL) = 0
[pid 21057] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21058, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
[pid 21057] close(3)                    = 0
[pid 21057] exit_group(1)               = ?
[pid 21057] +++ exited with 1 +++
<... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 21057
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21057, si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
rt_sigreturn({mask=[]})                 = 21057
write(1, "Action 'start' failed.\n", 23Action 'start' failed.
) = 23
write(1, "The Apache error log may have mo"..., 48The Apache error log may have more information.
) = 48
exit_group(1)                           = ?
+++ exited with 1 +++

 

Finde hier keinen Hinweis auf ein fehlerhaftes Zertifikat und weiß damit nicht wie ich noch weiter vorgehen soll.

Hoffe es kann jemand helfen, vielen Dank!

[lonesomewalker]

On 12/2/2019 at 2:51 PM, d00p said:

Na via Froxlor interface...Admin -> SSL Zertifikate -> löschen

Reicht temporär bis der Cronjob sie neu erstellt

Ohne funktionierendes Webinterface wirds schwer 😉

Das Löschen der Config-Files hat aber schon ausgereicht, danach war der froxlor vhost wieder erreichbar, und von da an sollte man dann auch weiterkommen

[wjl]

On 10/10/2019 at 3:03 PM, d00p said:

Das hatte ich jetzt leider auch schon bei zwei anderen Usern erlebt. Ich kann noch nicht ganz nachvollziehen woher das kommen sollte, denn eigentlich werden beim Update ja "alte" Let's Encrypt Zertifikate entfernt und komplett neue erstellt.

Auch ich habe mit strace versucht herauszufinden, welches Zerftifikat genau er nicht mag, ebenfalls erfolglos - ich habe danach einfach einen ssl-vhost ach dem anderen gelöscht und jedes mal apache neugestartet bis er gestartet hat und somit wusste man, bei welchem vhost das Zertifikat nicht ok ist. Das habe ich dann mit 

/root/.acme.sh/acme.sh remove [domain]

entfernt. Genauso wie in Froxlor aus der Zertifikatsliste (sofern vorhanden) und danach neu erstellen lassen - dann ging es.

Ich hab das Problem ebenfalls.

Und bei mir hat's leider nicht geholfen die ssl-vhosts und deren certs zu entfernen. Anfangs sah's gut aus, und ich kam - ohne ssl - wieder in Froxlor. Dort konnte ich dann auch nochmal die certs wegwerfen. Aber nach dem nächsten cronjob von Froxlor dann dasselbe...

Die acme-Routinen scheinen nicht alle certs neu angefordert zu haben, also hab ich das auch mal per force angefragt. Hab dann auch für alle Domains neue certs bekommen.

Und jetzt bleibt's aber dabei - der Apache startet nicht, die Ausgabe von configtest ist ok, aus den error.log und strace-Files erkennt man rein gar nichts... Merkwürden...

Schönen Abend noch,

Wolfgang

[pxmedia]

Ich hatte heute das gleiche Problem: Eines der Zertifikate wurde nicht korrekt aktualisiert -> ganze Kiste down, weil Apache nicht mehr hochkam.

Über das acme errorlog ließ sich nur noch herausfinden, dass es wohl Probleme bei der Authorisierung gab:

Zitat

[Wed 11 Dec 2019 12:05:11 AM CET] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 35
[Wed 11 Dec 2019 12:05:11 AM CET] Create new order error. Le_OrderFinalize not found. 

Darauf folgend dann nur noch:

Zitat

"Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/"

Auf der Kiste sind über 50 Domains, die alle auf die gleiche Weise im DNS angelegt sind, nur bei dieser einen hatte LE aus irgendeinem Grund Schluckauf und hat mich danach erstmal rausgeschmissen. Ist natürlich ärgerlich, wenn danach nichts mehr geht. Über strace ließ sich leider auch nicht herausfinden, welche Domain jetzt das Problem verursacht hat, aber der Cronjob gab mir den richtigen Tipp, weil er sich wieder an dieser einen Domain festgefahren hat:

Zitat

php -q /var/www/froxlor/html/scripts/froxlor_master_cronjob.php --letsencrypt --debug

...

[Wed 11 Dec 2019 03:48:53 AM CET] example.com:Verify error:Fetching http://example.com/.well-known/acme-challenge/oZPV0GHtECeqCBnmFeiQDaFnb43wPPjUVGv2qgXByd0: Connection refused

Werde den SSL Cronjob nun jede Woche manuell anstoßen, das ist mir ansonsten doch etwas zu wacklig. Auch wenn die Downtime glücklicherweise zur nachtschlafenden Zeit war.

[d00p]

Bitte --force, nicht --letsencrypt - das erstellt dir nicht die configs neu und bringt dir somit nix

[d00p]

Das hatte ich jetzt leider auch schon bei zwei anderen Usern erlebt. Ich kann noch nicht ganz nachvollziehen woher das kommen sollte, denn eigentlich werden beim Update ja "alte" Let's Encrypt Zertifikate entfernt und komplett neue erstellt.

Auch ich habe mit strace versucht herauszufinden, welches Zerftifikat genau er nicht mag, ebenfalls erfolglos - ich habe danach einfach einen ssl-vhost ach dem anderen gelöscht und jedes mal apache neugestartet bis er gestartet hat und somit wusste man, bei welchem vhost das Zertifikat nicht ok ist. Das habe ich dann mit 

/root/.acme.sh/acme.sh remove [domain]

entfernt. Genauso wie in Froxlor aus der Zertifikatsliste (sofern vorhanden) und danach neu erstellen lassen - dann ging es.

[Guest]

vor 2 Stunden schrieb d00p:

Das hatte ich jetzt leider auch schon bei zwei anderen Usern erlebt. Ich kann noch nicht ganz nachvollziehen woher das kommen sollte, denn eigentlich werden beim Update ja "alte" Let's Encrypt Zertifikate entfernt und komplett neue erstellt.

Auch ich habe mit strace versucht herauszufinden, welches Zerftifikat genau er nicht mag, ebenfalls erfolglos - ich habe danach einfach einen ssl-vhost ach dem anderen gelöscht und jedes mal apache neugestartet bis er gestartet hat und somit wusste man, bei welchem vhost das Zertifikat nicht ok ist. Das habe ich dann mit 

/root/.acme.sh/acme.sh remove [domain]

entfernt. Genauso wie in Froxlor aus der Zertifikatsliste (sofern vorhanden) und danach neu erstellen lassen - dann ging es.

Danke, hat so geklappt.

Der Fehler, der das verursacht hat, war glaube ich eine Domain, bei der die DNS-Einstellungen noch nicht ganz gestimmt haben und Let's Encrypt dann Probleme mit der ACME-Challenge hatte,

[lonesomewalker]

Same problem auf 5 verschiedenen Servern, auch hier spuckt strace gar nichts Verwertbares aus.

So, wie entferne ich aus der Datenbank die SSL-Domains korrekt, ohne die Integrität kaputt zu machen?
Zuerst wohl mal den Cron stoppen.

Danach ACME? Ohne zu wissen, welche Domain?

Oder reicht es, erst mal im Dateisystem die Conf der Domains zu löschen?

[d00p]

43 minutes ago, lonesomewalker said:

So, wie entferne ich aus der Datenbank die SSL-Domains korrekt, ohne die Integrität kaputt zu machen?

Na via Froxlor interface...Admin -> SSL Zertifikate -> löschen

43 minutes ago, lonesomewalker said:

Danach ACME? Ohne zu wissen, welche Domain?

Na eine Domain dazu solltest du schon kennen, sonst wirds schwer.

44 minutes ago, lonesomewalker said:

Oder reicht es, erst mal im Dateisystem die Conf der Domains zu löschen?

Reicht temporär bis der Cronjob sie neu erstellt