Richtig…den inner-tunnel läßt man am besten so wie er ist. Hab noch nie einen Grund gesehen, den anzufassen.
Richtig ist auch, wenn ich eine eigene CA betreibe, kann ich auch Zertifikate wieder einziehen und das ganze über eine sog. CRL (Certificate Revocation List) veröffentlichen. Diese CRL kann der RADIUS Server auch Überprüfen und Gerätern die mit zurückgezogenen Zertifikaten daher kommen, den Zugang verweigern.
Geht bei einer öffentlichen Zertifizierungsstelle nicht. Ich kann nicht an LE schreiben und denen sagen, zieht mal dieses und jenes Zertifikat wieder ein, weil sich damit wer in meinem WLAN authentisiert (kann ich schon, aber damit würde ich mich ziemlich lächerlich machen).
die opnsense hat eine eingebaute PKI…da kannst du dir eine eigene CA und Serverzertifikat für den RADIUS bauen und auf dem Server ablegen. Musst dann nur die Pfade in der in eap config anpassen.
Nicht das du dir am Ende noch den ganzen Server zerschießt.
Ja, das habe ich gesehen.
Ich lasse schon lange die LE-Zertifikate von der OPNSense zum v7-Server übertragen, um bei Aufrufen wie https://server.unsere-schule.de/… immer ein gültiges Zertifikat zu haben.
Aber offenbar ist die eine Datei dabei versehentlich unter die Räder gekommen; bzw war es offenbar auch nicht notwendig, sie mit zu kopieren. Hätte ich schon 2019 wissen sollen … da aber eh die OPNSense die LE-Zertifikate verwaltet, sollte die vielleicht auch den Rest erledigen
Alles, was Thomas (@tjordan ) hier geschrieben und erklärt hat, kann man am Beispiel SSL/TLS auch hier nochmal finden – angereichert um ein paar Bilder.
… und gut zu lesen, dass das offenbar auch andere Leute von dem Thema verwirrt sind
Hi.
Wo wir uns hier schon über die Theorie / best practice zu den Zertifikaten unterhalten, kann ich in diesem Thread gleich die nächsten Fragen loswerden…
mittlerweile angesehen und habe das genauso auf unserer OPNSense nachgemacht. Was mir nicht ganz klar ist: Warum erzeugen die pro Server eine komplett neue chain of trust? Warum reicht es nicht, nur einmal eine CA und intermediate-CA zu erstellen und anschließend alle Zertifikate darüber erstellen zu lassen? Scheint auf diese Art irgendwie sauberer zu sein – aber warum? Thomas (@tjordan) – Du weißt doch sicher wieder Rat?
Die zweite Sache, die ich auf der eigenen OPNSense-CA noch ausprobieren muss ist folgendes: Ich habe nach dem gleichen Muster eine chain of trust für den freeRADIUS-Server erstellt:
Und dann zwei Zertifkate erstellen lassen:
Das Server-Zertifikat würde ich im nächsten Schritt auf den lmn7-/freeRADIUS-Server kopieren und das Client-Zertifikat packe ich dann auf irgendein Tablet. Anschließend sollte die WPA3-Anmeldung direkt funktionieren …
Wenn ich das richtig sehe, könnte man nun theoretisch jedem User (sehr aufwändig) sein eigenes Client-Zertifkat verpassen, das man bei Bedarf dann auch zurückziehen kann. Alternativ kann man aber auch verschiedenen Gruppen ein Client-Zertifikat spendieren, so dass das Verfahren übersichtlich bleibt. Macht das jemand so? Wenn das klappt, kann man das sehr wahrscheinlich wirklich ganz einfach per relution verteilen lassen
grundsätzlich reicht auch eine Chain of trust…das ist etwas abhängig von der Größe der Organisationsstruktur. z.B. bei verschiedenen Standorten mit unterschiedlichen Subdomains könnte es Sinn machen auch noch intermediate CAs zu bilden. Oder wenn man nach Funktionionalitäten trennt. z.B. intermediate CA für Webserver, intermediate-CA für RADIUS, intermediateCA für LDAPS usw.
Hier ergibt sich das eher aus dem Handling der Zertifikate. Falls mal eine intermediate-CA kompromittiert werden sollte, muss ich nicht ALLE Zertifikate neu machen sondern nur die aus der jeweiligen Zwischenzertifizierungsstelle.
Es hängt wie gesagt, von der Organisationsstruktur ab. Bei einer einzelenen Schule sowas zu machen, wäre mir zu aufwendig. Mach ich aber Mehrschulbetrieb, macht das bilden der Zwischenzertifizierungsstellen wieder Sinn. Dann habe ich eine Root-CA und pro Schule auf dem Mehrschulbaum dann Zwischenzertifizierungsstellen. Beispiel Schulzentrum A hat Schule A1, A2 und A3. Die Root-CA gilt fürs gesamte Schulzentrum, und Schule A1, Schule A2, Schule A3 haben jeweils intermediate CAs.
Natürlich kann man auf der PKI der opnSense auch für jeden Benutzer ein Client bzw. Benutzerzertifikat bauen, aber dafür ist die an sich nicht gemacht. Für den Export- bzw. Import der Zertifikate muss ja auch der private Key exportiert (Kennwort erforderlich) werden. Beim Import auf dem Client muss das Kennwort, welches beim Export vergeben wurde, wieder eingegeben werden. Das läßt sich auf der opnSense so nur sehr umständlich abbilden. Das geht mit anderen Lösungen z.B. openxpki deutlich einfacher.
Bei verwalteten Geräten ist es sogar noch einfacher, wenn die PKI-Lösung (das macht die opnSense derzeit nicht) SCEP unterstützt. Dann wird vom MDM mittels API an der PKI ein Clientzertifikat für das jeweilige Gerät angefordert und automatisch installiert.
Ansonsten ist es auch möglicherweise (abhängig von der MDM-Lösung) machbar EIN Client-Zertifikat auf alle verwalteten Endgeräte ausrollen zu lassen. (Der Bereich MDM ist aber nun nicht unbedingt mein Spezialgebiet, daher will ich jetzt nicht sagen → Das geht so)
Im Bereich BYOD arbeitet man i.d.R. mit Client-Zertifikaten nicht.
Hallo Thomas,
alles klar – das klärt wieder einiges. Noch ist hier ja nicht viel passiert in Sachen OPNSense-PKI. Daher kann ich alles noch beliebig löschen oder neu anlegen.
Dass das automatische Erzeugen der Client-Zertifikate nicht eingebaut ist, ist aber nicht so schlimm, wenn man z.B. nur eine Gruppe „Lehrer-Tablets“ damit ausstatten will, denke ich?!
Man kann doch für solche Gruppen auch problemlos das gleiche Zertfikat verwenden. Wenn ich das richtig gesehen habe, kann man das auch so auf’s Gerät schieben. Ob dazu wirklich SCEP unbedingt notwendig ist, weiß ich bisher nicht.
Viele Grüße,
Michael
nein SCEP ist dafür nicht notwendig. SCEP ist quasi das Zuckerl auf der Sahne. Damit kann man automatisiert beim Enrollment für jedes Gerät ein individuelles Zertifikat generieren, auf den Geräten installieren und bei Bedarf z.B. bei Ablauf auch wieder erneuern lassen.
Angenommen in einem Industriebetrieb werden an die Mitarbeiter 3000 neue Dienstsmartphones verteilt. Da setzt sich keiner hin und fummelt da händisch irgendwas rum. Da fragt das MDM nur bei der PKI „Neues Zertifikat für Gerät 1337 bitte!“ an und flupp ist das drauf.
VG
Thomas
P.S. Hintergrund ist natürlich auch wieder die Organisationsgröße. Wenn man jetzt nur ein Zertifikat hat und ein Gerät kommt evtl. abhanden, muss man auf allen anderen 2999 Geräten das Zertifikat auch ersetzen. Hat jedes Gerät ein eigenes Zert, dann eben nur für das eine.
Ich habe in der Zwischenzeit etwas herumprobiert und gesehen, dass man mit der oben beschriebenen Methode direkt auf der OPNSense wirklich sehr bequem mit sehr wenigen Klicks die gesamte Chain of Trust sowie Client-Zertifkate erzeugen/widerrufen kann.
Was ich jedoch bisher vermisse ist ein Automatismus, wie man ihn vom ACME-Client und den LE-Certs kennt – also: Sobald abgelaufen → erneuern.
Das scheint im OPNSense-WebUI so nicht möglich zu sein bzw sogar so gewollt sein, oder ?!
Wenn man nun zurück an Deinen Beitrag hier bzgl der max. Gültigkeit denkt (die z.B. von Apple-Geräten eingefordert wird) muss man das regelmäßig komplett erneuern bzw. immer wieder neu Handarbeit anlegen, richtig? Oder wie vereinfachst Du diese Schritte?
