Public-Key-Infrastruktur mit Dogtag

Hundemarke

Hat die Systemlandschaft eine gewisse Größe erreicht, möchte man digitale Zertifikate für Benutzer und Maschinen nicht mehr mit OpenSSL verwalten. Hier hilft eine Public-Key-Infrastruktur (PKI) weiter. Mit Dogtag, der Open-Source-Variante von Red Hats Zertifikats-System, existiert dafür eine leistungsstarke und komfortable Lösung.

Mit Hilfe asymmetrischer Kryptosysteme ist es möglich, Daten digital zu signieren und zu verschlüsseln. Jede beteiligte Entität in diesem Kryptosystem besitzt dabei ein eigenes Schlüsselpaar, bestehend aus einem öffentlichen und einem privaten Schlüssel. Üblicherweise dient der öffentliche Schlüssel zum Verschlüsseln von Daten für diese Entität oder zum Verifizieren von Signaturen. Mit Hilfe des passenden privaten Schlüssels lassen sich die Daten entschlüsseln, die mit Hilfe des öffentlichen Schlüssels codiert wurden.

Dieser Schlüssel dient auch zum Erzeugen digitaler Signaturen. Möchte beispielsweise Alice eine verschlüsselte Nachricht an Bob versenden, benötigt sie dafür in ihrem Schlüsselbund Bobs öffentlichen Schlüssel. Hiermit kann sie die Nachricht dann verschlüsseln, die Bob mit seinem privaten Schlüssel wieder entziffert.

Bei Signaturen gibt ein Hash eine Art Zusammenfassung der Nachricht. Ihn verschlüsselt der Absender mit seinem privaten Schlüssel. Den so erzeugte Hash hängt er einfach an die Nachricht an. Der Empfänger kann nun seinerseits einen Hash von der empfangenen Nachricht generieren, indem er diese ebenfalls durch einen Hash-Algorithmus, wie beispielsweise MD5 oder SHA-1, chickt. Dekodiert man dann den verschlüsselten Hash mit dem öffentlichen Schlüssel des Absenders, so sollte das gleiche Ergebnis herauskommen, andernfalls lassen sich Integrität und Authentizität der Nachricht nicht bestätigen.

Problem: Schlüsseltausch

Das ganze Prinzip funktioniert nur dann, wenn man sich sicher sein kann, dass die eingesetzten Schlüssel echt sind, also wirklich zu der Person gehören, die in den Schlüsseln aufgeführt ist. Und genau hier kommt die sogenannte Public-Key-Infrastruktur (PKI) ins Spiel. Hierbei handelt es sich um eine zentrale Stelle, die die Authentizität öffentlicher Schlüsseln verifiziert. Ist die Echtheit eines Schlüssels bestätigt, so wird dieser durch eine Signatur der Zertifizierungsstelle beglaubigt. Das Ergebnis bezeichnet man dann als digitales Zertifikat. Zur einer PKI gehören mehrere, teilweise optionale Komponenten. Hierzu zählen unter anderen:

  • Eine Zertifizierungsstelle (Certificate Authority, CA)
  • Eine Registrierungsstelle (Registration Authority, RA)
  • Eine Zertifikatsperrliste (Certificate Revocation List, CRL)
  • Ein Verzeichnisdienst (LDAP-Server)
  • Ein Validierungsdienst (Online Certificate Status Protocol, OCSP)
  • Ein Daten-Recovery-Agent (DRA)
  • Zertifikate (X.509)

Bei der CA handelt es sich um die eigentliche Zertifikats-Ausgabestelle, die in der Lage ist, öffentliche Schlüssel mit einer Signatur zur beglaubigen. Oft existiert eine ganze Hierachie von Zertifizierungsstellen, wobei die oberste CA der Hierachie, die sogenannte Root-CA, lediglich Signierungs-Zertifikate fur untergeordnete Zertifizierungstellen ausgibt. Diese sind dann für das Beglaubigen der User- und Server-Schlüssel zuständig. Die Root-CA selbst ist in einem solchen Szenario meist gar nicht direkt online erreichbar. Die Registrierungsstelle, RA, nimmt die eigentlichen Anfragen zum Beglaubigen der Schlüsseln entgegen und leitet sie an die entsprechende CA weiter.

Die Zertifikatssperrliste enthält eine Übersicht nicht mehr gültiger Zertifikate. Hiermit lässt sich die Gültigkeit eines Zertifikats bestätigen. Zum Bereitstellen der Zertifikate wie auch der CRLs dient oft ein Verzeichnisdienst wie beispielsweise LDAP. Gibt es eine Änderung an einer CRL oder ein neues Zertifikat, landet diese Information direkt im Verzeichnis und lässt sich von dort abfragen. Zur Echtzeit-Validierung von Zertifikaten kommt das sogenannte Online Certificate Status Protocol (OCSP), zum Einsatz. Ist dieses, beispielsweise in einem Browser, aktiviert, lassen sich empfangene Zertifikate unmittelbar auf ihre Gültigkeit überprüfen. Die Überprüfung findet komplett transparent und automatisch im Hintergrund statt. Der Daten-Recovery-Agent kann optional eine Kopie der erzeugten Schüssel vorhalten. Somit lassen sich diese im Notfall wiederherstellen. Die Zertifikate selbst liegen überlicherweise im X.509-Format vor. Hierbei handelt es sich um einen ITU-T Standard zur Beschreibung des Zertifikatformats. Listing 1 zeigt ein Beispiel eines solchen X.509-Zertifikats.

Dogtag-Zertifikatssystem

Ab Fedora Version 8 steht Dogtag als PKI-Implementierung unter Open-Source-Lizenz zur Verfügung. Damit die entsprechenden Pakete den Weg auf das eigene System finden, ist eine yum-Konfiguratonsdatei »pki.repo« im Ordner »/etc/yum.repos.d« abzulegen (Listing 2). Zum Speichern der ausgestellen Zertifikate benötigt Dogtag den Fedora-Directory-Server (FDS), der sich aus dem im Listing 3 beschriebenen Yum-Repository heraus instalieren lässt. Die genaue Installation ist unter [2] aufgeführt. Der Registrierungsagent benötigt eine SQLite-Datenbank, die Bestandteil des Standard-Fedora-Repositories ist. Zur grafischen Administration kommt das Tool »pkiconsole« zum Einsatz. Dieses benötigt ein aktuelles Java-Runtime-Environment (JRE), das sich ebenfalls über das Standard-Repository installieren lässt (»yum install java-1.6.0-openjdk« ). Sind diese Vorarbeiten geleistet, lassen sich die einzelnen Subsysteme über Yum installieren:

yum install pki-ca pki-console

Dieser Artikel beschreibt die Installation und Konfiguration der eigentlichen Zertifizierungsstelle, PKI-CA. Für alle weiteren Subsysteme, wie beispielsweise »pki-dra« , »pki-ocsp« , »pki-dra« und anderen, finden sich jeweils Installationsanleitungen im Dogtag-Wiki [1]. Hat die Installation des »pki-ca« -Pakets geklappt, startet sogleich der »pki-ca« -Dienst und gibt eine URL zur Konfiguration aus. Klickt der Anwender drauf, öffnet sich ein Webbrowser und präsentiert ein hübsches Webinterface zur weitereren Konfiguration (Abbildung 1). Die URL enthält eine Setup-PIN zum Einrichten der CA. Soll die Konfiguration zu einem späteren Zeitpunkt erfolgen, findet sich die URL inklusive PIN in der Logdatei »/var/log/pki-ca-install.log« .

Abbildung 1: Zur Konfiguration bietet Dogtag ein komfortables Webinterface an.

Über das Webinterface lassen sich diverse Informationen zu der zu installierenden CA angeben, beispielsweise welcher Directory-Server als Backend dient, ob es sich bei dieser CA um eine Root- oder Sub-CA handelt oder welcher Admin-Account einzurichten ist. Alternativ kann das Kommandozeilentool »pkicreate« alle hier vorgenommenen Einstellungen vornehmen. Sind alle Fragen des Konfigurations-Wizards beanwortet, kann man anschließend die Webseite der CA über die URL »https://Servername:9443« im Browser aufrufen.

Möchte man als Anwender auf die CA zugreifen, um beispielsweise für sich selbst oder einen Netzwerk-Dienst ein Zertifikat zu erzeugen, so gelangt man über den Link »SSL End Users Services« auf eine Seite mit diversen Zertifikatsprofilen. Über diese Profile lassen sich dann Zertifikate mit bestimmten Eigenschaften und Parametern erzeugen. Beispielsweise ist das Profil »Manual User Dual-Use Certificate Enrollment« für User-Zertifikate zuständig. Ein Klick auf diesen Link erstellt eine Zertifikats-Anfrage anhand der eingegebenen Informationen. Diese ist dann vor der Ausstellung des eigentlichen Zertifikats von einem CA-Agent zu verifizieren und zu bestätigen.

Der passende private Schlüssel zu diesem Zertifikat wird direkt beim Erzeugen der Anfrage erstellt und im Zertifikatsspeicher des Browsers gespeichert. Dort wird er später mit dem importierten X.509-Zertifikat verknüpft. Möchte man lieber ein Zertifikat für einen Dienst erzeugen, beispielsweise einen Webserver, so wählt man das Profil »Manual Server Certificate Enrollment« aus der Liste der zur Verfügung stehenden Profile aus und übergibt hier die entsprechende Zertifikats-Anfrage (Certificate Signing Request, CSR) für den Server. Ein solche Anfrage für ein Server-Zertifikat lässt sich beispielsweise sehr leicht mit OpenSSL im passenden PKCS#10-Format [3] erzeugen:

openssl genrsa -des3 -out webserver.key 1024
openssl req -new -key webserver.key -out ↩
webserver.csr

Hat man den Request abgesendet, so ist dieser nun von einem CA-Administrator oder einem CA-Agent mit den notwendigen Rechten zu verifizieren und bestätigen. Hierfür loggt man sich auf der CA-Startseite über den Link »Agent Services« in die Zertifikatsverwaltung der CA ein. Dieses Login erfordert bereits eine zertifikatsbasierte Authentifizierung. Das hierfür notwendige Zertifikat wurde bei der Konfiguration von Dogtag erzeugt und in den Zertifikatsspeicher des Webbrowsers geladen. Natürlich lassen sich auch nachträglich neue Benutzer mit den hierfür notwendigen Rechten einrichten.

Der Punkt »List Request« zeigt nach einer erfolgreichen Anmeldung alle offenen Signing-Requests. Diese lassen sich nun verifizieren und bestätigen. Unter »List Certificates« ist eine Liste aller bestätigten Zertifikate im PKCS#7-Format zu finden. Will ein Anwender nun an sein Zertifikat gelangen, klickt er wieder auf den Links »SSL End Users Services« der CA-Hauptseite. Unter dem »Retrieval-Tab« lassen sich dann alle bestätigten Zertifikate auflisten oder man sucht seinen eigenen Request über die Request-ID, die Dogtag beim Erzeugen des Requests generiert und anzeigt. Ist das eigene Zertifikat gefunden, lässt es sich direkt in den Browser-eigenen Zertifikatsspeicher importieren. Der Firefox-Webbrowser verwendet, wie auch Dogtag, die Network-Security-Services-Bibliotheken (NSS). Als Datenbank-Backend für NSS kommen diverse Berkeley-DB-Dateien zum Einsatz, die jeweils im entsprechenden Firefox-Profil-Ordner liegen. Die öffentlichen Zertifikate sowie Sperrlisten (CRLs) befinden sich üblicherweise in der Datei »cert8.db« , die privaten Schlüssel hingegen in »key3.db« . In den Eigenschaften des Webbrowsers sind alle importierten Zertifikate aufgeführt. Möchte man diese in eine andere Anwendung, beispielsweise einen Mail-Client, importieren, so ist der Export im PKCS-#12 Format vorzunehmen, sodass neben dem Zertifkat selbst auch der private Schlüssel exportiert wird. Wer lieber auf der Kommandozeile arbeitet, kann auf das kleine Tool »certutil« zurückgreifen. Einen Überblick über den eigenen Zertifikatsspeicher verschafft man sich beispielsweise mit dem Aufruf in Listing 1.

Listing 1

<C>certutil<C>

certutil -L -d ~/.mozilla/firefox/i1nfei2a.default/ | grep -i tux
Certificate Authority - Tuxgeek Domain                       CT,C,C
CA Administrator of Instance pki-ca's Tuxgeek Domain ID      u,u,u
foo1 bar's Tuxgeek Domain ID                                 u,u,u
foo2 bar's Tuxgeek Domain ID                                 u,u,u
Thorsten Scherf's Tuxgeek Domain ID                          u,u,u

Natürlich kann Certutil auch neue Zertifikate hinzufügen oder bestehende löschen. Eine Beschreibung zu der sehr hilfreichen Anwendung findet sich unter [4].

Dogtag ist selbstverständlich auch in der Lage, Zertifikate direkt auszustellen, ohne die Anfrage manuell von einem Agent bestätigen zu lassen. Hierfür existieren mehrere Methoden. Am verbreitesten ist die LDAP- und PIN-basierte Authentifizierung. Bei beiden Varianten muss sich ein Benutzer vor der eigentlichen Zertifikats-Anfrage mit seinem Usernamen und Passwort an einem Directory-Server authentifizieren. Bei der PIN-basierten Authentifizierung ist zusätzlich noch eine PIN anzugeben, die sich als zusätzliches Attribut zu einem Benutzer-Objekt hinterlegen lässt. Beide Authentifizierungsmethoden lassen sich über das grafische Admin-Werkzeug »pkiconsole« konfigurieren. Dieses Tool ist mittels »pkiconsole https://Server:9443/ca« zu starten (Abbildung 2).

Abbildung 2: Über das grafische Admin-Werkzeug pkiconsole lassen sich viele Eigenschaften des Dogtag-Servers konfigurieren, hier die Authentifizierung von Benutzern.

Unter dem Punkt »Authentication« lassen sich nun diverse Plugins für die Authentifizierung eines Benutzers am Dogtag-Server einrichten. Für eine LDAP-basierte Authentifizierung über Benutzername und Passwort ist beispielsweise das Plugin »UidPwdDirAuth« auszuwählen und zu konfigurieren. Die Eingabe einer zusätzlichen PIN erfordert das Plugin »UidPwdPinDirAuth« . Jedes Benutzer-Objekt braucht dann natürlich auch ein PIN-Attribut. Dies lässt sich recht einfach dem dem Dogtag-Tool »setpin« erledigen. Ist eine solche Benutzer-Authentifizierung eingerichtet, muss ein Benutzer nicht mehr darauf warten das ein Agent die Zertifikats-Anfrage manuell bestätigt, stattdessen kann er das automatisch erzeugte Zertifikat unmittelbar im »Retrieval« -Tab der »SSL End Users Services« herunterladen.

Abbildung 3: Das erzeugte Zertifikat lässt sich über die Seite SSL End Users Services herunterladen.

Gerade in großen Umgebungen bietet es sich an, die erzeugten X.509-Zertifikate automatisch in einem Verzeichnisdienst zu veröffentlichen. Hierfür lässt sich entweder der bestehende Directory-Server für die Dogtag-Konfiguration verwenden, wobei im produktiven Einsatz ein eigenständiger Server besser ist. In bestehenden Windows-Umgebungen lassen sich die Zertifikate mit einem Activedirectory-Server publizieren, da es sich hierbei ja auch um einen LDAP-Server handelt. Der Admin bindet das Zertfikat dann einfach als zusätzliches Binärattribut an ein User-Objekt. Die Konfiguration hierfür lässt sich wieder mittels »pkiconsole« durchführen.

Abbildung 4: Über pkiconsole lassen sich die ausgestellen Zertifikate im LDAP veröffentlichen.

Unter dem Menüpunkt »Certificate Manager->Publishing« kann der Admin einen entsprechenden Mapper für die User-Zertifikate (»LdapUserCertMap« ) einrichten. Dieser Mapper stellt die Beziehung zwischen dem Subjekt-Namen eines Zertifikats und dem Distinguished Name (DN) eines Benutzers her, damit sich das Zertifikat auch dem korrekten Benutzer-Objekt zuweisen lässt. Ein dnPattern-Mapping könnte beispielsweise so aussehen: »UID=$subj.UID,OU=people,dc=tuxgeek,dc=de« . Um auch die CRLs und das CA-Zertifikat selbst im LDAP zu speichern, ist eine ähnliche Regel auch dem Mapper »LdapCaCertMap« und »LDAPCrlMap« hinzuzufügen. Abschließend sind unter dem »Publishing Tab« die eigentlichen Verbindungsdaten zum Verzeichnisdienst einzutragen. Sendet ein User nun eine Zertifikatsanfrage an den Dogtag-Server, so wird das ausgestellte Zertifikat unmittelbar auf dem konfigurierten LDAP-Server veröffentlicht. Eine manuelle Abfrage des Directory-Servers bestätigt dies (Listing 2).

Listing 2

<C>ldapsearch<C>

ldapsearch -x -b dc=tuxgeek,dc=de -h tiffy.tuxgeek.de uid=tscherf -LLL
dn: UID=tscherf,ou=people,DC=tuxgeek,DC=de
cn: Thorsten
sn: Scherf
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: tscherf
userCertificate;binary:: MIIDDzCCAfegAwIBAgIBCTANBgkqhkiG9w0BAQUFADA5MRcwFQYDV
 QQKEw5UdYhnZWVrIERvbWFpbjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA4MT
 ExMTE3MzkwM1oXDTA5MDUxMDE3MzkwM1owSTERMA8GA1UEAxMIZm9vMiBiYXIxHjAcBgkqhkiG9w0
 BCQEWD2ZvbzJAdHV4Z2Vlay5kZTEUMBIGCgmSJomT8ixkAQETBGZvbzIwgZ8wDQYJKoZIhvcNAQEB
 BQADgY0AMIGJAoGBAO22zHGO/tIuKect+DMiWl4l5OtA4oQKp8DbQrBhVl8R4O7MroY6+g6EeDwpJ
 6NFPFkbrxK4F+e5Pil1Sthr9LVjUb+E1CJGtdsWli3lrEnmdy2NjLRXY1obTwLn2PSd4Q4WGKcYGp
 BlZT4QmoVhlJ3pByalIIJvRPhrSuZn4VThAgMBAAGjgZUwgZIwHwYDVR0jBBgwFoAUhKOWr9dAuOM
 17u1W0oe8MD7vG/YwQAYIKwYBBQUHAQEENDAyMDAGCCsGAQUFBzABhiRodHRwOi8vdGlmZnkudHV4
 Z2Vlay5kZTo5MDgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCB
 ggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEApSA7qHWm4dvjf6WcPm9rChDD0OMfbSL8HzCYCd
 /b5RfrCAB7EOa5wdJNb8ldEi4Zj9OD3r4yxq7QJlOSlKUxd+vmrRLLCeDZZMsFUE5owdOMP7QCSzs
 T+FMOQZaAVGrKFNbv06ceuaKssb0HrD6gSAmFpqGP3wEhKHIGt76hHbmsYgl3gMawFpWmzuqEDzlx
 KMeo0jdQF++icxnh3zpkJSyLwueGM33kQ2zmU6buZfSt/ROJ8qo4Te58Wy/G1l01eI6NAMdMzKI0r
 5nQLyEprj6j3ZU99+taxW+tHM9sjBXvEt1PCDTSiSrTv33064+qrEs4EGiaLWfPLikYafmxng==

Hier ist darauf zu achten, dass für den betreffenden Benutzer bereits ein Objekt in der angegebenen Organisations-Einheit (OU) existiert, sonst funktioniert die Veröffentlichung des Zertifikats nicht. Außerdem finden sich nur Zertifikate für neue Anfragen im LDAP wieder; Zertifikate die vor der Publishing-Konfiguration entstanden, landen somit nicht automatisch im Verzeichnis-Dienst, lassen sich aber nachträglich, beispielsweise mittels »ldapmodify« , hinzufügen.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019