3
OPNsense, Radius, Wifi, Lets encrypt
Hallo in die Runde,
das Thema Zertifikat – und vor allem die praktische Umsetzung – ist mir leider immer noch etwas unklar. Ich dachte, ich probiers mal mit "learning by doing" und jetzt stehe ich da ich armer, dummer Tor 😉
Gegeben sei
a) eine aktuelle OPNsense,
b) ein ACME-Client-Modul, welches über DNS-01 von ipv64.net ein Zertifikat (Last ACME-Status: OK) erhält
c) dieses Zertifikat ist unter System>Settings>Administration unter HTTPS ausgewählt
d) dieses Zertifikat ist unter Services>FreeRadius>ausgewählt (Root&Server, ferner MSCHAPv2, prime256v1)
e) dieses Zertifikat UND den Schlüssel habe ich "downgeloadet" oder "loadete ich down"(?) und importiertete es in meinen Ruckus R320 unter Administration>Zertifikat>Signiertes Zertifikat.
Feststellungen, bzw. Fragen:
1. Rufe ich am nächsten Tag meine OPNsense über Safari auf, mosert der doch tatsächlich wegen des Zertifikats rum. Also im Prinzip wie vorher auch schon. Nur ist es jetzt das LetsEntcrypt-Zertifikat. Warum klappt das nicht mal in diesem Fall?! Das wäre doch die Minimal-Erwartung?!
2. Nach dem Import des Zertifikates in den Ruckus fällt auf, dass sich dieser im Browser so nennt, wie das Zertifikat (test.ipv64.net/admin/dashboard.jsp). Auch wenn ich ihn wie gewohnt über die lokale IP aufrufe, wird der URL-String geändert. Warum ist das so? ABER ne Zertifikate-Warnung vom Browser erhalte ich hier nicht 😁
3. Radius-Auth: Als ich Punkt d) noch nicht vorgenommen hatte, moserte ein iOS-Client bei der Radius-Auth am Ruckus, dass er dem Radius-Zertifikat nicht vertraue. Ich habe dann das Lets-Entcrypt wie unter d) beschrieben hinterlegt ... jetzt mosert er, dass er dem LetsEncrypt-Zertifikat nicht vertraut?! Wtf?
Müssen die Geräte- bzw. Hostnamen evtl. doch dem Zertifikat-Namen entsprechen?! Und wenn ja, kann ich lokal ja schlecht die TLD (.net) übernehmen?!
Und überhaupt, wo ist der Denkfehler?!
PS: Mir ist – glaube ich – schon bewusst ("klar" wäre ein zu großes Wort), dass es (vermutlich?) nicht üblich ist, überall das gleiche Zertifikat zu hinterlegen 😉
PPS: Das mit dem Reverse Proxy will ich erst im nächsten Schritt angehen – das ist "much more spooky" für mich 😉
PPPS: @aqui Ich habe Deine kritische Antwort bzw. Deine Bedenken bzgl. CA schon gelesen – aber ich bin auch ein (bayerischer) Dickkopf 😉
das Thema Zertifikat – und vor allem die praktische Umsetzung – ist mir leider immer noch etwas unklar. Ich dachte, ich probiers mal mit "learning by doing" und jetzt stehe ich da ich armer, dummer Tor 😉
Gegeben sei
a) eine aktuelle OPNsense,
b) ein ACME-Client-Modul, welches über DNS-01 von ipv64.net ein Zertifikat (Last ACME-Status: OK) erhält
c) dieses Zertifikat ist unter System>Settings>Administration unter HTTPS ausgewählt
d) dieses Zertifikat ist unter Services>FreeRadius>ausgewählt (Root&Server, ferner MSCHAPv2, prime256v1)
e) dieses Zertifikat UND den Schlüssel habe ich "downgeloadet" oder "loadete ich down"(?) und importiertete es in meinen Ruckus R320 unter Administration>Zertifikat>Signiertes Zertifikat.
Feststellungen, bzw. Fragen:
1. Rufe ich am nächsten Tag meine OPNsense über Safari auf, mosert der doch tatsächlich wegen des Zertifikats rum. Also im Prinzip wie vorher auch schon. Nur ist es jetzt das LetsEntcrypt-Zertifikat. Warum klappt das nicht mal in diesem Fall?! Das wäre doch die Minimal-Erwartung?!
2. Nach dem Import des Zertifikates in den Ruckus fällt auf, dass sich dieser im Browser so nennt, wie das Zertifikat (test.ipv64.net/admin/dashboard.jsp). Auch wenn ich ihn wie gewohnt über die lokale IP aufrufe, wird der URL-String geändert. Warum ist das so? ABER ne Zertifikate-Warnung vom Browser erhalte ich hier nicht 😁
3. Radius-Auth: Als ich Punkt d) noch nicht vorgenommen hatte, moserte ein iOS-Client bei der Radius-Auth am Ruckus, dass er dem Radius-Zertifikat nicht vertraue. Ich habe dann das Lets-Entcrypt wie unter d) beschrieben hinterlegt ... jetzt mosert er, dass er dem LetsEncrypt-Zertifikat nicht vertraut?! Wtf?
Müssen die Geräte- bzw. Hostnamen evtl. doch dem Zertifikat-Namen entsprechen?! Und wenn ja, kann ich lokal ja schlecht die TLD (.net) übernehmen?!
Und überhaupt, wo ist der Denkfehler?!
PS: Mir ist – glaube ich – schon bewusst ("klar" wäre ein zu großes Wort), dass es (vermutlich?) nicht üblich ist, überall das gleiche Zertifikat zu hinterlegen 😉
PPS: Das mit dem Reverse Proxy will ich erst im nächsten Schritt angehen – das ist "much more spooky" für mich 😉
PPPS: @aqui Ich habe Deine kritische Antwort bzw. Deine Bedenken bzgl. CA schon gelesen – aber ich bin auch ein (bayerischer) Dickkopf 😉
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 54280757057
Url: https://administrator.de/forum/opnsense-radius-wifi-lets-encrypt-54280757057.html
Ausgedruckt am: 23.12.2024 um 16:12 Uhr
3 Kommentare
Neuester Kommentar
Wow 685 Aufrufe ... keinerlei Antwort.
Ist das Thema um diese Zertifikate so komplex oder so trivial, dass mich keiner bloßstellen möchte?! 🤣
Ich will doch nur wissen, warum das so ist, wie es bei mir ist. Vielleicht ist das ja auch nur bei mir so, weil ich irgendwo nen Bockmist gebaut habe. Aber doch zumindest auf der OPNsense sollte das Zertifikat doch funktionieren?!
Oder fangen wir anders an: Ist das oben skizzierte Verhalten erwartbar in meinem Setups?
Oder muss der Name des Gerätes irgendwie - doch - zum Zertifikat passen?! Der Ruckus entwickelt mit Zertifikat ja sozusagen ein Eigenleben.
Ist das Thema um diese Zertifikate so komplex oder so trivial, dass mich keiner bloßstellen möchte?! 🤣
Ich will doch nur wissen, warum das so ist, wie es bei mir ist. Vielleicht ist das ja auch nur bei mir so, weil ich irgendwo nen Bockmist gebaut habe. Aber doch zumindest auf der OPNsense sollte das Zertifikat doch funktionieren?!
Oder fangen wir anders an: Ist das oben skizzierte Verhalten erwartbar in meinem Setups?
Oder muss der Name des Gerätes irgendwie - doch - zum Zertifikat passen?! Der Ruckus entwickelt mit Zertifikat ja sozusagen ein Eigenleben.
Ist das Thema um diese Zertifikate so komplex oder so trivial, dass mich keiner bloßstellen möchte?! 🤣
Glaube eher das letztere 😂. Und das als Level 5 😀.Oder muss der Name des Gerätes irgendwie - doch - zum Zertifikat passen?!
Logisch, wozu sonst hat ein Zertifikat einen Common-Name und SANs (Subject Alternative Names)? Genau, um den Host mit seinem Namen zu beglaubigen, sonst könntest du dich ja einfach als Google ausgeben wenn der Name im Cert wurscht wäre.Wenn du also mehrere Geräte intern absichern willst musst du entweder ein Multidomain Zertifikat oder ein Wildcard-Zertifikat ausstellen lassen.
Ein Wildcard-Zertifikat musst du bei Let's Encrypt aber per DNS-Methode beglaubigen lassen, damit ist man intern aber wesentlich flexibler was die Namensvergabe betrifft.
Aber es gilt auf jeden Fall das der FQDN mit dem du einen Dienst aufrufst zwingend in den SANs des Zertifikats enthalten sein muss damit du keine Trustfehler erhältst!
Eine externe CA wie LE ist auch nicht zwingend nötig, du kannst auch problemlos eine eigene interne CA betreiben und diese in deinen Geräten als vertrauenswürdige Root-CA markieren und damit entsprechende Zertifikate für deine Geräte und FQDNs signieren. Nur wenn externe User auf deine angebotenen Dienste zugreifen wollen, sollte man auf LE Zertifikate zurückgreifen, da man bei diesem ja bekanntlich keinen Einfluss auf die Root-CAs hat.
✌️
1Glaube eher das letztere 😂. Und das als Level 5 😀.
Na, na na, nicht so gehässig. Immerhin habens schon knapp 1.000 Leute gelesen ... und sich kein "Lösungs-Pickerl" ins Heftl kleben lassen. Mein Level 5 habe ich ja nicht (nur) auf Grund meiner sicherlich hervorragenden Lösungsvorschläge 😇, sondern vor allem wegen der vielen tiefschürfenden Fragen die ich - übrigens hier als "Enduser" gelistet – der Community überantworte. Ganz dem Motto: Lieber dumm fragen als dumm sterben! 😉Spaß beiseite: Das mit dem Namen klingt bestechend logisch. Bei meinen Recherchen im Vorfeld hatte ich da leider eine Antwort in den falschen Hals bekommen und bin in der Folge "vom rechten Pfade abgekommen".
Das umfasst also auch nicht nur z.B. den Hostnamen oder andere Teile des FQDN, sondern den kompletten String von der TLD kommend bis zum Host runter.
Aber es gilt auf jeden Fall das der FQDN mit dem du einen Dienst aufrufst zwingend in den SANs des Zertifikats enthalten sein muss damit du keine Trustfehler erhältst!
Das heißt aber auch, dass ich meine OPNsense umbenenne in den zertifizierten Hostnamen und dass ich die Domäne anpasse. Bisher hatte ich hier meinedomaene.internal ... muss jetzt zu ipv64.net werden. Ist das so korrekt? Bin nämlich in der Vergangenheit damit aufgewachsen dafür niemals nicht "öffentliche" TLDs zu nehmen.Gleiches Vorgehen bei evtl. vorhandenen Overrides im UnboundDNS.
Ein Wildcard-Zertifikat musst du bei Let's Encrypt aber per DNS-Methode beglaubigen lassen
DNS-01 nutzte ich zwar jetzt schon – Wildcard dürfte über meinen DDNS-Dienst mangels Kontroll über die Domäne wohl schwierig sein. Das hieße vermutlich, ich benötige mindestens einen vServer und ne eigene Domäne, die auf diesen zeigt. Anschließend lasse ich diesen gegen LetsEntrypt zertifizieren und übertrage mir Zertifikat&Schlüssel ins lokale Netz? Ist das so richtig?! Oder könnte ich den vServer auch mit meinem acme-Modul überspringen?!Im acme-Modul gäbe es ja auch die Option von "Alt Names". Damit könnte ich mir doch alle nötigen Host-Namen eintragen. Sozusagen ein Multi-Host-Zertifikat. Nochmal ne doofe Frage: lokale IP-Adressen kann ich mir da nicht verifizieren lassen, weil die nicht eindeutig wären (Pfad) – nehme ich mal an?
Eine externe CA wie LE ist auch nicht zwingend nötig, du kannst auch problemlos eine eigene interne CA betreiben und diese in deinen Geräten als vertrauenswürdige Root-CA markieren und damit entsprechende Zertifikate für deine Geräte und FQDNs signieren.
Das hatte ich soweit schon verstanden, mich nur dickköpfig mit der LE-Lösung auseinandersetzen wollen. In meiner Naivität vor diesem Thread hier, hatte ich eigentlich überlegt, lokale CA-Zertifikate um 1-2 LE-Zertifkate für die Wifi-Zertifizierung zu ergänzen. Aber jetzt verstehe ich, dass das ja gar nicht funktionieren kann, weil ich ja nur eine Domäne&TLD im Netz praktisch einsetzen kann.Ich habe natürlich unter der Prämisse in den letzten Tagen einiges rumprobiert. Aktuell nutze ich 2 LE-Zertifikate – eines für die OPNsense und eines für den Ruckus. Hostnamen entsprechend angepasst, ebenso die Domäne.
Was ich noch nicht verstehe ist das unterschiedliche Verhalten von OPNsense zu Ruckus:
a) Den Ruckus rufe ich über IP auf und der wechselt automatisch zu seinem DNS-Namen/Zertifikatenamen und meckert dann nicht, weil er ja ein passendes LE-Zertifikat hat.
b) Die OPNsense bleibt bei ihrer lokalen IP (URL-Feld des Browsers) und weil die IP nicht zertifiziert ist, kommt in der Folge die Zertifikatewarnung. Rufe ich sie über ihren zertifzierten DNS-Namen auf, flutscht es aber (dauert allerdings recht lange).
c) Der FreeRadius läuft als Service auf der OPNsense, unter EAP ist das opnsense-LE-Zertifikat ausgewählt, im Ruckus ist der Radius über seinen FQDN (opnsense...ipv64.net) hinterlegt, ... und trotzdem mosert iOS bei der Wifi-Verbindung wegen des Zertifikats "Wird nicht vertraut". Woran kann denn das jetzt noch liegen?!
