Sub-CAs in FreeIPA

Unter Autorität

Das Open-Source-Identity-Management-Framework FreeIPA war schon häufig Thema dieser Artikel-Reihe. Im aktuellen Release 4.4 wurde nun ein Feature hinzugefügt, das für alle Administratoren interessant ist, die das Framework als vollständige PKI-Lösung einsetzen möchten.
Das Storage-Management und die Virtualisierung der Speicherumgebung stehen im Mittelpunkt der November-Ausgabe des IT-Administrator. Denn längst sind die ... (mehr)

In den letzten Releases des Identity-Management-Frameworks FreeIPA wurden bereits viele interessante Features eingebaut, die es ermöglichen, X.509-Zertifikate zu verwalten. Um beispielsweise Zertifikate für einen bestimmten Einsatzzweck ausstellen zu können, wurden in der Version 4.2 Zertifikatsprofile eingeführt. Mit dem aktuellen Release kommen sogenannte Lightweight Sub-CAs [1] hinzu.

Bisher war es so, dass die Certificate-Authority-Komponente, die in FreeIPA durch das Open-Source-Projekt Dogtag realisiert ist, lediglich über einen einzelnen Signierungsschlüssel verfügt. Das heißt, sämtliche von FreeIPA ausgestellten Zertifikate werden immer mit diesem einen Schlüssel signiert. Somit war es bisher nicht möglich, Zertifikate für unterschiedliche Einsatzzwecke auch von unterschiedlichen CAs zu beziehen; stattdessen wurden sämtliche Zertifikate immer von der gleichen CA ausgestellt.

Mehrere CAs, weniger Ressourcen

Der Begriff "lightweight" im Zusammenhang mit Sub-CAs rührt daher, dass sich die CAs innerhalb von Free-IPA die meisten Ressourcen teilen, was letztendlich für eine bessere Performance sorgt. So verwenden beispielsweise alle CAs die gleiche NSS-basierte Backend-Datenbank (unterhalb von "/var/lib/pki/pki-tomcat/alias/"), in der die CA-eigenen Zertifikate abgelegt werden. Auch wird lediglich eine einzelne Tomcat-Instanz verwendet, um die einzelnen CAs bereitzustellen, was wiederum dazu führt, dass alle Instanzen innerhalb von FreeIPA über den gleichen Netzwerkport angesprochen werden können und auch in die gleichen Logdateien schreiben.

Nun gibt es aber oft den Anwendungsfall, dass Zertifikate nur dann erfolgreich validiert werden sollen, wenn sie für einen bestimmten Einsatzzweck ausgestellt wurden. User-Zertifikate für die Anmeldung an einem VPN-Gateway sind ein klassisches Beispiel. Die entsprechenden Zertifikate werden von einer bestimmten CA mit dem passenden Zertifikatsprofil ausgestellt und können dann von einem VPN-Gateway mit dem Signierungsschlüssel der jeweiligen CA entsprechend verifiziert werden. Benutzer-Zertifikate, die von einer anderen Sub-CA des FreeIPA-Frameworks ausgestellt wurden, sollen jedoch ignoriert werden und nicht zu einer erfolgreichen Validierung des Zertifikates führen, sodass die Anmeldung eines Benutzers mit einem solchen Zertifikat also fehlschlägt.

Um sich die auf einem System mit Free-IPA 4.4 bereits vorhandenen CAs anzusehen, reicht der folgende Aufruf:

 

Neben der eindeutigen Authority ID wird ebenfalls das Subject des CA-Zertifikats sowie dessen Aussteller angezeigt. Der folgende Befehl legt eine neue Sub-CA an, die mit dem Schlüssel der Haupt-CA (IPA CA) signiert wird:

 

Jede CA bekommt eine eindeutige ID zugewiesen, die bei den Sub-CAs Teil des Nicknames wird. Ein Blick in die CA-Backend-Datenbank verdeutlicht dies. Neben diversen Subsystem-Zertifikaten befindet sich hier das Zertifikat der Haupt-CA mit dem Nickname "caSigningCert cert-pki-ca" sowie auch das Zertifikat der soeben neu erzeugten Sub-CA mit dem gleichen Nickname, gefolgt von der Authority-ID (Listing 1). Als Herausgeber ist die Haupt-CA angegeben (Listing 2).

Listing 1: Sub-CA

 

Listing 2: Herausgeber des Zertifikats

 

Im nächsten Schritt ist eine Access Control List (ACL) anzulegen, die festlegt, welches Zertifikatsprofil mit welcher CA verknüpft werden soll. Somit wird sichergestellt, dass eine CA lediglich Zertifikate auf Basis des zuvor eingerichteten Profils ausgeben kann. Im folgenden Beispiel gehen wir davon aus, dass das Profil mit dem Namen "vpn-users" bereits eingerichtet wurde:

 

Der eigentliche Certificate Signing Request (CSR) lässt sich schnell mit zwei openssl-Kommandos anlegen:

 

Im Anschluss lässt sich dann die Zertifikatsanfrage in Form der CSR-Datei an das FreeIPA-System senden (Listing 3). Hierbei müssen Sie die neu eingerichtete CA und das gewünschte Profil angeben. FreeIPA stellt dann umgehend ein entsprechendes Zertifikat aus, das auch als Teil des Benutzer-Objektes im LDAP gespeichert wird, wenn diese Einstellung zuvor in dem verwendeten Profil definiert wurde.

Listing 3: Certificate Signing Request

 

Ein Blick in die Ausgabe von »ipa certprofile-show« verrät, ob FreeIPA die neu ausgestellten Zertifikate, die auf einem bestimmten Profil basieren, auch im LDAP speichert:

 

Hat alles geklappt, können Sie das neu ausgestellte Zertifikat in einer Datei speichern. Der folgende Befehl bestätigt, dass das Zertifikat in der Tat von der zuvor neu eingerichteten Sub-CA ausgestellt wurde:

 

Fazit

Mit dem neuen Feature der Sub-CAs macht FreeIPA einen weiteren Schritt in die richtige Richtung, um als vollständige PKI-Lösung dienen zu können. Aktuell fehlen zwar noch einige Features, beispielsweise das Nesting, sodass eine Sub-CA einer anderen Sub-CA untergeordnet sein kann.

Momentan werden alle Sub-CAs mit dem Schlüssel der Haupt-CA signiert. Auch lässt sich die Gültigkeit eines CA-Schlüssels aktuell nicht festlegen. Alle CA-Schlüssel sind fix für 20 Jahre gültig. Diese und andere Features stehen aber bereits auf der To-do-Liste und werden sicher in einem der nächsten Releases adressiert werden.

(of)

Link-Codes

[1] FreeIPA Sub-CAs DesignPage: http://www.freeipa.org/page/V4/Sub-CAs

comments powered by Disqus
Mehr zum Thema

Open Source-Tipp

Die Notwendigkeit für sichere E-Mail-Kommunikation sollte nicht erst seit Bekanntwerden der letzten Abhörskandale klar sein. Leider gestaltet sich die praktische Umsetzung eines solchen Vorhabens jedoch manchmal als schwierig. Der Open Source-Tipp zeigt, wie sich sehr leicht Zertifikate für den S/MIME-Einsatz erzeugen lassen.

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite