Zertifikatsverwaltung via privacyIDEA: Unterschied zwischen den Versionen

Aus maxTechCorner
← Zum vorherigen Versionsunterschied
Deko (Diskussion | Beiträge)
877 Bearbeitungen
imported>TechCorner-Redaktion
Aktualisierung 10/2026: pi-manage config ca (ab 3.10), openssl -noenc statt Python-2.7-Pfad, MS-CA, Rollout-Wege, CRL-Cronjob, Link auf privacyIDEA-Hauptartikel
 
(Eine dazwischenliegende Version von einem anderen Benutzer wird nicht angezeigt)
Zeile 1: Zeile 1:
==='''Symptom'''===
{{Steckbrief
Es wird eine einfache Lösung für die Zertifikatsverwaltung und Rollout gesucht.
| gilt_fuer  = privacyIDEA ab 3.10 (getestet mit 3.13/3.14), lokale OpenSSL-CA oder Microsoft-CA
==='''Ursache und Lösung'''===
| bereich    = IT-Security
PrivacyIDEA kann mittlerweile auch Zertifikate als Token ausrollen und das kann man bei<br />
| dauer      = ca. 20 Minuten
einer bestehenden Instanz ideal zum Verteilen von Zertifikaten verwenden. <br />
| rechte      = root / privacyIDEA-Admin
<br />
| stand      = Oktober 2026
Hierzu einfach die Files erzeugen:
}}
<pre>
Mit der '''Zertifikatsverwaltung via privacyIDEA''' lassen sich Benutzerzertifikate genauso ausrollen und verwalten wie andere zweite Faktoren: Ein Zertifikat ist in privacyIDEA ein Token vom Typ ''certificate'', das einem Benutzer zugeordnet, gesperrt und widerrufen werden kann. privacyIDEA signiert die Zertifikate dabei nicht selbst, sondern bindet über '''CA-Konnektoren''' eine lokale OpenSSL-CA oder eine vorhandene Microsoft-CA an. Typische Einsatzzwecke sind Client-Zertifikate für WLAN (EAP-TLS), VPN oder die Anmeldung an Webanwendungen.
cp /opt/privacyidea/lib/python2.7/site-packages/tests/testdata/ca/openssl.cnf /etc/privacyidea/CA/


openssl req -days 3650 -new -x509 -keyout /etc/privacyidea/CA/ca.key \
Einen Überblick über privacyIDEA insgesamt – Token-Typen, Installation und Anbindungen – gibt der Artikel [[PrivacyIDEA – Open-Source-Mehr-Faktor-Authentifizierung|privacyIDEA – Open-Source-Mehr-Faktor-Authentifizierung]].
 
{{Hinweis|Frühere Versionen dieses Artikels kopierten die <code>openssl.cnf</code> aus einem Python-2.7-Pfad der privacyIDEA-Installation. Das ist überholt: Bei Paketinstallationen liegt eine Beispiel-<code>openssl.cnf</code> bereits unter <code>/etc/privacyidea/CA/</code>, und seit Version 3.10 lautet der Verwaltungsbefehl <code>pi-manage config ca …</code> (vorher <code>pi-manage ca …</code>).}}
 
== Variante 1: Lokale CA mit pi-manage einrichten (empfohlen) ==
Der einfachste Weg ist der Assistent von <code>pi-manage</code>. Er legt die CA-Dateien an und erzeugt gleichzeitig den passenden CA-Konnektor in privacyIDEA:
<syntaxhighlight lang="bash">
pi-manage config ca create firmen-ca
</syntaxhighlight>
Der Assistent fragt nacheinander ab:
* Verzeichnis der CA (z. B. <code>/etc/privacyidea/CA/firmen-ca</code>),
* Schlüssellänge (2048, 4096 oder 8192 Bit – empfohlen: '''4096'''),
* Gültigkeit des CA-Zertifikats in Tagen,
* Distinguished Name der CA (z. B. <code>/CN=Firmen-CA/O=Beispiel GmbH/C=DE</code>),
* Gültigkeit der Sperrliste (CRL) und Überlappungszeitraum.
 
Anschließend die Konnektoren prüfen:
<syntaxhighlight lang="bash">
pi-manage config ca list -v
</syntaxhighlight>
 
== Variante 2: Lokale CA manuell anlegen ==
Wer die CA-Parameter selbst steuern möchte, passt zunächst <code>/etc/privacyidea/CA/openssl.cnf</code> an und erzeugt dann CA-Schlüssel und -Zertifikat:
<syntaxhighlight lang="bash">
cd /etc/privacyidea/CA
 
openssl req -x509 -new -newkey rsa:4096 -sha256 -days 3650 -noenc \
            -keyout /etc/privacyidea/CA/ca.key \
             -out /etc/privacyidea/CA/ca.crt \
             -out /etc/privacyidea/CA/ca.crt \
             -config /etc/privacyidea/CA/openssl.cnf
             -config /etc/privacyidea/CA/openssl.cnf
 
touch /etc/privacyidea/CA/index.txt
touch /etc/privacyidea/CA/index.txt
echo 01 > /etc/privacyidea/CA/serial
echo 01 > /etc/privacyidea/CA/serial
openssl rsa -in ca.key -out ca-nopw.key
mv ca-nopw.key ca.key
chown -R privacyidea /etc/privacyidea/CA
chown -R privacyidea /etc/privacyidea/CA
chmod 0600 /etc/privacyidea/CA/ca.key
chmod 0600 /etc/privacyidea/CA/ca.key
</pre>
</syntaxhighlight>
Dann wird der Konnektor in der UI angelegt und es können Zertifikate erstellt werden.<br />
Der Schalter <code>-noenc</code> (früher <code>-nodes</code>) erzeugt den CA-Schlüssel ohne Passphrase – privacyIDEA muss ihn ohne Rückfrage verwenden können. Der Umweg über <code>openssl rsa</code> zum Entfernen der Passphrase entfällt damit. Umso wichtiger sind die restriktiven Dateirechte und ein geschützter Server.
Idealerweise laden sich die User ihre eigenen Zertifikate (PKCS12) über das Selfservice Portal runter.
 
==='''Links und Quellen'''===
Danach in der privacyIDEA-Oberfläche unter '''Konfiguration → CA-Konnektoren''' einen neuen Konnektor vom Typ ''local'' mit dem Verzeichnis <code>/etc/privacyidea/CA</code> und den Dateien <code>ca.key</code>, <code>ca.crt</code> und <code>openssl.cnf</code> anlegen.
[http://www.routerperformance.net/howtos/roll-out-client-certificates-for-mobile-phones-via-privacyidea/ www.routerperformance.net/howtos/roll-out-client-certificates-for-mobile-phones-via-privacyidea/]
 
=== '''Kontakt''' ===
{{Hinweis|Die mitgelieferte Konfiguration ist ein Beispiel. Für eine produktive Unternehmens-[[PKI]] sollten Struktur (Root- und Sub-CA), Laufzeiten, Sperrlisten-Verteilung (CDP) und Schlüsselschutz bewusst geplant werden.}}
Wenn Sie Fragen oder Anmerkungen zu diesem Artikel haben, melden Sie sich bitte bei uns:<br />
 
[http://mailto:techcorner@max-it.de techcorner@max-it.de].<br />
=== Zertifikatsvorlagen ===
Die lokale CA unterstützt einfache Vorlagen: Kombinationen aus X.509-Erweiterungen (Abschnitte der <code>openssl.cnf</code>) und Gültigkeitsdauer. Sie werden in einer YAML-Datei definiert, deren Pfad im CA-Konnektor hinterlegt wird:
<syntaxhighlight lang="yaml">
user:
    days: 365
    extensions: "user"
webserver:
    days: 750
    extensions: "server"
</syntaxhighlight>
 
== Variante 3: Microsoft-CA anbinden ==
In Windows-Domänen kann privacyIDEA Zertifikate auch von einer vorhandenen '''Microsoft-Zertifizierungsstelle (AD CS)''' signieren lassen. Dazu wird auf einem Windows-Server der Domäne der ''privacyIDEA MS CA Worker'' installiert; privacyIDEA verbindet sich mit ihm (in Produktion immer per TLS mit Client-Zertifikat):
<syntaxhighlight lang="bash">
pi-manage config ca create -t microsoft ms-ca
</syntaxhighlight>
Erfordert die CA eine manuelle Freigabe, steht das Token zunächst im Zustand ''pending''. Über einen Event Handler (Ereignis <code>token_init</code>, Bedingung <code>rollout_state=pending</code>) kann privacyIDEA den Benutzer automatisch per E-Mail informieren.
 
== Zertifikate ausrollen ==
Ist ein CA-Konnektor eingerichtet, wird ein Zertifikat wie jedes andere Token über '''Token ausrollen → Zertifikat''' erzeugt. Dabei gibt es drei Wege:
# '''CSR hochladen:''' Der Benutzer erzeugt Schlüssel und Zertifikatsanforderung selbst (der private Schlüssel verlässt sein Gerät nie) und lädt den CSR hoch.
# '''CSR auf dem Server erzeugen:''' privacyIDEA erzeugt Schlüsselpaar und Anforderung. Der Benutzer lädt anschließend ein verschlüsseltes '''PKCS#12'''-Paket herunter – geschützt mit der Token-PIN bzw. einem einmalig angezeigten Zufallspasswort.
# '''Vorhandenes Zertifikat hochladen''', um es einem Benutzer zuzuordnen.
 
Idealerweise rollen Benutzer ihre Zertifikate selbst über das Self-Service-Portal aus. Wird für die Anmeldung am Portal ein zweiter Faktor verlangt (Richtlinie ''login_mode''), ist auch die Zertifikatsausstellung durch MFA abgesichert.
 
== Widerruf und Sperrlisten (CRL) ==
Widerruft ein Administrator ein Zertifikats-Token, wird das Zertifikat gesperrt und eine neue CRL erzeugt. privacyIDEA erneuert die CRL jedoch '''nicht automatisch regelmäßig''' – sie ist typischerweise 30 Tage gültig. Daher einen Cronjob einrichten:
<syntaxhighlight lang="bash">
# /etc/cron.d/privacyidea-crl – täglich prüfen, ob eine neue CRL fällig ist
0 3 * * * privacyidea pi-manage config ca create_crl firmen-ca
</syntaxhighlight>
Der Befehl erzeugt nur dann eine neue CRL, wenn der Überlappungszeitraum erreicht ist; mit <code>-f</code> lässt sich die Erstellung erzwingen. Die CRL muss anschließend dort bereitgestellt werden, wo die prüfenden Systeme sie abrufen (z. B. RADIUS-Server oder Firewall).
 
== Unterstützung von m.a.x. it ==
Bei Zertifikats- und Identity-Management mit privacyIDEA – vom Aufbau der CA bis zum Zertifikats-Rollout für WLAN und VPN – unterstützt Sie m.a.x. it mit [https://www.max-it.de/it-services/cybersecurity/ Cybersecurity-Services von m.a.x. it].
 
== Siehe auch ==
* [[PrivacyIDEA – Open-Source-Mehr-Faktor-Authentifizierung|privacyIDEA – Open-Source-Mehr-Faktor-Authentifizierung]]
* [[OPNsense - WLAN-Authentifizierung mittels EAP-TLS]]
* [[OPNsense - Radius]]
* [[PKI]]


'''Über m.a.x. Informationstechnologie AG:'''<br />
== Links und Quellen ==
Als etabliertes Münchner Systemhaus zeichnen wir uns seit 1989 als verlässlicher IT-Partner mittelständischer<br />
* [https://privacyidea.readthedocs.io/en/latest/configuration/caconnectors.html privacyIDEA-Doku – CA-Konnektoren]
und großer Unternehmen aus. Unser Portfolio reicht von IT- Services über individuelle Softwareentwicklung bis hin zur ERP-Beratung.
* [https://privacyidea.readthedocs.io/ privacyIDEA – offizielle Dokumentation]
* [https://www.max-it.de/it-services/cybersecurity/ m.a.x. it – Cybersecurity-Services]


=== '''Tags''' ===
{{Uebermax}}
PrivacyIDEA, Zertifikate, Rollout
[[Kategorie:IT-Security]]


[[Kategorie: IT-Security]]

Aktuelle Version vom 5. Oktober 2026, 00:00 Uhr

Auf einen Blick

Gilt fürprivacyIDEA ab 3.10 (getestet mit 3.13/3.14), lokale OpenSSL-CA oder Microsoft-CA
BereichIT-Security
Dauerca. 20 Minuten
Rechteroot / privacyIDEA-Admin
StandOktober 2026

Mit der Zertifikatsverwaltung via privacyIDEA lassen sich Benutzerzertifikate genauso ausrollen und verwalten wie andere zweite Faktoren: Ein Zertifikat ist in privacyIDEA ein Token vom Typ certificate, das einem Benutzer zugeordnet, gesperrt und widerrufen werden kann. privacyIDEA signiert die Zertifikate dabei nicht selbst, sondern bindet über CA-Konnektoren eine lokale OpenSSL-CA oder eine vorhandene Microsoft-CA an. Typische Einsatzzwecke sind Client-Zertifikate für WLAN (EAP-TLS), VPN oder die Anmeldung an Webanwendungen.

Einen Überblick über privacyIDEA insgesamt – Token-Typen, Installation und Anbindungen – gibt der Artikel privacyIDEA – Open-Source-Mehr-Faktor-Authentifizierung.


HinweisFrühere Versionen dieses Artikels kopierten die openssl.cnf aus einem Python-2.7-Pfad der privacyIDEA-Installation. Das ist überholt: Bei Paketinstallationen liegt eine Beispiel-openssl.cnf bereits unter /etc/privacyidea/CA/, und seit Version 3.10 lautet der Verwaltungsbefehl pi-manage config ca … (vorher pi-manage ca …).

Variante 1: Lokale CA mit pi-manage einrichten (empfohlen)

Der einfachste Weg ist der Assistent von pi-manage. Er legt die CA-Dateien an und erzeugt gleichzeitig den passenden CA-Konnektor in privacyIDEA: 

pi-manage config ca create firmen-ca

Der Assistent fragt nacheinander ab:

  • Verzeichnis der CA (z. B. /etc/privacyidea/CA/firmen-ca),
  • Schlüssellänge (2048, 4096 oder 8192 Bit – empfohlen: 4096),
  • Gültigkeit des CA-Zertifikats in Tagen,
  • Distinguished Name der CA (z. B. /CN=Firmen-CA/O=Beispiel GmbH/C=DE),
  • Gültigkeit der Sperrliste (CRL) und Überlappungszeitraum.

Anschließend die Konnektoren prüfen: 

pi-manage config ca list -v

Variante 2: Lokale CA manuell anlegen

Wer die CA-Parameter selbst steuern möchte, passt zunächst /etc/privacyidea/CA/openssl.cnf an und erzeugt dann CA-Schlüssel und -Zertifikat: 

cd /etc/privacyidea/CA

openssl req -x509 -new -newkey rsa:4096 -sha256 -days 3650 -noenc \
            -keyout /etc/privacyidea/CA/ca.key \
            -out /etc/privacyidea/CA/ca.crt \
            -config /etc/privacyidea/CA/openssl.cnf

touch /etc/privacyidea/CA/index.txt
echo 01 > /etc/privacyidea/CA/serial
chown -R privacyidea /etc/privacyidea/CA
chmod 0600 /etc/privacyidea/CA/ca.key

Der Schalter -noenc (früher -nodes) erzeugt den CA-Schlüssel ohne Passphrase – privacyIDEA muss ihn ohne Rückfrage verwenden können. Der Umweg über openssl rsa zum Entfernen der Passphrase entfällt damit. Umso wichtiger sind die restriktiven Dateirechte und ein geschützter Server.

Danach in der privacyIDEA-Oberfläche unter Konfiguration → CA-Konnektoren einen neuen Konnektor vom Typ local mit dem Verzeichnis /etc/privacyidea/CA und den Dateien ca.key, ca.crt und openssl.cnf anlegen.


HinweisDie mitgelieferte Konfiguration ist ein Beispiel. Für eine produktive Unternehmens-PKI sollten Struktur (Root- und Sub-CA), Laufzeiten, Sperrlisten-Verteilung (CDP) und Schlüsselschutz bewusst geplant werden.

Zertifikatsvorlagen

Die lokale CA unterstützt einfache Vorlagen: Kombinationen aus X.509-Erweiterungen (Abschnitte der openssl.cnf) und Gültigkeitsdauer. Sie werden in einer YAML-Datei definiert, deren Pfad im CA-Konnektor hinterlegt wird: 

user:
    days: 365
    extensions: "user"
webserver:
    days: 750
    extensions: "server"

Variante 3: Microsoft-CA anbinden

In Windows-Domänen kann privacyIDEA Zertifikate auch von einer vorhandenen Microsoft-Zertifizierungsstelle (AD CS) signieren lassen. Dazu wird auf einem Windows-Server der Domäne der privacyIDEA MS CA Worker installiert; privacyIDEA verbindet sich mit ihm (in Produktion immer per TLS mit Client-Zertifikat): 

pi-manage config ca create -t microsoft ms-ca

Erfordert die CA eine manuelle Freigabe, steht das Token zunächst im Zustand pending. Über einen Event Handler (Ereignis token_init, Bedingung rollout_state=pending) kann privacyIDEA den Benutzer automatisch per E-Mail informieren.

Zertifikate ausrollen

Ist ein CA-Konnektor eingerichtet, wird ein Zertifikat wie jedes andere Token über Token ausrollen → Zertifikat erzeugt. Dabei gibt es drei Wege:

  1. CSR hochladen: Der Benutzer erzeugt Schlüssel und Zertifikatsanforderung selbst (der private Schlüssel verlässt sein Gerät nie) und lädt den CSR hoch.
  2. CSR auf dem Server erzeugen: privacyIDEA erzeugt Schlüsselpaar und Anforderung. Der Benutzer lädt anschließend ein verschlüsseltes PKCS#12-Paket herunter – geschützt mit der Token-PIN bzw. einem einmalig angezeigten Zufallspasswort.
  3. Vorhandenes Zertifikat hochladen, um es einem Benutzer zuzuordnen.

Idealerweise rollen Benutzer ihre Zertifikate selbst über das Self-Service-Portal aus. Wird für die Anmeldung am Portal ein zweiter Faktor verlangt (Richtlinie login_mode), ist auch die Zertifikatsausstellung durch MFA abgesichert.

Widerruf und Sperrlisten (CRL)

Widerruft ein Administrator ein Zertifikats-Token, wird das Zertifikat gesperrt und eine neue CRL erzeugt. privacyIDEA erneuert die CRL jedoch nicht automatisch regelmäßig – sie ist typischerweise 30 Tage gültig. Daher einen Cronjob einrichten: 

# /etc/cron.d/privacyidea-crl – täglich prüfen, ob eine neue CRL fällig ist
0 3 * * * privacyidea pi-manage config ca create_crl firmen-ca

Der Befehl erzeugt nur dann eine neue CRL, wenn der Überlappungszeitraum erreicht ist; mit -f lässt sich die Erstellung erzwingen. Die CRL muss anschließend dort bereitgestellt werden, wo die prüfenden Systeme sie abrufen (z. B. RADIUS-Server oder Firewall).

Unterstützung von m.a.x. it

Bei Zertifikats- und Identity-Management mit privacyIDEA – vom Aufbau der CA bis zum Zertifikats-Rollout für WLAN und VPN – unterstützt Sie m.a.x. it mit Cybersecurity-Services von m.a.x. it.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=Zertifikatsverwaltung_via_privacyIDEA&oldid=3792“