Zuerst werden Zertifikate ausgetauscht, damit die weitere Übertragung von Daten verschlüsselt übertragen wird. Client Hello ↔ Server Hello. Der Server zeigt sein Zertifikat, der Client akzeptiert das.
Jetzt gehts verschlüsselt weiter.
Die Authentisierungsmethode wird abgefragt. Dann werden, abhängig von der gewählten Methode Client-Zertifikat (EAP-TLS) oder Benutzerdaten (EAP-PEAP) vom Client übermittelt.
Der Radius prüft das Zertifikat auf seine Gültigkeit bzw. die Benutzerdaten und gibt dann den Zugang frei oder blockt ihn wenn was nicht stimmt.
Entweder ist höchste Zeit für’s Wochenende oder ich habe einen Knoten im Kopf:
Wenn zuerst das Zertifkat kommt und Client & Server vertrauen sich bereits, warum ist dann (auch beim ersten Login) noch extra der Login notwendig, wenn doch die Methode EAP-TLS im Prinzip bereits erfolgreich war!? Oder gilt das beim ersten Login nicht?
Der Vergleich mit ssh und ssh-copy-id drängt sich ja geradezu auf… da läuft das mit dem pub.key-Verfahren ja ähnlich, aber vor dem Schlüsselaustausch steht da ein erfolgreicher (erster) Login.
die Idee dahinter ist, dass die Anmeldedaten über den sogenannten outer-tunnel verschlüsselt übertragen werden sollen.
Daher ist im ersten Schritt erforderlich, dass der Client dem Server vertraut. Hier kommt das Serverzertifikat ins Spiel. Der Client vertraut dem Server → es können Daten ausgetauscht werden.
Im nächsten Schritt zeigt dann bei der Methode EAP-TLS der Client sein Zertifikat vor. Der Server prüft, ist das Zertifikat gültig und ob er der Zertifizierungsstelle des Client-Zertifikats vertraut. Ist das der Fall (und wenn beide Zertifikate aus der gleichen CA stammen ist das der Normalfall), hat man eine zweiseitige Vertrauensstellung.
Ok. Verstanden.
Aber könnte es sein oder konfigurierbar sein, dass ab der Stelle „Im nächsten Schritt…“ beim ersten Verbinden nur EAP-PEAP klappt?
(Ansonsten sehe ich auch weiterhin nicht ein, warum überhaupt irgendwo Credentials notwendig sind, wenn alles von vorneherein über Zertifikate funktioniert?)
EAP-PEAP setzt EAP-TLS voraus. Also nein.
Warum macht man dann nicht immer EAP-TLS? Macht man z.B. wenn es um firmeneigene oder schuleigene, verwaltete Geräte geht, da man hier die Client-Zertifikate über eine eigene PKI über SCEP generieren und ausrollen lassen kann.
Warum macht man es bei BYOD in der Regel nicht? Weil sich die Benutzer selbst auf der PKI Zertifikate erstellen und diese selbst als Client-Zertifikate auf ihr Endgerät importieren müssten (ich kenne tatsächlich eine Schule bei der das gemacht wird).
In dem Fall ist die EAP-PEAP Methode mit Benutzername und Kennwort einfach praktikabler.
Funktioniert ja auch prima. Man muss nur einmal auf dem Client das Serverzertifikat akzeptieren und dass sollte eben aus einer eigenen privaten CA stammen und nicht aus einer öffentlichen CA aus den oben beschriebenen Gründen.
Was die Geheimhaltung angeht. Es gibt bei den Zertifikat auch immer den sog. private Key → der sollte geheim sein und wird auch nie vorgezeigt. Nur der jeweilige öffentliche Teil des Zertifikats wird vorgezeigt und ausgetauscht.
Die ca kann zertifkate ausstellen. Fuer jedes geraet das einloggen daef bekommt es ein individuelles zertifkat das auch zurueckgezogen werden kann.
Wenn man als ca aber ein LE zertifikat nimmt, dann kommt man einfach an zertifkate und kann sich dann ins wlan einloggen.
Es ist also nicht „ein“ geheimes zertifkat. Das geheime ist das eigene ca zertifkat und der schluessel dafuer das einem erlaubt zertifkate auszustellen.
Die zertifkate imminner und outer tunnel sind net dieselben.
Richtig?
angesehen. Da wird ja beschrieben, wie man sich ein eigenes Zertifkat ausstellen kann.
Da ich vor längerer Zeit dem Server ein OPNSense-LE-Zertifikat spendiert habe, scheint das auf unserem v7-Server nicht mehr 100% zu funktionieren, denn es passt etwas nicht zusammen
Die Datei Sep 14 2019 cakey.pem stammt von der Erstinstallation und ist daher noch das Original aber die Datei Jun 22 04:06 cacert.pem ist von der OPNSense und gehört daher zum LE-Cert.
Aus diesem Grund gelingt es mir auch nicht, dass ich mit dem Befehl openssl x509 -req -in radius.csr -CA /etc/linuxmuster/ssl/cacert.pem -CAkey /etc/linuxmuster/ssl/cakey.pem -CAcreateserial -out radius.pem -days 365 -sha512
ein neue Zertifikat anfordern kann.
Die Fehlermeldung war sinngemäß „mismatch“, was ich sogar einsehe!
Die Frage ist: Kann man das cacert.pem auf dem v7-Server unter /etc/linuxmuster/ssl neu erzeugen lassen, so dass es wieder zusammenpasst?
Das soll für heute aber auch reichen…
Viele Grüße,
Michael
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?
