Open Source im professionellen Einsatz

Zertifikate erzeugen

Einige Distributionen haben ein Makefile im Verzeichnis »/etc/raddb/certs«. Damit bauen sie mittels OpenSSL drei Arten von Zertifikaten: Erstens das einer kleinen CA, die später die Urkunden sowohl für (zweitens) den Server und (drittens) die Clients unterzeichnet. Ist dieses Verzeichnis jedoch wie bei Ubuntu 9.04 leer, bezieht der Admin die Dateien aus dem Github von Free Radius unter »raddb/certs/« [10]. Für jedes Zertifikat kennt das Paket eine Konfigurationsdatei sowie ein steuerndes gemeinsames Makefile. Um ein neues CA-Zertifikat anzulegen, bearbeitet der Admin »ca.cnf«. Den Abschnitt »[certificate_authority]« passt er wie in Listing 2 an. Identische Werte setzt er bei »input_password« und »output_password«.

Listing 2: Auszug aus
ca.cnf

[certificate_authority] 
countryName             = DE
stateOrProvinceName     = Hamburg
localityName            = Hamburg
organizationName        = UebelHacker 
emailAddress            = ca@uebelhacker.de 
commonName              = "UebelHacker Certificate Authority 

Analog editiert der Admin die Sektion »[server]« in »server.cnf«, wählt aber dort einen anderen »commonName«, damit sich die Zertifikate unterscheiden (siehe Listing 3). An der Stelle für das Passwort fügt er das in der »eap.conf« festgelegte »private_key_password« ein. Schließlich erzeugt »make all« neben den CA- und Server-Zertifikaten auch die nötige Diffie-Hellman-Datei »dh« und die »random«-Datei, beides wichtige Bestandteile des Protokoll-Handshake von SSL/TLS.

Listing 3: Auszug aus
server.cnf

[server] 
countryName             = DE
stateOrProvinceName     = Hamburg 
localityName            = Hamburg
organizationName        = UebelHacker
emailAddress            = radius@uebelhacker.de
commonName              = "UebelHacker Radius Server" 

Benutzerzertifikate

Bei EAP-TLS benötigt jedes Gerät ein eigenes Client-Zertifikat, das der Systemverwalter mit der Datei »client.cnf« erzeugt. Das Makefile von Free Radius signiert diese Ausweise jedoch mit dem Server-Zertifikat. Damit stattdessen die CA signiert, ändert der Admin die Zeilen aus Listing 4 im Makefile und achtet auf das führende Tab in Zeile 2. So kann er dem Supplikanten später direkt das CA-Zertifikat mitgeben.

Listing 4: Makefile an CA
anpassen

client.crt: client.csr ca.pem ca.key index.txt serial
         openssl ca -batch -keyfile ca.key -cert ca.pem
   -in client.csr -key $(PASSWORD_CA) -out client.crt
   -extensions xpclient_ext -extfile xpextensions
   -config ./client.cnf

In der Sektion »[client]« legt der »commonName« den Benutzernamen für Berechtigungen und weitere Einstellungen unter Radius fest. Auch dieses Zertifikat schützt ein Passwort, das der Admin in »input_password« und »output_password« setzt:

[client]
countryName         = DE
stateOrProvinceName = Hamburg
localityName        = Hamburg
organizationName    = UebelHacker
emailAddress        = s@uebelhacker.de
commonName          = uebelacker

Anders als für CA und Server muss der Admin hier mehrere Zertifikate ausstellen - für jeden User eins. Da »make client« immer nur eins erzeugt, empfiehlt es sich, diese Aufgabe zu skripten. Die fertigen Zertifikate übergibt er den Benutzern zusammen mit ihrem Passwort und dem CA-Zertifikat auf sicherem Weg, beispielsweise per USB-Stick oder auf einer Smartcard.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook