wie beispielsweise MD5 oder SHA-1, schickt. Dekodiert

Transkript

1 Public-Key-Infrastruktur mit Dogtag Guter Hüter Hat die Systemlandschaft eine gewisse Größe erreicht, möchte man digitale Zertifikate nicht mehr mit Open- SSL verwalten. Hier hilft eine Public-Key-Infrastruktur () weiter. Mit Dogtag, der Open-Source-Variante von Red Hats Zertifikats-System, existiert dafür eine leistungsstarke und komfortable Lösung. Thorsten Scherf 3 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 bildet ein Hash eine Art Zusammenfassung der Nachricht. Ihn verschlüsselt der Absender mit seinem privaten Schlüssel. Den so erzeugten 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, schickt. Dekodiert man dann den verschlüsselten Hash mit dem öffentlichen Schlüssel des Absenders, sollte das gleiche Ergebnis herauskommen, andernfalls lassen sich Integrität und Authentizität der Nachricht nicht bestätigen. Problem: Schlüsseltausch Abbildung 1: Zur Konfiguration bietet Dogtag ein komfortables Webinterface an. 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 () 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 gehören mehrere, teilweise optionale Komponenten. Hierzu zählen unter anderen: n Eine Zertifizierungsstelle (Certificate Authority, CA) n Eine Registrierungsstelle (Registration Authority, RA) n Eine Zertifikatsperrliste (Certificate Revocation List, CRL) n Ein Verzeichnisdienst (LDAP-Server) n Ein Validierungsdienst (Online Certificate Status Protocol, OCSP) n Ein Daten-Recovery-Agent (DRA) n 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 zu beglaubigen. Oft existiert eine ganze Hierachie von Zertifizierungsstellen, wobei die oberste CA der Hierachie, die sogenannte Root-CA, lediglich Signierungs-Zertifikate für untergeordnete Zertifizierungstellen ausgibt. Diese sind Andrea Müller

2 4 01 [pki] 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 den Zertifikaten, 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. Dogtag-Zertifikatssystem Ab Fedora Version 8 steht Dogtag als -Implementierung unter einer Open- Source-Lizenz zur Verfügung. Damit die entsprechenden Pakete den Weg auf das 02 name=certificate System $basearch Listing 2:»certutil«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 eigene System finden, ist eine yum- Konfiguratonsdatei»pki.repo«im Ordner»/etc/yum. repos.d«abzulegen (Listing 1). Zum Speichern der ausgestellen Zertifikate benötigt Dogtag den Fedora-Directory- Server (FDS), der sich leicht über ein Yum-Repository installieren lässt. Die genaue Installation beschreibt [2]. Benutzern. 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 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, -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 03 baseurl= svn.fedora.redhat.com/pki/download/pki/1.0.0/fc$releasever/rpms/$basearch/ [pki source] Listing 1:»pki.repo«06 name=certificate System Source 07 baseurl= svn.fedora.redhat.com/pki/download/pki/1.0.0/fc$releasever/srpms/ Abbildung 2: Über das grafische Admin-Werkzeug»pkiconsole«lassen sich viele Eigenschaften des Dogtag-Servers konfigurieren, hier die Authentifizierung von 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«. Ü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» 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.

3 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, 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 U 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 di- Abbildung 3: Das erzeugte Zertifikat lässt sich über die Seite»SSL End Users Services«herunterladen. 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 starten (Abbildung 2). 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 Benutzerverse 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 2. 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 Listing 2:»ldapsearch«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 ExMTE3MzkwM1oXDTA5MDUxMDE3MzkwM1owSTERMA8GA1UEAxMIZm9vMiBiYXIxHjAcBgkqhkiG9w

4 6 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. Gerade in großen Umgebungen bietet es sich an, die erzeugten X.509-Zertifikate automatisch in einem Verzeichnisdienst 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 Listing 4:»ldapsearch«01 $ PrettyPrintCrl /tmp/crl.txt 02 Certificate Revocation List: 03 Data: 04 Version: v2 05 Signature Algorithm: SHA1withRSA Issuer: CN=Certificate Authority,O=Tuxgeek Domain 07 This Update: Thursday, November 13, :46:26 PM CET Europe/Berlin 08 Next Update: Thursday, November 13, :46:26 PM CET Europe/Berlin 09 Revoked Certificates: 10 Serial Number: 0x9 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. 11 Revocation Date: Wednesday, November 12, :06:54 PM CET Europe/Berlin 12 Extensions: 13 Identifier: Revocation Reason Critical: no 15 Reason: Key_Compromise 16 Extensions: 17 Identifier: CRL Number Critical: no 19 Number: Signature: 21 Algorithm: SHA1withRSA Signature: Listing 5:»PrettyPrintCrl«23 1E:97:52:23:1F:ED:9B:7B:B4:00:BA:A1:6C:A2:70:74: 24 35:54:B3:15:7F:4D:A0:11:B4:9F:57:B6:1C:39:FC:46: 25 E5:3D:3A:E7:80:D2:E6:37:58:95:A5:D0:51:3B:63:6B: 26 D2:F1:5F:2D:DA:86:C0:34:E9:96:2D:F9:8D:49:8A:E2: 27 63:B2:0F:9B:E2:56:FD:5D:BF:D4:E6:13:01:9A:09:4D: 28 AA:DD:24:1C:79:17:07:02:58:80:26:FF:F6:A2:5D:BC: 29 46:BD:7F:0E:4F:B9:2E:D8:29:A6:95:B1:89:AD:92:99: 30 BB:7C:20:8F:D9:64:FB:2A:D6:4C:32:D8:49:8E:59:1F: 31 55:F3:3E:34:5A:87:5E:11:BD:C7:51:0C:E9:65:E7:CA: 32 8D:EF:28:B4:7D:71:49:7D:DE:1B:BA:E8:6E:57:15:84: 33 53:FF:0A:79:47:19:F5:03:10:1D:6C:08:6B:EF:F5:54: 34 24:2D:04:2A:8D:0A:06:2A:FC:F6:1C:CB:3A:2E:23:AF: 35 D5:59:91:7E:35:F3:95:B9:6B:1C:1C:C7:4A:67:AC:96: 36 2B:86:68:29:99:09:A1:E0:F7:55:9E:12:27:35:AB:BC: 37 49:7C:E9:F0:D6:FF:95:82:97:E2:74:45:78:82:6F:93: 38 CB:92:18:20:27:2F:10:19:4D:EE:4C:23:2D:B5:F4:E8 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 dn- Pattern-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»LD- APCrlMap«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 4). 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 betreffen-

5 Abbildung 4: Über»pkiconsole«lassen sich die ausgestellen Zertifikate im LDAP veröffentlichen. den Zertifikats selbst, entscheiden. Der Administrator kann sich über die»agent Services«unter dem Menüpunkt»Search for Certificates«alle ausgestellen Zertifikate auflisten und dann über»revoke«festlegen, welches davon auf der Sperrliste landet. Natürlich kann er auch gezielt nach einem bestimmtem Zertifikat suchen. Über»Update Revocation List«und»Display Revocation List«ist die CRL erst zu aktualisieren, bevor die geänderte Version auf dem Bildschirm erscheint (Abbildung 5). 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. Den Inhalt der CRL zeigt der Webbrowser über die»eigenschaften«(abbildung 6). Schickt man lediglich den Inhalt des»certificaterevocationlist«-attributs an das Tool»PrettyPrintCrl«, findet man den Inhalt der CRL etwas schöner formatiert vor (Listing 5). 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 hinterlegt der Admin die URL des Responders. Ein manuelles Konfigurieren Abbildung 5: Ein Benutzer-Zertifikat wurde der CRL hinzugefügt. der Client-Anwendung kann er sich somit sparen. als Open Source Abbildung 6: In einer Client-Anwendung lässt sich die CRL dann importieren. Mit Dogtag steht endlich auch im Open- Source-Umfeld eine leistungsstarke - Infrastruktur zur Verfügung. Dank der Webinterfaces und der grafischen Konsole arbeitet man sich sehr schnell in die Bedienung und Administration ein. 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) n Infos [1] Dogtag-Wiki: [ pki. fedoraproject. org/ wiki/ _Main_Page] [2] Dogtag Data Storage: [ pki. fedoraproject. org/ wiki/ _ Data_Storage_Requirements] [3] PKCS-Spezifikation: [ de. wikipedia. org/ wiki/ PKCS] [4] certutil: [ www. mozilla. org/ projects/ security/ pki/ nss/ tools/ certutil. html] 7