In den vorigen Beiträgen

opensuse 12.3, LDAP, sssd – I
opensuse 12.3, LDAP, sssd – II

zu meiner kleinen LDAP-Reihe für OS 12.3 bin ich darauf eingegangen, dass der OpenLDAP-Server seit OS 12.2 wegen sssd TLS/SSL-fähig ausgelegt werden muss. In diesem Beitrag treffe ich mittels YaST2 die Vorbereitungen, um die TLS-Fähigkeit zu erreichen und lege dafür Zertifikate an.

Im weiteren Verlauf des Textes bezeichne ich als “LDAP-Server” dasjenige Server-System unter Opensuse 12.3, das eine OpenLDAP-Implementierung beinhaltet. Im LDAP-Baum werden später gemäß suse-spezifischer Regeln Standardobjekte für die Beherbergung von User- und Gruppen-Informationen angelegt. Der LDAP-Baum beinhaltet dann auch die Credentials für eine User-Authentifizierung.

Ein anderer Opensuse 12.3-basierter PC oder Server, auf dem ein User, dessen Daten im LDAP hinterlegt sind, sich einloggen will, bezeichnen wir nachfolgend dagegen als Linux- “Host” unseres Netzwerkes. Ziel ist es, den User mit Hilfe des LDAP_Servers zu authentifizieren und ihm bzw. anderen Programmen auf dem Host das Arbeiten mit dem LDAP-Server zu ermöglichen.

CA und Common Server Certificate für einen LDAP-Server

Verschlüsselte Verbindungen wie TLS/SSL basieren u.a. auf Zertifikaten. Ein asymmetrisches Sicherheitsverfahren leitet die Client/Server-Kommunikation ein. Dabei werden der private wie der öffentliche Schlüssel eines Servers eingesetzt: Der Erhalt des Server-Zertifikats dient dem Client zur Prüfung der Identität des Servers. Nach erfolgreicher Authentizitätsprüfung sendet der Client dem Server eine Zufallssequenz (pre-master-secret). Dieser Austausch erfolgt verschlüsselt unter Zuhilfenahme des öffentlichen Server-Keys (aus dem Zertifikat). Server und Client berechnen dann auf Basis definierter Verfahren einen gemeinsamen Schlüssel für das anschließend eingesetzte symmetrische (und deshalb schnelle) Verschlüsselungsverfahren für den eigentlichen Datenaustausch. Weitere detailliertere Infos erhält man hier :

http://de.wikipedia.org/wiki/Transport_Layer_Security

Zertikate – im besonderen Server-Zertifikate – werden über eine übergeordnete Instanz ausgestellt. Diese Instanz ist ein sog. “Certificate Authority”, kurz CA. Bei der Kommunikation von Clients mit Servern, die sich über Zertifikate ausweisen, muss das Serverzertifikat und damit die Identität des Servers mittels Informationen der CA als unabhängiger dritter Instanz verifiziert werden.

Hatte man für sein eigenes Netzwerk bislang keine CA generiert, so wird dies nun zwingend erforderlich, wenn Netzwerk-Hosts mit ihrem SSSD den zentralen LDAP-Server zur User-Authentifizierung nutzen sollen.

Es ist wahrscheinlich, dass auf dem zentralen LDAP-Server weitere Server-Dienste laufen werden. Daher kann es sinnvoll sein, auf diesem Server ein von SuSE so genanntes “Common Server Certificate” [CSC] zu implementieren. Ich zeige kurz für zwei Fälle, wie das geht.

Neu im Vergleich zu meinem früheren Artikel Opensuse 12.1 – LDAP -II ist hier lediglich der Einsatz des CSC.

Fall 1: LDAP-Server und CA-Server sind identisch

In unserem Fall setze ich aus Testzwecken neben einer vorhandenen Root-CA eine weitere namens “anraconb” für meine Tests auf. Dies geschieht mittels des YaST2-Moduls >> “CA-Management”. Im sich öffnenden Fenster drücken wir den Button “Create CA” und
füllen im nächsten Dialogfenster die erforderlichen Informationen aus:

Die CA soll logisch später für eine virtuelle Spieldomaine namens “anraconb.de” zuständig sein und Zertifikate für Server und ggf. auch Clients in dieser Domaine ausstellen. Nachdem die CA erzeugt ist, können wir diese über den entsprechenden Button in der Grundmaske des YaST2-CA-Managements “betreten”:

Um ein kopierbares Zertifikatsfile der CA verfügbar zu haben, exportieren wir unser Zertifikat in eine PEM-Datei. Ich lege diese in einem Verzeichnis “/etc/certs” unter dem Namen “anraconb_CA.pem” ab.

Nun legen wir dann für unseren LDAP-Server ein “Server-Zertifikat” an. Nachdem dieses später auf dem gleichen System wie die CA zum Einsatz kommen wird, handelt es sich aus Sicht der späteren Client-Hosts um ein “Self Signed Cerificate”. Aber das kümmert uns im Moment noch nicht.

Bei der Bezeichnung “common name” sollte der FQDN des Servers eingetragen werden. Dies ist wichtig ! Wir werden an verschiedenen Stellen eine exakte Übereinstimmung des Zertifikatsnamens mit dem FQDN des Servers benötigen.

Nachdem das Zertifikat angelegt ist, exportieren wir dieses und den zugehörigen Key in unverschlüsselter Form erneut als Dateien:

Etwas scrollen hätte übrigens zeigt, dass YaST hier RSA-basierte Zertifikate und Schlüssel erzeugt:

Nun zum Export als File:

Das Key-File enthält den “Private Key” für künftige Verschlüsselungen! Key-Files, die aus dem Certificate Management exportiert wurden, müssen daher in besonderer Weise geschützt werden und sollten zunächst nur root zum Lesen zur Verfügung stehen.

Abschließend wählen wir als weitere Exportfunktion den “Export als Common Server Certificate”.

Opensuse legt dann die Dateien erneut an – allerdings an definierter Stelle, die dann später von allen möglichen YaST2-Modulen genutzt wird. Man findet die erforderlichen Zertifikats- und Key-Dateien unter

• /etc/ssl/servercerts/servercert.pem
• /etc/
  ssl/servercerts/serverkey.pem

Die Zertifikatsdatei der CA wird unter

• /etc/ssl/certs/YaST-CA.pem

angelegt

Fall 2: LDAP-Server und CA-Server sind nicht identisch

Natürlich müssen wir auf dem CA-Server ein Zertifikat für den LDAP-Server ausstellen. Dieser wird dann natürlich einen anderen Namen haben – z.B. “xlamp.anraconb.de”.

Alles läuft auf dem CA-Server praktisch identisch zum oben beschriebenen Vorgehen ab, bis wir das erstellte Server-Zertifikat exportieren. Wir müssen hier einen zusätzlichen Export als “p12”-Datei vornehmen.

Man beachte, dass man hier neben dem Zertifikatsnamen ein weiteres Passwort angeben muss.

Dieses File kopieren wir dann per scp auf den Zielserver – also den LDAP-Server. Am besten in das gleiche Verzeichnis “/etc/certs”. Dort schützen wir es, indem wir Lese- und Schreibrechte nur an root vergeben ! Diesen Schritt bitte nicht vergessen !

Auf dem LDAP-Server importieren wir dann das p12-File über “Yast2 >> Common Server Certificate” über die Taste “Import/Replace”. Als Ergebnis werden auf dem LDAP-Server dann in den gleichen Verzeichnissen wie oben beschrieben die notwendigen Files angelegt – u.a. auch das der CA.

Fazit

Eine CA für das eigene Netzwerk ist schnell angelegt. Für seine Server – hier den LDAP-Server – erzeugt man ebenso schnell ein RSA-basiertes Zertifikat und importiert dieses dann auf dem Zielserver mittels YaST als “Common Server Zertifikat”. Das so erhaltene Zertifikat und der private Schlüssel des Servers können dann bei der TLS-Absicherung des LDAP-Servers eingesetzt werden.

Natürlich können aber auch andere Serverdienste die Zertifikatsfiles und die generierten Schlüssel für eine SSL/TLS-Absicherung verwenden – z.B. vsftp, Apache, Cyrus IMAP.

Im nächsten Beitrag dieser Serie legen wir einen LDAP-Server unter Opensuse 12.3 an. Damit wir im Gegensatz zu früheren Artikeln bzgl. LDAP unter Opensuse 12.1 auch was neues lernen, werde ich dabei auch kurz zeigen, was man tun muss, um den LDAP-Server monitoring- und munin-fähig aufzusetzen.