Frage zu Zertifikaten bei Freeradius WLAN

Hallo zusammen,

ich habe vor ca. 2 Jahren die Freeradius Authentifizierung genau wie beschrieben eingerichtet. Das läuft auch super.
Wenn sich ein Client das erste Mal verbindet muss man noch ein Zertifikat anklicken „unsichere Verbindung“. Da ich das vor zwei Jahren weggeklickt habe, ist es mir erst jetzt durch Zufall wieder auf den Schirm gekommen - die KuK haben es wohl auch einfach abgenickt.

Die Erzeugung eines Zertifikats kommt in der Linuxmuster-Anleitung im Gegensatz zu hier nicht vor und irgendwie bin ich durcheinander, welches Zertifikat der Freeradius braucht.

Hat jemand einen Tipp (Stichwort: Snake-Oil-Zertifkate loswerden)? Soll ich lieber gleich auf Freeradius 3 Upgraden und dann Zefanjas Anleitung befolgen? Lieber wäre mir aber ein gültiges Zertifikat. Kann ich da auf das vom Server verweisen?

viele Grüße
Manuel

P.S.: Linuxmuster 6.2, Freeradius Version 2, Unifi-WLAN, gültiges LetsEncrypt-Zertifikat für den Server vorhanden.

Hallo Manuel,

das ist nicht so einfach, weil der Radiusserver aus dem Internet nicht
erreichbar ist: also geht ein Letsencrypt Zertifikat nicht so ohne weiteres.

Ein gangbarer Weg wäre: auf dem server wird ein LE certbot eingerichtet,
der ein Wildkard Cert erneuert und einen hook hat, der das Cert auf den
Radius bewegt.
Einziges Problem dann: der radius muß über seinen Namen angesprochen
werden: und der muß zum wildcard Cert passen UND der DNS muß den
richtigen Namen zurückmelden.

Alles in allem ein ganz schönes rumgewürge: mir ist das zuviel.
Vielleicht mach ich das in ein paar Jahren mal: derzeit gibt es
SnakeOil: so ist das halt.

LG

Holger

Hallo.
Passt zu der Frage, die ich bzgl LE und v7 auch gerade habe …
Das Verteilen der erneuerten Zertifikate kann man evtl hiermit machen?!

https://www.dxsdata.com/de/2017/05/distributing-letsencrypt-ssl-certificates-in-lan/

Bin nicht mehr sicher, ob @Tobias so etwas ähnliches auch schon gemacht hatte?!
hth,
Michael

mit einem reverse proxy geht das natürlich.
wenn der radiusserver unter seinem offiziellen namen von extern auf den revproxy (oder auf einen LE-server weiter-) gelenkt wird, dann kann man dort LE-Zert erstellen und sie dort abholen und dem radius unterschieben.
Ich mache das momentan noch mit docker/proxy-le-companion vom docker/jwilder-nginx, habe aber vor auf die struktur von frank umzusteigen, dann kann der dockerhost das übernehmen. Ja, vermuztlich geht auch all das auf der OpnSense, i’m wary about that,

VG, Tobias

Hallo @Tobias.

Auf diese Antwort hatte ich gehofft :slight_smile:
Wenn ich das richtig sehe, ist das doch genau der docker-Host, der beim lmn70-Setup mit installiert wird, oder? Dahinter steckt ja ebenfalls ein abgewandelter jwilder-nginx , oder? Auf dem docker-Host bin ich bisher nicht sonderlich weit gekommen, wie man hier sieht.

Ich blicke in Sachen LE und Verteilung der Zertifikate aber offenbar noch nicht vollständig durch. Wenn es „nur“ darum ginge, einen Webdienst von außen in orange/rot erreichen zu können, wäre die Sache einfach. Aber: daaaaamals war es ja immer ein Problem, dem Server selbst ein gültiges Zertifikat unterzuschieben. Daher hatten ja einige den Servernamen auf einen FQDN umgestellt, um das zu ermöglichen (Zugriff Schulkonsole etc). Wenn die LE-Zertifikate jetzt über einen Rev.Proxy abgewickelt werden, müssen aber doch alle Services dahinter (uU in den unterschiedlichsten Netzen) trotzdem einen FQDN haben, wenn sie gültige Zertifikate erhalten sollen, oder?? In einem anderen Thread wurde schon angemerkt, dass man die Zertifikate immer auf Domänennamen, nicht aber auf IPs ausstellt … das heißt also, dass die Sicherheitsmeldung im Firefox auch weiterhin erscheint, wenn ich https://10.16.1.1 verwende, ja?

Vielleicht kannst du den Nebel ja nochmal etwas lichten…
Schönen Gruß,
Michael

HI @Michael, bin ab jetzt 3 Tage offline, antworte mal ausführlich danach…VG; Tobias

Hallo @Tobias – wieder am Start?

Hallo Michael,

naja, ich rede von einem docker-host für externe Dienste wie Collabora, Cloud (wer will), moodle, mrbs, limesurvey, apt-cacher, … dafür will ich einen docker-host aufziehen, wie es Frank vorgeschlagen hat, bin aber noch nicht dazugekommen.

Der andere: der beim lmn7-setup installierte dockerhost ist für interne Dienste gedacht: momentan eben nur e-mail-server, aber auch alles, was man intern halten will (moodle?,…usw). Und ja, da hat Frank auch seine Finger im Spiel, aber hier wurde ein von Thomas erstmal jwilder-nginx proxy installiert.

Ja, wenn letsencrypt für dich ein gültiges Zertifikat ausstellen soll, dann geht das nur für einen FQDN und nicht für „server.linuxmuster.lan“ oder „10.16.1.1“.

Ja, richtig.

Jetzt kommt das aber:

  • Du kannst intern „server.linuxmuster.lan“ als hostnamen den Servers haben und alle deine Hosts haben die Domäne „linuxmuster.lan“.
  • Dann besorgst du dir über ein Verfahren LE-ZErtifikate für z.B: „server.meine-schule.de“ und „cloud.meine-schule.de“ usw. und schiebst dem Server sowie der Cloud diese Zertifikate unter.
  • Von außerhalb kommst du jetzt ohne Warnung an Server und Cloud
  • Von innerhalb aber nicht, da „https://server.linuxmuster.lan“ oder „https://10.16.1.1“ ein „falsche“ Zertifikat ausliefern.
  • Daher habe ich in der Firewall-DNS Ausnahmen definiert, nämlich, dass „server.meine-schule.de“ nach 10.16.1.1 auflösen soll und „cloud.meine-schule.de“ nach der internen IP der cloud, z.B: 172.16.17.1

Jetzt habe ich intern und extern unterschiedliche Domänen und trotzdem komme ich von intern und extern an die Rechner ohne Zertifikatswarnung.

Wichtig: Du solltest deine Use-Cases abklopfen. Überall dort, wo Endbenutzer mit dem FQDN in Berührung kommen, gibt es früher oder später ärger. Überall dort wo dritte Parteien-Server (wie webuntis) an den FQDN deines SErver in Berührung kommen, gibt es Ärger.
Aber überall anders, wo also nur Maschinen (von dir kontrolliert) mit den services und servern kommunizieren kannst du auf selbst-signierte Zertifikate unterschieben.

Ich habe z.B. kein Webunits, daher habe ich dem Server-LDAP kein LE-Zertifikat untergeschoben. Die SChulkonsole auf dem SErver hat aber Kontakt mit Endbenutzern, z.B. BYOD etc. Daher hat meine Schulkonsole ein LE-Zertifikat und ich kontaktiere die Schulkonsole über „https://server.meine-schule.de“ statt https://server.linuxmuster.lan

VG, Tobias

Ach so,

ob du die LE-Zertifikate jetzt über den externen docker-host oder den internen dockerhost oder die OpnSense oder anders machst, ist fast egal. Auch hier use-cases anschauen. Beispiel bei mir:

  • unsere Cloud ist aus PErfomanz jetzt nicht mehr hinter einem reverse proxy, sondern hat eine eigene IP, daher muss das LE-gedöns auch auf der Cloud selbst erfolgen.
  • alle anderen Dienste sind bei uns hinter dem Proxy, der dafür die Zertifikate besorgt und auch für die DIenste handelt, die hinter dem Proxy liegen (z.B. unser Vertretungsplandienst: läuft auf dem dockerhost mit dem proxy, der proxy macht den https-trafik, der vertretungsplan kann nur http) von intern wie extern greife ich auf demselben Wege zu.
  • ebenso verteile ich die Zertifikate für die Dienste die zwar hinter dem Proxy liegen, aber nicht auf dem proxy-host liegen, z.B. für die Schulkonsole: der Proxy besorgt das LE-Zertifikat und wenn ich von außen zugreifen könnte, dann würde der Proxy auch das Zertifikat ausliefern. Von intern greife ich aber direkt auf 10.16.1.1 zu (siehe letzter post mit den DNS-Ausnahmen) und dann muss die Schulkonsole ja selbst die Zertifikate haben, also muss das Zertifikat von proxy zu Server kopiert/verteilt werden.

du siehst: andere länder, andere sitten. oder so ähnlich.

VG, tobias

Hallo zusammen,

ich möchte auch gerne die Zertifikate durch eine Maschine holen lassen und dann verteilen. Optimalerweise sogar ein WildCard Zertifikat.

Darum meine Idee: kleine VM oder sowas wie ein RaspberryPi in die DMZ stellen und der holt sich dann das WildCard-Zertifikat. Anschließend verteilt er es per „hook“ auf die andere Rechner. Dafür muss er natürlich Zugriff per SSH auf die anderen Server haben.

Was meint ihr, ist das ein Sicherheitsrisiko?

Der Server/Schulkonsole und Unifi sind jetzt schon über „Server.meine-Schule.de“ von innnen erreichbar und haben schon Zertifikate. Nur muss ich bis jetzt alle 3 Monate von Hand die Firewall aufmachen, auf den richtigen Server lenken und die Zertifikate holen.

Viele Grüße
Manuel

P.S.: Linuxmuster.Net 6.2

Hallo @Tobias.
Ok, danke für deine ausführliche Darstellung. Ich sehe nun, wohin die Reise geht. Natürlich wäre es am schönsten, wenn man die DNS-Challenge von Let’s Encrypt nutzen könnte. Das ist aber nicht soooo einfach, weil man Kontrolle über den DNS-Server seines Anbieters haben muss. Wir sind mit unserer Schulhomepage bei HostEurope – da haben wir zwar einen vServer, doch leider unterstützt HE die automatische Verlängerung von LE-Zertifikaten immernoch nicht so, wie man sich’s vorstellt. Scheint eine ziemliche Krücke zu sein, da sie lieber eigene Zertifikate verkaufen wollen?!?

Übrigens: Bei der Installation der V7 hatte ich extra direkt einen FQDN gewählt – in der Hoffnung, dadurch um div. Probleme einen Bogen machen zu können. Jetzt lese ich, dass die Probleme dadurch erst anfangen :scream:? WebUntis haben wir momentan noch nicht – aber vielleicht künftig mal.

Ich bin weiterhin der Meinung, dass OPNSense selbst die LE-Zertifikate holen und erneuern sollte, da dort ja alles schon mit an Bord ist und man von dort problemlos in alle Netze gelangen kann. Ich habe mich daher nochmal anhand dieser Anleitung an die Sache herangewagt … und stecke fest: Der HAPrroxy soll bei mir in die DMZ (ehemals orange) umleiten und nicht nach grün, wie das in der Anleitung geschildert wird…

Bis später,
Michael

Ja, aber.
Der Use-Case, dass man die Cloud z.B. an einer eigenen IP-Adresse hat, die wird von der OpnSense-Lösung auch nicht abgedeckt. Aber prinzipiell ja: warum nicht die OpnSense nehmen, keine Frage. HAproxy ist dazu noch das umfassendere Tool. Muss man halt sich reinknien…
VG, Tobias

Hi.

… allerdings … HAProxy ist komplex.
Ich habe mir das Plugin angesehen. Die Bedingungen und Regeln sind komplex – aber die Einstellungen unter „Real Server“ sind extrem simpel. Erweiterungen/Änderungen für neue und später hinzukommende Hosts mit Port 80/443 wären damit dann relativ schnell angelegt und per WebGUI konfigurierbar. Zudem hätte man einen Load Balancer auf der FW gleich mit an Bord …

Übrigens beherrscht OPNSense offenbar auch das Kopieren der Zertifikate. Man kann ein Bsp für einen LDAP-Host auch hier finden:
Skript zum Kopieren der Zertifikate

→ Ein Vergleich der beiden
Schöne Grüße,
Michael

Hallo Manuel,

IMHO absolut ja! Wenn Du einen Rechner in der (vergleichsweise ungeschützten) DMZ hast, der, sofern er kompromittiert werden sollte, passwortlosen SSH-Zugriff auf alle Deine Server, NAS, etc. in den internen Netzen hat, dann ist alles zu spät!

Viele Grüße,
Jochen

Hallo Jochen,
ja, das stimmt - blöde Idee.

Dann doch lieber einen Rechner / eine VM in grün, die das Zertifikat holt (ich wollte eigentlich nicht den Server direkt nehmen)?. Die wäre dann halt dauerhaft auf Port 80 aus dem Internet erreichbar. Aber da kommt man wohl nicht drum rum - siehe Proxy-Post von Tobias.

Viele Grüße
Manuel

Hallo Manuel,

du kannst ja den Rechner, der die Zertifikate holt schon nach DMZ/rot/blau stellen, ich würde halt nicht von dort die Zertifikate verteilen, sondern der server in Grün holt sich die ZErtifikate ab, schaut ob sie neuer sind als die, die er schon hat und verteilt sie wieder.
Ich würde sogar den Server den LE-Prozess anstoßen lassen, also dort den cron-job einrichten.
Aber ein Raspi - weiß nicht, ob das nicht overkill ist… :slight_smile:
VG, Tobias

Hi @Brendle, hi @Michael,

weil ihr gestern drüber geredet habt, hab ich festgestellt, dass ich für die v7 die Verteilung der Zertifikate noch automatisieren muss…

Hier noch mein Script, wie ich die fertigen LE-Zertifikate vom Server aus herhole und dann verteile

in meiner Scriptsammlung:

VG und viel Spaß damit.
Tobias

2 „Gefällt mir“

Hallo Tobias,
vielen Dank. Das hilft mir weiter. Genau das, was ich brauche.
Danke!
Grüße
Manuel

Hi.
Nachdem ich Freitag schon kurz davor war, die ganze Sache hinzuschmeißen, gab es heute relativ überraschend einen Durchbruch: HAProxy läuft jetzt als reverse Proxy direkt auf OPNSense. :wink: Die schon mehrfach zitierte Anleitung funktioniert also!

Ich habe die Anleitung aber direkt in unsere DMZ umgebogen, so dass dort nun alle Webdienste angesiedelt werden können.

Was mir bis dato übrigens nie richtig klar war (da ich es vorher nie ausprobiert hatte): Man kann völlig problemlos in der workstations/devices-Datei auch Namen für IP-Adressen in der DMZ/orange vergeben und ist nicht auf das grüne Netz/LAN beschränkt. Das war einer der Stolpersteine bei der Namensauflösung und Umleitung über den Reverse Proxy.

Der nächste Schritt wird nun das LE-Plugin direkt auf der OPNSense-Firewall sein. Ich bleibe also dran und werde versuchen LE direkt dort laufen zu lassen.

Wenn das geschafft ist, wird’s nochmal eine Diskussion geben, wer die Zertifikate wohin kopieren darf. Wenn die FW selbst passwortlosen Zugang zu div. Rechnern in allen möglichen Netzen hätte, wäre das sicher nicht der Weisheit letzter Schluss. Daher kommt das Script von @Tobias hier evtl auch noch zum Einsatz, denn der Server kommt natürlich passwortlos auf die FW und kann sich die Zertifikate von dort holen und dann selbst weiterverteilen …

So long,
Michael

Hallo zusammen,

@Michael: klingt interessant. Wir sind ja noch auf 6.2 und jetzt klappt es so so:

  1. Der UniFi-Controller (läuft auf Ubuntu 18.04) holt sich per Certbot ein Wildcard-Zertifikat *.meine-Schule.de. Dazu muss man nicht mal einen Port aufmachen, da das dann über eine DNS-Challenge läuft. Allerdings braucht man ein Plugin für den Certbot und entsprechende Kontrolle über die Domain.
    Wir sind bei INWX und da gibt es das hier: (übrigens auch Docker-kompatibel) https://github.com/kegato/letsencrypt-inwx/blob/master/README.md

  2. Das Wildcard-Zertifikat wird dann mit Hilfe von @Tobias Anleitung an den Server und die Firewall (bald auch Nextcloud) verteilt. Das muss ich noch einrichten, aber das Kopieren von Hand hat schon geklappt und ein Zertifikat reicht für alles.

Für mich war jetzt das schöne, dass ich keinen Port öffnen muss und mir ein Wildcard-Zertifikat einfach gut gefällt.

Viele Grüße
Manuel