[Ubuntu] Apache/Certbot deaktiviert sich immer wieder

[Crys]

Servus zusammen,

ich habe einen aktuellen Ubuntu 16 LTS Server. Vor ein paar Tagen habe ich mal wieder alle Updates laufen lassen und ihn gewartet ... und seit der selben Zeit funktioniert der Webserver nicht mehr rund.

Zuerst ging mein Webserver mit Apache2 gar nicht mehr, dann habe ich ein bisschen rum probiert und gesehen, dass es am certbot von Letsencrypt liegt. Diesen habe ich auf verschiedenen Weißen wieder versucht zu starten, bis des dann auch geklappt hat. Aber dennoch schaltet sich ca. 1x am Tag den Apache ab ...

Aktivieren kann ich das dann wieder nachfolgend:

certbot certonly --apache --tls-sni-01-port 4545 --allow-subset-of-names --cert-name <MyDomain> -d <MyDomain>

service apache2 start

Wenn ich ins Apache2 errorlog schaue habe ich dort immer wieder die selben Einträge, ca. 3x jede Minute:

[Sun Feb 04 14:25:31.233001 2018] [ssl:info] [pid 22885] [client 127.0.0.1:40748] AH01964: Connection to child 2 established (server unas:443)
[Sun Feb 04 14:25:31.233562 2018] [ssl:debug] [pid 22885] ssl_engine_kernel.c(2096): [client 127.0.0.1:40748] AH02043: SSL virtual host for servername <MyDomain> found
[Sun Feb 04 14:25:31.235270 2018] [ssl:debug] [pid 22885] ssl_engine_kernel.c(2023): [client 127.0.0.1:40748] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[Sun Feb 04 14:25:31.235420 2018] [ssl:debug] [pid 22885] ssl_engine_kernel.c(354): [client 127.0.0.1:40748] AH02034: Initial (No.1) HTTPS request received for child 2 (server <MyDomain>:443)
[Sun Feb 04 14:25:31.236451 2018] [authz_core:debug] [pid 22885] mod_authz_core.c(809): [client 127.0.0.1:40748] AH01626: authorization result of Require all granted: granted
[Sun Feb 04 14:25:31.236484 2018] [authz_core:debug] [pid 22885] mod_authz_core.c(809): [client 127.0.0.1:40748] AH01626: authorization result of <RequireAny>: granted
[Sun Feb 04 14:25:31.236688 2018] [authz_core:debug] [pid 22885] mod_authz_core.c(809): [client 127.0.0.1:40748] AH01626: authorization result of Require all granted: granted
[Sun Feb 04 14:25:31.236711 2018] [authz_core:debug] [pid 22885] mod_authz_core.c(809): [client 127.0.0.1:40748] AH01626: authorization result of <RequireAny>: granted
[Sun Feb 04 14:25:36.282663 2018] [ssl:info] [pid 22885] (70007)The timeout specified has expired: [client 127.0.0.1:40748] AH01991: SSL input filter read failed.
[Sun Feb 04 14:25:36.282838 2018] [ssl:debug] [pid 22885] ssl_engine_io.c(1017): [client 127.0.0.1:40748] AH02001: Connection closed to child 2 with standard shutdown (server <MyDomain>:443)

Ich habe mich schon im Internet informiert, aber nichts aussagekräftiges dazu gefudnen, was das bedeutet oder ob das überhaupt mit meinem Fehler in zusammenhing steht. Leider habe ich gerade nicht den Eintrag, bevor der Webserver sich immer abschaltet, den kann ich aber nachreichen.

Ich habe gelesen, dass Letsencrypt das Apache Plugin (aus Sicherheitsgründen) nicht mehr unterstützt und man deshalb den 'webroot' verwenden soll. Der Webserver mit Letsencrypt lief bei mir jetzt gut 2 Jahre ohne Probleme.

Was kann hier falsch laufen?

 

[snaxilian]

Naja, wenn der Anbieter über die bisherige Methode keine Zertifikate mehr ausstellt, dann musst du dich eben anpassen und die Webroot Methode nutzen.
Warum sollte sich hier jemand die Mühe machen, eine vom Hersteller nicht supportete und damit nicht funktionale Lösung so lange zurecht zu frickeln bis dies funktioniert.
Desweiteren: Nur mit der Fehlermeldung kann man recht wenig anfangen. Gerade die Meldungen, die du erst nachreichen willst, wären interessant.

Was hindert dich denn daran, dein System an die unterstützte Variante anzupassen? Certbot und Apache sind beide recht gut dokumentiert und Beispiele finden sich mehr als genug im Netz...

 

[Crys]

Was hindert dich denn daran, dein System an die unterstützte Variante anzupassen?

Weil es nicht funktioniert! Ich habe gut 2 Wochen versucht den Webserver wieder zum laufen zu bekommen.
Weil es auch noch ein Limit von max. 5 neuen Zertifikaten in 7 Tagen gibt, ist probieren keine gute Idee ...

Bitte, ich habe den Befehl 'sudo certbot --authenticator webroot --installer apache', wie in der Hilfe für Apache2 Ubuntu 16.04 beschrieben ausgeführt:

$ certbot --authenticator webroot --installer apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer apache

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: <MyDomain>
2: <MyDomain2>
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/<MyDomain>.conf)

What would you like to do?
-------------------------------------------------------------------------------
1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (limit ~5 per 7 days)
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Keeping the existing certificate
Deploying Certificate for <MyDomain> to VirtualHost /etc/apache2/sites-enabled/default-ssl.conf
Error while running apache2ctl graceful.
httpd not running, trying to start
Action 'graceful' failed.
The Apache error log may have more information.

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs

Rolling back to previous server configuration...
Error while running apache2ctl graceful.
httpd not running, trying to start
Action 'graceful' failed.
The Apache error log may have more information.

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs

Encountered exception during recovery
Error while running apache2ctl graceful.
httpd not running, trying to start
Action 'graceful' failed.
The Apache error log may have more information.

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/certbot/error_handler.py", line 100, in _call_registered
    self.funcs[-1]()
  File "/usr/lib/python2.7/dist-packages/certbot/client.py", line 557, in _rollback_and_restart
    self.installer.restart()
  File "/usr/lib/python2.7/dist-packages/certbot_apache/configurator.py", line 1834, in restart
    self._reload()
  File "/usr/lib/python2.7/dist-packages/certbot_apache/configurator.py", line 1845, in _reload
    raise errors.MisconfigurationError(str(err))
MisconfigurationError: Error while running apache2ctl graceful.
httpd not running, trying to start
Action 'graceful' failed.
The Apache error log may have more information.

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs

Error while running apache2ctl graceful.
httpd not running, trying to start
Action 'graceful' failed.
The Apache error log may have more information.

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs


IMPORTANT NOTES:
 - An error occurred and we failed to restore your config and restart
   your server. Please submit a bug report to
   https://github.com/letsencrypt/letsencrypt
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/<MyDomain>/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/<MyDomain>/privkey.pem
   Your cert will expire on 2018-05-03. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"

Nun, jetzt geht wieder gar nichts.

Und hier auch noch die letzten Zeilen aus dem apache2 error log:

[Sun Feb 04 20:24:49.364846 2018] [ssl:info] [pid 11382] [client 127.0.0.1:51552] AH01964: Connection to child 10 established (server unas:443)
[Sun Feb 04 20:24:49.365294 2018] [ssl:debug] [pid 11382] ssl_engine_kernel.c(2096): [client 127.0.0.1:51552] AH02043: SSL virtual host for servername <MyDomain> found
[Sun Feb 04 20:24:49.406207 2018] [ssl:debug] [pid 11382] ssl_engine_kernel.c(2023): [client 127.0.0.1:51552] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[Sun Feb 04 20:24:49.406327 2018] [ssl:debug] [pid 11382] ssl_engine_kernel.c(354): [client 127.0.0.1:51552] AH02034: Initial (No.1) HTTPS request received for child 10 (server <MyDomain>:443)
[Sun Feb 04 20:24:49.407254 2018] [authz_core:debug] [pid 11382] mod_authz_core.c(809): [client 127.0.0.1:51552] AH01626: authorization result of Require all granted: granted
[Sun Feb 04 20:24:49.407273 2018] [authz_core:debug] [pid 11382] mod_authz_core.c(809): [client 127.0.0.1:51552] AH01626: authorization result of <RequireAny>: granted
[Sun Feb 04 20:24:49.407434 2018] [authz_core:debug] [pid 11382] mod_authz_core.c(809): [client 127.0.0.1:51552] AH01626: authorization result of Require all granted: granted
[Sun Feb 04 20:24:49.407446 2018] [authz_core:debug] [pid 11382] mod_authz_core.c(809): [client 127.0.0.1:51552] AH01626: authorization result of <RequireAny>: granted
[Sun Feb 04 20:24:50.624711 2018] [mpm_prefork:notice] [pid 18367] AH00171: Graceful restart requested, doing restart
(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
[Sun Feb 04 20:24:50.641190 2018] [mpm_prefork:alert] [pid 18367] no listening sockets available, shutting down
[Sun Feb 04 20:24:50.641195 2018] [:emerg] [pid 18367] AH00019: Unable to open logs, exiting
[Sun Feb 04 20:24:55.650718 2018] [ssl:info] [pid 11382] (70007)The timeout specified has expired: [client 127.0.0.1:51552] AH01991: SSL input filter read failed.
[Sun Feb 04 20:24:55.650905 2018] [ssl:debug] [pid 11382] ssl_engine_io.c(1017): [client 127.0.0.1:51552] AH02001: Connection closed to child 10 with standard shutdown (server <MyDomain>:443)

Dann schon mal vielen Dank für diese Hilfe und der weiteren Lösung des Problems (mit dieser nun handfesten Fehlermeldung)

 

[snaxilian]

Also Anspruch auf Hilfe hast du nicht, aber schön wie du dies rein interpretierst.

Natürlich kannst du herum probieren, genau dafür gibt es den "dry run"

Die Log-Meldungen deuten aber eher auf eine Fehlkonfiguration des Apache hin und weniger auf ein Problem mit dem Certbot.
Apache hat netterweise viele Hinweise in seinen Logs, nach denen man suchen kann und die Hinweise geben wo die Fehler liegen. Das sind diese ganzen AHxxxx Werte.

Ich würde also ein Problem nach dem anderen lösen:
Zuerst deine Config Files gerade ziehen und danach den Certbot.

 

[fax668]

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443

Das will dir sagen, dass schon ein anderer Prozess auf Port 443 lauscht. Vermutlich ist das ein alter Apache Prozess, den du erst mit "kill" abschießen musst. Welchen Prozess genau du beenden musst, kannst du mit "netstat -lnpt" rausfinden.

 

[Crys]

Das will dir sagen, dass schon ein anderer Prozess auf Port 443 lauscht. [...]

Mein OpenVPN lauscht da, weshalb mein ursprünglicher Befehl ja eine Weiterleitung auf Port 4545 beinhaltet: '--tls-sni-01-port 4545'.
Intern wird auch Port 443 gesplittet und das schon seit Jahren ohne Probleme. Ich bekomme diesen 'webroot' Befehl aber nicht mit einer Portweiterleitung kombiniert.
Eventuell hat bei der obigen Apache-Fehlermeldung der Certbot wieder 'Port 433' in die '/etc/apache2/ports.conf' geschrieben. Das macht der (hin und wieder), was ich auch immer auskommentieren muss, damit es läuft ...

 

[snaxilian]

Hast du zufällig diese Anleitung für den OpenVPN Server befolgt? http://www.vpntutorials.com/tutorials/openvpn-sharing-a-port-with-a-webserver-on-port-80-443/
Denn "intern" lauscht dein Apache somit nur noch auf den Ports 80 & 4545, von extern wäre er aber auch unter 443 erreichbar, da der OpenVPN Server nicht für ihn bestimmte Anfragen auf 443 eben weiterleitet auf 4545.

Somit wäre aber der Webserver für LE auf 80 und 443 erreichbar und du müsstest nicht diesen anderen Port angeben. Ist halt keine alltägliche Config. Ich hätte sowas auch eher durch einen Reverse Proxy oder IPtables irgendwie abgefackelt, dass je nachdem ob es TCP oder UDP Pakete sind, diese entweder an den Apache oder den OpenVPN Dienst gehen.

Bei der Webroot Methode ist tls-sni-01 übrigens hinfällig, da http-01 als Challenge genutzt wird und so "nur" der Webserver auf Port 80 erreichbar sein muss.

 

[Crys]

Ich habe hier auch noch das Apache Log, unmittelbar vor dem Aus:

[Mon Feb 05 00:54:31.113906 2018] [ssl:debug] [pid 23194] ssl_engine_kernel.c(354): [client 127.0.0.1:56744] AH02034: Subsequent (No.4) HTTPS request received for child 6 (server <MyDomain>:443)
[Mon Feb 05 00:54:31.114374 2018] [authz_core:debug] [pid 23194] mod_authz_core.c(809): [client 127.0.0.1:56744] AH01626: authorization result of Require all granted: granted
[Mon Feb 05 00:54:31.114387 2018] [authz_core:debug] [pid 23194] mod_authz_core.c(809): [client 127.0.0.1:56744] AH01626: authorization result of <RequireAny>: granted
[Mon Feb 05 00:54:31.114456 2018] [authz_core:debug] [pid 23194] mod_authz_core.c(809): [client 127.0.0.1:56744] AH01626: authorization result of Require all granted: granted
[Mon Feb 05 00:54:31.114460 2018] [authz_core:debug] [pid 23194] mod_authz_core.c(809): [client 127.0.0.1:56744] AH01626: authorization result of <RequireAny>: granted
[Mon Feb 05 00:54:32.642556 2018] [ssl:info] [pid 15249] (70007)The timeout specified has expired: [client 127.0.0.1:56742] AH01991: SSL input filter read failed.
[Mon Feb 05 00:54:32.642701 2018] [ssl:debug] [pid 15249] ssl_engine_io.c(1017): [client 127.0.0.1:56742] AH02001: Connection closed to child 5 with standard shutdown (server <MyDomain>:443)
[Mon Feb 05 00:54:32.760996 2018] [ssl:info] [pid 15241] [client 127.0.0.1:56746] AH01964: Connection to child 3 established (server unas:443)
[Mon Feb 05 00:54:32.761382 2018] [ssl:debug] [pid 15241] ssl_engine_kernel.c(2096): [client 127.0.0.1:56746] AH02043: SSL virtual host for servername <MyDomain> found
[Mon Feb 05 00:54:32.763533 2018] [ssl:debug] [pid 15241] ssl_engine_kernel.c(2023): [client 127.0.0.1:56746] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[Mon Feb 05 00:54:32.763620 2018] [ssl:debug] [pid 15241] ssl_engine_kernel.c(354): [client 127.0.0.1:56746] AH02034: Initial (No.1) HTTPS request received for child 3 (server <MyDomain>:443)
[Mon Feb 05 00:54:32.764419 2018] [authz_core:debug] [pid 15241] mod_authz_core.c(809): [client 127.0.0.1:56746] AH01626: authorization result of Require all granted: granted
[Mon Feb 05 00:54:32.764434 2018] [authz_core:debug] [pid 15241] mod_authz_core.c(809): [client 127.0.0.1:56746] AH01626: authorization result of <RequireAny>: granted
[Mon Feb 05 00:54:32.764571 2018] [authz_core:debug] [pid 15241] mod_authz_core.c(809): [client 127.0.0.1:56746] AH01626: authorization result of Require all granted: granted
[Mon Feb 05 00:54:32.764581 2018] [authz_core:debug] [pid 15241] mod_authz_core.c(809): [client 127.0.0.1:56746] AH01626: authorization result of <RequireAny>: granted
[Mon Feb 05 00:54:36.165440 2018] [ssl:info] [pid 23194] (70007)The timeout specified has expired: [client 127.0.0.1:56744] AH01991: SSL input filter read failed.
[Mon Feb 05 00:54:36.165588 2018] [ssl:debug] [pid 23194] ssl_engine_io.c(1017): [client 127.0.0.1:56744] AH02001: Connection closed to child 6 with standard shutdown (server <MyDomain>:443)
[Mon Feb 05 00:54:37.905264 2018] [ssl:info] [pid 15241] (70007)The timeout specified has expired: [client 127.0.0.1:56746] AH01991: SSL input filter read failed.
[Mon Feb 05 00:54:37.905401 2018] [ssl:debug] [pid 15241] ssl_engine_io.c(1017): [client 127.0.0.1:56746] AH02001: Connection closed to child 3 with standard shutdown (server <MyDomain>:443)
[Mon Feb 05 00:54:45.395563 2018] [mpm_prefork:notice] [pid 15233] AH00171: Graceful restart requested, doing restart
AH00112: Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist
AH00112: Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist
(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443

Danach geht es erst nach dem manuellen neustart (wie im ersten Post beschrieben) weiter.

------------------------------------------------------------------------------------------------------------------

Hast du zufällig diese Anleitung für den OpenVPN Server befolgt? [...]

Genau, so habe ich das eingerichtet

Somit wäre aber der Webserver für LE auf 80 und 443 erreichbar und du müsstest nicht diesen anderen Port angeben. [...]

Genau, von extern ist https auch wie gehabt über Port 443 erreichbar. Der Certbot hat aber schon immer eine weiterleitung auf Port 4545 benötigt, diese Päckchen hat der OpenVPN Split wohl nicht weitergereicht ... aber hatte ja lange so funktioniert.

Ich hätte sowas auch eher durch einen Reverse Proxy oder IPtables irgendwie abgefackelt, dass je nachdem ob es TCP oder UDP Pakete sind, diese entweder an den Apache oder den OpenVPN Dienst gehen.

Daran hatte ich mich auch mal versucht, aber nicht zum laufen bekommen. Meinst du damit sollte es gehen?

Ich bin einfach ein bisschen ratlos, was ich noch probieren sollte!?

 

[snaxilian]

Das kann vielfältige Ursachen haben. Irgendein Fehler in den Apache oder Sites Config sein oder der OpenVPN Server grätscht dazwischen weil er nicht sauber die nicht für ihn bestimmten Pakete weiterleitet.
Ich würde da auch eher wenig Fehlersuche betreiben sondern folgendes machen:

1. OpenVPN Server auf seinen default Port oder gibt es einen Grund für die doppelte Belegung? Wenn du so Proxies o.ä. umgehen willst lass dir gesagt sein: Ein guter Netzwerk-Admin erkennt auch dies und filtert es bei Bedarf und du kannst genauso gut den openVPN auf Port 53 laufen lassen (default für DNS Server), das wird oft vergessen zu filtern
2. Sicherung der Apache & Sites sowie Lets Encrypt Config und der Zertifikate
3. Apache, certbot usw. inkl. config vom System schmeißen und sauber von neuem beginnen und dann nicht irgendwelche Tutorials abschreiben sondern versuchen zu verstehen was da passiert oder nur an die Doku der jeweiligen Devs/Hersteller/Maintainer halten.

 

[Crys]

[...] oder gibt es einen Grund für die doppelte Belegung?

Ich war lange zeit in China und da waren sämtliche VPN-Ports durchweg blockiert. Eine Verbindung über das https-Port hat aber (zumindest letztens noch) immer geklappt
Außerdem sind in vielen öffentlichen Netzwerken (wie hier an der Uni) nur wenige Ports frei, wie 80 und 443. Deshalb benötige ich die Umleitung auch jetzt noch.

[...] und dann nicht irgendwelche Tutorials abschreiben sondern versuchen zu verstehen was da passiert oder nur an die Doku der jeweiligen Devs/Hersteller/Maintainer halten.

An ein neu aufspielen habe ich auch schon gedacht, aber das mit dem "verstehen" ist nicht so einfach ... sonst müsste ja niemand IT studieren (was ich auch nicht getan habe)
Wenn ich es verstehen würde, dann hätte ich das Problem ja schon gelöst ... aber ich kann einfach von neuen mein Glück versuchen und hoffen das es dann wieder ein paar Jahre gut geht
Weil eine 1:1 Anleitung gibt es eben im Internet nicht und auch keine Leute die einen alle erdenklichen Fälle aufbereiten oder einem erklären können.

Ich werde die Tage aber mal meinen OpenVPN deaktivieren und schauen ob es im status quo mit den std. Ports des Apaches läuft.

 

[snaxilian]

Dafür muss auch niemand Informatik studieren, für den Privatgebrauch reicht analytisch denkende Fähigkeiten als Grundlage und wer so etwas beruflich programmieren oder administrieren will, für den gibt es den Fachinformatiker in den jeweiligen Richtungen.
Studium ist da nice to have aber keine zwingende Voraussetzung.