Sub-CAs in FreeIPA

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:

# ipa ca-find

-------------

1 CA matched

-------------

    Name: ipa

    Description: IPA CA

    Authority ID: a620d132-c68b-4684-8ed3-69834aba1a7a

    Subject DN: CN=Certificate Authority,O=TESTRELM.TEST

    Issuer DN: CN=Certificate Authority,O=TESTRELM.TEST

----------------------------

Number of entries returned 1

----------------------------

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:

# ipa ca-add "VPN" --subject "cn=VPN User CA, O=TESTRELM.TEST" --desc "This CA issues certificates for all VPN users"

--------------------

Created CA "VPN"

--------------------

    Name: VPN

    Description: This CA issues certificates for all VPN users

    Authority ID: 56a88dc2-bf5d-44f3-b019-afc4f6f33042

    Subject DN: CN=VPN User CA,O=TESTRELM.TEST

    Issuer DN: CN=Certificate Authority,O=TESTRELM.TEST

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).

# certutil -d /var/lib/pki/pki-tomcat/alias/ -L
Certificate Nickname
    Trust Attributes
    SSL,S/MIME,JAR/XPI
ocspSigningCert cert-pki-ca u,u,u
subsystemCert cert-pki-ca u,u,u
caSigningCert cert-pki-ca CTu,Cu,Cu
Server-Cert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
caSigningCert cert-pki-ca 56a88dc2-bf5d-44f3-b019-afc4f6f33042 u,u,u

# certutil -d /var/lib/pki/pki-tomcat/alias/ -L -a -n "caSigningCert cert-pki-ca 56a88dc2-bf5d-44f3-b019-afc4f6f33042"|openssl x509 -subject -issuer -dates -noout -serial
subject= /O=TESTRELM.TEST/CN=VPN User CA
issuer= /O=TESTRELM.TEST/CN=Certificate Authority
notBefore=Aug 14 12:48:26 2016 GMT
notAfter=Aug 14 12:48:26 2036 GMT
serial=0D

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:

# ipa caacl-add vpn-users --usercat=all

# ipa caacl-add-profile vpn-users --certprofile caIPAvpnUsers

# ipa caacl-add-ca vpn-users --ca VPN

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

# openssl genrsa -out tscherf.key 2048

# openssl req -new -sha256 -key tscherf.key -out tscherf.csr

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.

# ipa cert-request --principal tscherf --profile caIPAvpnUsers --ca VPN tscherf.csr
    Certificate: MIIEAzCCAu [...] 44yWn8nFE=
    Subject: CN=tscherf,O=TESTRELM.TEST
    Issuer: CN=VPN User CA,O=TESTRELM.TEST
    Not Before: Wed Aug 17 09:21:06 2016 UTC
    Not After: Sat Aug 18 09:21:06 2018 UTC
    Fingerprint (MD5): be:cd:2b:20:7b:31:b6:76:62:14:a1:38:31:f8:2f:b5
    Fingerprint (SHA1): 4a:89:60:50:9b:a7:44:f0:bb:e0:b4:aa:8b:c3:6f:f9:a4:c0:0e:3b
    Serial number: 14
    Serial number (hex): 0xE

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:

# ipa certprofile-show caIPAvpnUsers

    Profile ID: caIPAvpnUsers

    Profile description: Profile for VPN users

    Store issued certificates: TRUE

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:

# ipa user-show tscherf --out

    tscherf.crt|openssl x509 -in

    tscherf.crt -noout -subject

       -issuer

subject= /O=TESTRELM.TEST/CN=tscherf

issuer= /O=TESTRELM.TEST/CN=VPN User CA

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)