Certbot-auto ohne offenen Port 80 / Problem mit tls-sni-01 Option

Hallo zusammen,

für unsere WebUntis Anbindung wollte ich ein Zertifikat erzeugen, damit ich die Authentifizierung in WebUntis von LDAP auf LDAPS umstellen kann.

Nach dieser Anleitung habe ich certbot-auto installiert:
https://www.linuxmuster.net/wiki/anwenderwiki:server:ssl-tls-letsencrypt

Da der Standartport 80 bei uns im Router dicht ist, wollte ich die Zertifkate nicht so

certbot-auto certonly --apache --email administrator@meineschule.de -d server.meineschule.de

sondern so (angelehnt an die alte Anleitung anwenderwiki:server:ssl-tls-letsencrypt-alt [CommunityWiki] )

certbot-auto certonly --standalone --preferred-challenges tls-sni --email administrator@meineschule.de -d server.meineschule.de

erzeugen.

Leider klappt das nicht:

Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

Eine Recherche hat ergeben, dass in dieser certbot Version wegen (bekannter) Sicherheitsrisiken die Option TLS-SNI deaktiviert wurde.

Frage in die Runde:
Wie geht ihr vor, um die Zertifkate zu erstellen?

Besten Dank im Voraus.

Viele Grüße
Manuel

Hi Manuel,

zwei Lösungen habe ich bisher implementiert, eine noch nicht probiert

  1. 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)
  2. du nimmst einen reverse proxy, der LE-Zertifikate für dich erstellt, z.B. traefik, ha-proxy oder nginx, siehe z.B. Docker multi fomaggi: Cloud, MRBS, Office, gitlab, vplan, LE über docker für ein Beispiel, darin auch Links zu ha-proxy lösungen von anderen
  3. 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.

VG, Tobias

1 „Gefällt mir“

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

Hallo Tobias,

Habe es nun auch wie Variante 1 gelöst.

Vielen Dank!

Hallo,

…also bei mir nicht: Ich musste den Port 80 explizit wieder öffnen.

Gruß
Christoph G.

Hallo,

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:

aber ohne durchschlagenden Erfolg.

Viele Grüße

Wilfried

Lieber Wilfried,

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…

L.G.
Christoph Gü

P.S. Teste das von außen mit nmap !

Hallo Wilfried,

Wir sind auch bei Belwue.
Port 80 musste zunächst im Router von Belwue geöffnet werden.

Liebe Grüße Manuel

Hallo Christoph und Manuel,

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.

Viele Grüße, Wilfried

Hallo Tobias,

ich hatte das selbe Problem mit tls-sni und auch bei BelWü Port 80 aufmachen lassen. Der Redirect funktioniert auch.

Ist das sicherer als Redirect und wie sieht Deine port.conf aus? Bei mir taucht port 80 nur auskommentiert aus:

#Listen 80

Trotzdem geht der redirect und auch der certbot dry-run. Sollte ich irgendwie auf dem Server Port 80 dicht machen?

Danke für Tipps

Max

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.

Hallo zusammen,

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:

ufw allow OpenSSH
ufw allow 2222
ufw allow 80,443/tcp

Dann die Firewall einschalten:
ufw enable

Der Befehl ufw status führt zu folgender Ausgabe:

Status: active

To Action From
– ------ ----
OpenSSH ALLOW Anywhere
2222 ALLOW Anywhere
80,443/tcp ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
2222 (v6) ALLOW Anywhere (v6)
80,443/tcp (v6) ALLOW Anywhere (v6)

Außerdem funktioniert:

certbot renew --dry-run

und der Zugriff auf die Nextcloud sowie alle Apps (sind bei mir aber nicht viele).

Port 80 könnte mit ufw deny 80/tcp auch wieder geschlossen werden, solange er nicht gebraucht wird.

Viele Grüße

Wilfried

Hallo Tobias,

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 :slight_smile:
Mal sehen, ob es beim wirklichen neu machen des Zertifikats auch wirklich klappt.

LG
Max

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.

Wenn der ssh-Zugang durch Key-Authentification abgesichert ist, sollte das in diesem Bereich wohl reichen.

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…

VG, Tobias