zwei Lösungen habe ich bisher implementiert, eine noch nicht probiert
Port 80 temporär immer dann “freischalten”, wenn ich die challenge mache (auf dem lmn-server habe ich dafür port 80 in ports.conf des Apache aufgenommen, restartet und nach der challenge wieder rückgängig gemacht, so läuft port 80 zwar auf den Server aber immer ins Leere)
du nimmst den Typ “dns-01”, dafür musst du in deinem DNS einen record eintragen lassen, hab das noch nie selbst probiert. Gehe davon aus, dass mein Provider (belwue) das evtl. nicht macht.
… nur als Ergänzung und Rückfrage: War es nicht so, dass man nur bei der ersten Erstellung des Zertifikates unbedingt Port 80 benötigt und die Erneuerung danach auch verschlüsselt über 443 laufen kann? Ich meine, dass ich das irgendwo gelesen habe … !?
Da erinnere ich mich auch daran, aber das kann aus den Zeiten stammen als TLS-SNI noch funktionierte. Wie Manuel schreibt: Das SSL-VErfahren ist aus Sicherheitsgründen deaktiviert worden.
bei mir läuft die Nextcloud lokal auf einer ubuntu-18.04-VM im roten Netz. Die öffentliche IP ist von Belwü. Certbot kann die Zertifikate nicht erneuern, weil offensichtlichPort 80 fehlt. Ein “ufw status” ergibt ein “inactive”. Was muss ich tun, um Port 80 zu öffnen?
Langfristig sollte es aber eine “automatische” Lösung sein. Den Port temporär von Hand zu öffnen ist nicht akzeptabel.
Ich habe das Problem auch in der letsencrypt-community diskutiert:
ich grübele gerade darüber, wie Du Deine VM portmäßig angeschlossen hast: Offenbar betreibst Du alles virtualisiert und hast somit den Linuxmuster.net-Server auf den Ports 242 (Schulkonsole), den Ipfire auf 444 (auch virtualisiert) und dann eben die VM für die Nextcloud mit eigenem apache.
Wenn das so ist, hast Du die Ports gemappt: Zumindest den https-Port 443 der Nextcloud / Apache müsste bereits durchgeleitet / gemappt sein auf ROT, also am IpFire vorbei. Diese “Weiterleitung” müsste man auch für den Port 80 einrichten: Also, die Nextloud-VM Port 80 auf das rote Netzwerk legen (meinem Verständnis nach !). Ferner muss bei mir - ich bin nicht an einem Belwü, sondern an einem handelsüblichen Speedport-Router - dort der Port 80 ebenfalls freigeschaltet sein und auf “Rot” zeigen…
ja, das Netz sieht so aus, wie Christoph vermutet hat.
Nachdem ich den Port für die über Belwü bezogene öffentliche Adresse habe freischalten lassen, flutscht es mit certbot, zumindest beim “dry-run”.
Danke für die Anregungen.
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.
ich habe mal ein paar Schritte durchgeführt, um das Ganze etwas sicherer zu machen (Ubuntu Server 18.04).
In der /etc/ssh/sshd_config wurde der Standardport von 22 z. B. auf 2222 geändert und ssh mit service ssh restart neu gestartet.
Vor dem Einschalten der Firewall (Gefahr des Aussperrens, sofern man mit ssh auf den Server zugreift) habe ich folgende Befehle abgesetzt:
root@nextcloud:~# netstat -l -t -n -p
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 1080/mysqld
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 1060/redis-server 1
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1047/sshd
tcp6 0 0 :::22 :::* LISTEN 1047/sshd
tcp6 0 0 :::443 :::* LISTEN 7391/apache2
root@nextcloud:~#
so wie es aussieht, ist 80 zu. Trotzdem werde ich von extern redirected und certbot --dry-run funktioniert:
root@nextcloud:/opt/letsencrypt# ./letsencrypt-auto certonly --dry-run --renew-by-default --standalone --email <habichrausgelöscht> -d owncloud.eichendorff-gymnasium.de
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for owncloud.eichendorff-gymnasium.de
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- The dry run was successful.
und die letzten 2 Zeilen sogar in ROT
Mal sehen, ob es beim wirklichen neu machen des Zertifikats auch wirklich klappt.
222 oder 2222 macht das Ganze nicht sicherer, nmap scannt die beiden Ports per default durch, wird also im Vorbeifahren mitgenommen. Die Ports da unten eignenen sich nicht zum Verstecken.
Port 22222 waere wohl bzgl. Sicherheit die bessere Wahl, die Ports da oben laesst nmap in Grundeinstellung weitgehend in Ruhe, wieso weiss ich nicht, denn in der nmap-services gibt es hierfuer eigentlich noch vereinzelt Eintraege, die gescannt werden sollten (auch fuer die 22222). Ich denke da spielt auch eine Rolle, wer das Ganze wie durch den Compiler presst.
Ich halte sowieso nicht viel von Versteckspielchen, die machen eine eigentlich nur selbst irre.
Hi Max,
sorry, ich weiß gar nicht mehr worüber wir hier genau diskutieren: --standalone steht dafür, dass dein certbot den Port 80 während des UPdate-prozesses selbst öffnet und darauf lauscht. Ohne standalone müsste der Apache auf port 80 lauschen…
Der ursprüngliche Post von Manuel war ja: tls-sni-01 funktioniert nicht, und http-01 geht nicht, weil der Port 80 vor dem Rechner zu ist.
Ich lese grade nach, dass der Weg zu deinem Port 80 offen ist, also auch kein Wunder, dass es funktioniert.
Mit “Redirect” meist du die Firewall weiterleitung von Belwue:80 auf deine cloud:80, richtig?
Ob du also certbot --standalone nimmst oder den Apache und dort immer port 80 auf und zu machst, ist meiner Ansicht nach völlig gleich sicher.
Ich kann dir also nicht mal mehr sagen, warum ich das früher so mit “an/aus”-schalten gemacht habe, vllt. hat linuxmuster-dehydrated keinen standalone-modus und braucht also den apache…
