Hi Max (und die anderen),
zum Thema: Apache port 80 an und ausschalten (automatisch):
da hatte ich das dokumentiert und dann Franks „dehydrated“ genommen.
Ich bin nicht mehr auf dem Laufenden, da ihr alle „certbot“ verwendet (das ist das LE-präferierte tool, richtig?).
Und zu deiner Frage: Wenn ich in der ports.conf den „Listen 80“ auskommentiere (das ist, was bei mir das hook-skript im anderen thread automatisch macht(e)), dann hat auch der certbot keine Chance (glaube ich, testen will ich das nicht) ein dry-run auch nicht. ein „apache2 restart“ ist selbstverständlich nötig.
Wenn bei dir port 80 auf dem Server weiterhin offen ist (checke mal mit netstat -l -t -n -p), obwohl #Listen 80 in der ports.conf steht, dann habe ich einen denkfehler oder du einen konfigurationsfehler.
Und wenn der Port 80 zu ist, dann sollte der certbot auch nicht funktionieren können.
Ob jetzt Redirect oder ausschalten? Da ist nur ganz hypothetisch ausschalten besser, weil man dem apache2 gar keine Chance mehr gibt buggy zu antworten, auch nicht mit einem redirect.
Sorry, dass ich nicht mehr in der Materie drin bin. Seit linuxmuster-dehydrated hatte ich mir keine Gedanken mehr gemacht und seit „docker“ kam, habe ich dehydrated abgestellt und mache alles mit einem reverse-proxy auf dem docker-host.
Das Prinzip davor ist aber immernoch dasselbe: von außen werden Port 80 Anfragen an den reverse-proxy (docker-host) geleitet, sonst nirgends mehr hin.
VG, Tobias
P.S: Jetzt noch ein Kommentar zu den docker-geschichte vs. automatischem An- und Abschalten von Port 80: Seit ich einen reverse-proxy in docker habe, mache ich mir keine Gedanken mehr um die Port 80 Anfragen und das ist sicherheitstechnisch ein Fehler, denn ich weiß nicht wirklich wie der Webserver der die Port 80 Anfragen annimmt funktioniert. Denn z.B. eine Anfrage an http://cloud.meineschule.de wird bei mir server-seitig per HSTS auf https://cloud.meineschule.de umgeleitet. Ich habe grade keine Ahnung, wie der Reverse Proxy es schafft, Letsencrypt-validations davon zu überzeugen, nicht bei https sondern bei http://cloud.meineschule.de/.well-known/usw. nachzufragen und dort eine Antwort zu kriegen.
Die Variante, Port 80 nur für den Zeitraum einzuschalten, finde ich immernoch charmant und sicherer, solange es zuverlässig funktioniert. Leider weiß ich wegen der nicht von mir geschriebenen Automatismen, ob mein reverse-proxy das überhaupt könnte.
Fazit: Automatismus + Docker sind nicht zwangsläufig besser als certbot und apache2-an-aus.