Dogtag als Public-Key-Infrastruktur (PKI)

Aus ADMIN 01/2009

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.

01 certutil -L -d ~/.mozilla/firefox/i1nfei2a.default/ | grep -i tux
02 Certificate Authority - Tuxgeek Domain                       CT,C,C
03 CA Administrator of Instance pki-ca's Tuxgeek Domain ID      u,u,u
04 foo1 bar's Tuxgeek Domain ID                                 u,u,u
05 foo2 bar's Tuxgeek Domain ID                                 u,u,u
06 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).

01 ldapsearch -x -b dc=tuxgeek,dc=de -h tiffy.tuxgeek.de uid=tscherf -LLL
02 dn: UID=tscherf,ou=people,DC=tuxgeek,DC=de
03 cn: Thorsten
04 sn: Scherf
05 objectClass: top
06 objectClass: person
07 objectClass: organizationalPerson
08 objectClass: inetOrgPerson
09 uid: tscherf
10 userCertificate;binary:: MIIDDzCCAfegAwIBAgIBCTANBgkqhkiG9w0BAQUFADA5MRcwFQYDV
11  QQKEw5UdYhnZWVrIERvbWFpbjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA4MT
12  ExMTE3MzkwM1oXDTA5MDUxMDE3MzkwM1owSTERMA8GA1UEAxMIZm9vMiBiYXIxHjAcBgkqhkiG9w0
13  BCQEWD2ZvbzJAdHV4Z2Vlay5kZTEUMBIGCgmSJomT8ixkAQETBGZvbzIwgZ8wDQYJKoZIhvcNAQEB
14  BQADgY0AMIGJAoGBAO22zHGO/tIuKect+DMiWl4l5OtA4oQKp8DbQrBhVl8R4O7MroY6+g6EeDwpJ
15  6NFPFkbrxK4F+e5Pil1Sthr9LVjUb+E1CJGtdsWli3lrEnmdy2NjLRXY1obTwLn2PSd4Q4WGKcYGp
16  BlZT4QmoVhlJ3pByalIIJvRPhrSuZn4VThAgMBAAGjgZUwgZIwHwYDVR0jBBgwFoAUhKOWr9dAuOM
17  17u1W0oe8MD7vG/YwQAYIKwYBBQUHAQEENDAyMDAGCCsGAQUFBzABhiRodHRwOi8vdGlmZnkudHV4
18  Z2Vlay5kZTo5MDgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCB
19  ggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEApSA7qHWm4dvjf6WcPm9rChDD0OMfbSL8HzCYCd
20  /b5RfrCAB7EOa5wdJNb8ldEi4Zj9OD3r4yxq7QJlOSlKUxd+vmrRLLCeDZZMsFUE5owdOMP7QCSzs
21  T+FMOQZaAVGrKFNbv06ceuaKssb0HrD6gSAmFpqGP3wEhKHIGt76hHbmsYgl3gMawFpWmzuqEDzlx
22  KMeo0jdQF++icxnh3zpkJSyLwueGM33kQ2zmU6buZfSt/ROJ8qo4Te58Wy/G1l01eI6NAMdMzKI0r
23  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.

Ungültige Zertifikate

Oft genug kommt es vor, dass Zertifikate ihre Gültigkeit verlieren, beispielsweise dann, wenn der private Schlüssel zu dem Zertifikat verloren ging. Damit alle betroffenen Anwendungen von solch ungültigen Zertifikaten erfahren, lassen sich sogenannte Zertifkats-Sperrlisten (Certificate Revocation Lists, CRL) erzeugen. Hierbei handelt es sich um öffentlich zugängliche Listen, die beispielsweise ein Webbrowser, periodisch abfragen oder importieren kann, um ungültige Zertfikate zu erkennen.

Welche Zertifikate auf dieser Sperrliste landen, kann der Administrator einer CA, wie auch der Eigentümer des betreffenden Zertifikats selbst, entscheiden. Der Administrator kann sich über die »Agent Services« unter dem Menüpunkt »Search for Certificates« alle ausgestellen Zertifikate auflisten lassen und dann über »Revoke« festlegen, welches davon auf der Sperrliste landet. Natürlich kann er auch gezielt nach einem bestimmtem Zertifikat suchen. Über »Update Revokation List« und »Display Revokation List« ist die CRL erst zu aktualisieren, bevor die geänderte Version auf dem Bildschirm erscheint (Abbildung 5).

Abbildung 5: Ein Benutzer-Zertifikat wurde der CRL hinzugefügt.

Ein Endanwender kann nun über die »SSL End Users Services« eine aktuelle Version der CRL in seine Anwendung importieren. Der Menüpunkt »Retrieval | Import Certificate Revocation List | Import the latest CRL to your browser« startet den Import-Vorgang (Abbildung 6). In den Eigenschaften des Browsers legt der Anwender fest, wie oft er die CRL aktualisieren möchte, um sich nicht immer wieder manuell um eine neue Version der Sperrliste bemühen zu müssen. Der Inhalt der CRL lässt zeigt der Webbrowser über die »Eigenschaften« (Abbildung 6). Direkt aus der Dogtag-Datenbank liest ihn der Aufruf in Listing 3.

01 ldapsearch -LLL -x -b dc=tuxgeek,dc=de -h tiffy.tuxgeek.de -D
02 cn="Directory Manager" -w password objectClass=certificationAuthority
03 certificateRevocationList
04 dn: UID=Certificate Authority,OU=people,DC=tuxgeek,DC=de
05 certificateRevocationList;binary:: MIIBtjCBnwIBATANBgkqhkiG9w0BAQUFADA5MRcwFQY
06  DVQQKEw5UdXhnZWVrIERvbWFpbjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5Fw0wODEx
07  MTMxMjQ2MjZaFw0wODExMTMxNjQ2MjZaMCIwIAIBCRcNMDgxMTEyMTUwNjU0WjAMMAoGA1UdFQQDC
08  gEBoA4wDDAKBgNVHRQEAwIBDDANBgkqhkiG9w0BAQUFAAOCAQEAHpdSIx/tm3u0ALqhbKJwdDVUsx
09  V/TaARtJ9Xthw5/EblPTrngNLmN1iVpdBRO2Nr0vFfLdqGwDTpli35jUmK4mOyD5viVv1dv9TmEwG
10  aCU2q3SQceRcHAliAJv/2ol28Rr1/Dk+5LtgpppWxia2Smbt8II/ZZPsq1kwy2EmOWR9V8z40Wode
11  Eb3HUQzpZefKje8otH1xSX3eG7roblcVhFP/CnlHGfUDEB1sCGvv9VQkLQQqjQoGKvz2HMs6LiOv1
12  VmRfjXzlblrHBzHSmesliuGaCmZCaHg91WeEic1q7xJfOnw1v+VgpfidEV4gm+Ty5IYICcvEBlN7k
13  wjLbX06A==

Schickt man lediglich den Inhalt des certificateRevocationList Attributs an das Tool »PrettyPrintCrl«, findet man den Inhalt der CRL etwas schöner formatiert vor.

Abbildung 6: In einer Client-Anwendung lässt sich die CRL dann importieren.

CRLs haben den entscheidenen Nachteil, das sie manuell zu pflegen sind. Unter Umständen sind jede Menge unterschiedliche Server, von denen man in regelmäßigen Abständen eine CRL beziehen möchte, in der lokalen Client-Applikation einzutragen. Das ist sehr umständlich und verbraucht natürlich auch Plattenplatz, da die CRLs ja im lokalen Dateisystem gespeichert werden. Einfacher ist es dann, wenn man einen Client besitzt, der zum Online Certificate Status Protocol (OCSP) kompatibel ist. Hiermit lassen sich Zertifikate von ganz unterschiedlichen Zertifikatsstellen in Echtzeit abfragen. Einzige Voraussetzung hierfür: Die ausgebende Zertifikatstelle betreibt einen eigenen OCSP-Responder, der Client-Anfragen nach der Gültigkeit eines Zertifikats beantwortet. Ist dieser OCSP-Responder vorhanden, so besitzen alle Zertifikate dieser CA die Erweiterung »Authority Information Access«. Hier wird die URL des Responders hinterlegt. Ein manuelles Konfigurieren der Client-Anwendung entfällt somit.

Fazit

Mit Dogtag steht endlich auch im Open-Source-Umfeld eine leistungsstarke PKI-Infrastruktur zur Verfügung. Dank der Webinterfaces und der grafischen Konsole hat man sich auch sehr schnell in die Bedienung und Administration eingearbeitet. Mit Hilfe diverser Templates unter »/var/lib/pki-ca/webapps« lässt sich sogar das Look and Feel der Anwendung an die eigenen Wünsche anpassen. (ofr)

Infos

[1] Dogtag-Wiki: [http://pki.fedoraproject.org/wiki/PKI_Main_Page]

[2] Dogtag Data Storage: [http://pki.fedoraproject.org/wiki/PKI_Data_Storage_Requirements]

[3] PKCS-Spezifikation: [http://de.wikipedia.org/wiki/PKCS]

[4] Certutil: [http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html]