Weil's so schön ist: Rückfrage zu Zertifikaten und EAP-TLS

1

Hallo und guten Morgen,
ich habe mal wieder eine Frage zu selbst-signierten Zertifikaten und dem, was in den Docs steht. Hier wird ja des öfteren diskutiert, wie man ein selbst-signiertes Zertifikat erzeugen und signieren muss, wenn der v7-Server selbst die CA ist. Das zeigt @tjordan zum Beispiel hier.

Mir geht es jetzt aber nicht um Firefox-SSL-Zertifikate sondern und EAP-TLS und WPA3-Enterprise.
Nun ist es so, dass in der v7-Doku zur Erstellung der Zertifikate dies steht:
https://docs.linuxmuster.net/de/latest/systemadministration/network/radius/index.html#wlan-zertifikate-einrichten
Am Schluss hat man über diesen Weg also 5 Dateien:

cacert.pem (das Zertifkat der CA, also vom v7-Server selbst erzeugt)
cacert.crt (die Dateien sind mMn identisch und .crt wird nicht weiter verwendet!)

radius.csr       (certificate request)
radius-key.pem   (priv. Key)
radius.pem       (das eigentliche Zertifkat)

Meine Frage dazu:
Müsste es für EAP-TLS nicht so sein, dass man
folgende Zertfikate hat:

ca.pem      (das Zertifikat der Zertifizierungsstelle)
server.pem  (das Server-Zertifikat)
server.key  (mit passendem priv. Schlüssel)

UND ZUSÄTZLICH NOCH:
das client-Zertifikat 
client.p12  (jetzt also im p12 oder pfx Format)

:thinking: :interrobang:

Wenn ich das richtig sehe, gehören dann die beiden Zertifikate ca.pem und client.p12 im richtigen Format und mit der richtigen maximalen Gültigkeitsdauer auf die Endgeräte. Nur dann kann EAP-TLS doch richtig funktionieren – oder??

Daher meine Frage:
Ist evtl die Doku an dieser Stelle nicht lückenlos? Fehlt da also etwas bzgl der Erstellung der p12-Datei? Oder soll die Doku an dieser Stelle gar nicht so weit gehen?

Daneben gibt es ein weiteres Problem: Es scheint so zu sein, dass es völlig unterschiedliche Voraussetzungen an das (Client?)-Zertifikat gibt, wenn man bei unterschiedlichen Plattformen ein Zertifikat importieren will. Das ganze wurde hier ganz gut zusammengestellt. Der Autor sagt etwas zu allen gängigen Plattformen:

Ganz unten auf der Seite wird „das goldene Zertifikat“ vorgestellt, dass angeblich bisher auf allen Plattformen funktioniert hat! Und genau das sollte man dann ja offensichtlich auch für EAP-TLS verwenden, richtig?

Daher die nächste Frage: Hat das jemand so gemacht oder mit welchen Optionen erzeugt ihr die Zertifikate, um Geräte (in unserem Fall ipads) per EAP-TLS ins WPA3-WiFi zu bringen?

Viele Grüße,
Michael

P.S.: Es gibt noch einen kleinen Fehler in der Doku (das sollte an Chris (@cweikl) gehen, denke ich): Der Abschnitt " Auf dem lmn-Server ist in der Datei /etc/linuxmuster/allowed_ports der Radiusport 1812 einzutragen" ist seit v7 obsolet. Die Datei gibt’s so nicht mehr.

2

Hallo und guten Abend,

ich beschäftige mich auch gerade mit dem Thema und bin am überlegen, ob EAP-TLS etwas für die schuleigenen Laptops und evtl. sogar das Linbo-Image (mit wpa-supplicant sollte da auch EAP-TLS gehen, oder?).

Zu deiner Frage mit den Zertifikaten/Schlüsseln. Wenn ich das korrekt verstanden habe (davon gehe ich noch :slight_smile: aus), musst du zwischen CA und Client unterscheiden.

  • CA (wo immer die liegt, z.B. auf dem lmn-Server oder im docker-host, im einfachsten Fall, also nur eine Ebene): Privater Schlüssel zum Signieren, und zugehöriger öffentlicher Schlüssel.
  • Radius-Server: Zertifikat (von CA signiert) mit passendem priv. Schlüssel. Hiermit kann der Radius-Server vom Clienten ‚geprüft‘ werden. Hier im Forum wurde bereits oft genug erklärt, weshalb ein LE-Zertifikat daher eine schlechte Idee ist.
  • Client(en) Pro (für Radius unterscheidbaren) Client wird ein eigenes Schlüsselpaar erzeugt. Zum öffentlichen Schlüssel wir ein certificate request (csr) erstellt. Den braucht die CA um das Zertifikat auszustellen. Der Client braucht ein eigenes Schlüsselpaar, da sich ja der Client gegenüber dem Radius-Server authentifiziert, d.h. seine Nachricht (was auch immer da laut Protokoll versandt wird) signiert (hierfür wird der private Schlüssel benötigt), die dann vom Server verifiziert (mit dem Zertifikat) wird.

CA und Radius-Server könnten auch ‚zusammengelgt‘ werden. In diesem Fall landet man bei den 5 Dateien, vorausgesetzt man benutzt das selbe Client-Zertifikat (inklusive privatem Schlüssel) für alle tatsächlichen Clienten (Ansonsten 2 + 3*x).

Wie oben erklärt gehört hier auch der priv. Schlüssel dazu.

Welche Formate und/oder Dateiendungen jeweils benötigt werden hängen - wie du geschrieben hast - vom jeweiligen System und Einsatzzweck ab.

wird es für Client-Authentifizierung bei EAP-TLS aber nicht sein, denn unter keyUsage steht: serverAuth und genau diesen Zweck hat das Client-Zertifikat eben nicht. (In dem Blog-Beitrag geht es eben vor allem um HTTPS und damit um Server-Zertifikate)

Wenn hier aber jemand EAP-TLS erfolgreich am laufen hat (idealerweise in einem Unifi Netz, mit LMN und Windows-Clients), dann bin ich ebenso für Informationen dankbar.
Ich gehe davon aus, dass im Zusammenhang mit LMN ein Client-Zertifikat erstellt wird und dann entweder ins Image aufgenommen oder via Postsync dem Zertifikatsspeicher von Windows hinzugefügt wird. Ich vermute, dass die LMN es nicht vorsieht z.B. automatisch beim Device-Import Clientzertifikate zu erstellen/erneuern/behalten, diese im Samba-AC abzulegen und dann beim Postsync abzurufen und individuell auf jedem Client zu ‚installieren‘. Ginge das denn?

3

Hallo Michael,

fixed.

LG
Chris

1 „Gefällt mir“