4. Testbericht und Anmerkungen

  4.1 OpenSSL

Das OpenSSL-Paket funktioniert recht stabil. Allerdings führen schon kleine Schreibfehler zu, auf den ersten Blick nicht sehr verständlichen, Fehlermeldungen folgender Art (die zweite Zeile ist eine Meldung vom Betriebssystem):

> openssl x509 -inform der -in cert-6,der -text
cert-6,der: No such file or directory
unable to load certificate
261:error:02001002:system library:fopen:system lib:bss_file.c:271:fopen('cert-6,der','r')
261:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:273:
          

Die OpenSSL-Applikation ca unterscheidet zwischen Groß-/Klein-Schreibung in Zertifikaten und Anforderungen! Mit anderen Worten, es ist möglich, ein inhaltlich gleiches Zertifikat zweimal herauszugeben; z.B. einmal mit Locality Name Hamburg und das andere Mal mit HAMBURG. Auch ist es möglich, daß sich vielleicht nur ein zusätzliches Leerzeichen eingeschlichen hat. Die Zertifikate würden sich jedoch durch die Seriennummer und die unterschiedliche Signatur unterscheiden.

Die Erzeugung eines Root-CA-Zertifikat ist in OpenSSL besser gelöst als in SSLeay, da es jetzt nicht mehr notwendig ist, Extensions nachträglich in das Zertifikat zu patchen. Allerdings wird bei der Erzeugung eines Root-Zertifikats kein Eintrag in die Index-Datei (index.txt) vorgenommen. Ebenso ist die Seriennummer des Root-Zertifikats auf "00" festgelegt. Beides ist nicht immer wünschenswert.

Zertifikate werden von OpenSSL über Hash-Werte, die über den Distinguished Name (und evtl. die E-Mail-Adresse) gebildet werden, identifiziert. Probleme können auftreten, wenn ein Root-Zertifikat erneuert werden muß und der Distinguished Name nicht geändert werden kann oder soll. Die Konsequenzen sind offensichtlich. Verläßt sich eine Applikation (womit hier nicht nur OpenSSL gemeint ist) zur Identifizierung des Root-Zertifikats nur auf den Hash-Wert des Issuer-DN (aus dem zu prüfenden Zertifikat), und nicht zusätzlich auf die Extension Authority Key Identifier, kann das Root-Zertifikat nicht mehr (eindeutig) identifiziert werden. Die Überprüfung von Zertifikatketten würde dann vermutlich fehlschlagen.

Wird für die Seriennummer in serial.txt die Hex-Zahl 00 eingetragen, steht nach Herausgabe des nächsten (ersten) Zertifikates die Seriennummer in der Datei serial.txt auf 5C5C5C5D... Die Seriennummer des gerade herausgegebenen neuen Zertifikats ist dann 0 (einstellig).

Ein Verzeichnis newcerts wird bei Aufruf von make install nicht angelegt. Die Default-Konfigurationsdatei erwartet dieses Verzeichnis aber. Das Verzeichnis muß daher nachträglich angelegt werden.

Ansonsten ist die Verwaltung von Zertifikaten und der Betrieb einer CA mit OpenSSL gut möglich. An einigen Stellen ist allerdings Handarbeit notwendig, die aber auch teilweise als Cron-Job mit Hilfe von Skripten erledigt werden kann. Dazu zählen folgende Punkte:

  4.2 Zertifikate und CRLs mit dem Netscape Browser

Zertifikate und CRLs können von einem HTTP-Server als spezielle MIME-Types an einen Browser gesendet werden. Dazu müssen die Zertifikate und die CRLs im (binären) DER-Format vorliegen. Üblicherweise erzeugen die OpenSSL-Applikationen Dateien im PEM-Format (Base64). Es besteht aber die Möglichkeit, die Dateien nachträglich in das DER-Format umzuwandeln. Zertifikate werden durch folgenden Befehl in das DER-Format umgewandelt:

openssl x509 -in cert.pem -outform der -out cert.der

Der entsprechende Befehl, um eine CRL in das DER-Format zu wandeln, lautet:

openssl crl -in crl.pem -outform der -out crl.der

Achtung:
Netscape-Browser akzeptieren (bisher) keine X.509v2 CRLs. Genaueres steht im Abschnitt über CRLs.

Zertifikate

Mit OpenSSL erzeugte Zertifikate lassen sich in den Netscape Communicator/Navigator (NSC) relativ einfach importieren.

Allerdings lassen sich keine Zertifikate, deren Schlüssellängen größer als 1024 Bit ist, mit Browser-Versionen vor 4.0 verwenden. Ein solcher Browser bricht die Verbindung zu einem Server ab, wenn sich in der Zertifikatkette ein Zertifikat mit einem solchen langen Schlüssel befindet.

Zertifikat im (binären) DER-Format kann von einem HTTP-Server als einer der folgenden MIME-Typen an den Browser geschickt werden:

Die MIME-Types signalisieren dem Browser, daß es sich um ein Zertifikat handelt, und der Browser startet dann einen entsprechenden Interaktions-Modus. Der Browser bietet dem Benutzer in Abhängigkeit vom MIME-Type und der Erweiterung Netscape-Cert-Type eine Auswahl an, für welchen Zweck ein Zertifikat bestimmt ist. Im folgenden eine Aufstellung der Browser-Vorschläge in Abhängigkeit von Cert- und MIME-Type.

Zertifikate als MIME-Type x-x509-ca-cert gesendet:

[ mimeCACert.gif ]

Zertifikate als MIME-Type x-x509-user-cert gesendet:

Alle Zertifikate werden unabhängig vom Netscape-Cert-Type als "eigene E-Mail Benutzer-Zertifikate" erkannt.

Zertifikate als MIME-Type x-x509-email-cert gesendet:

Alle Zertifikate werden unabhängig vom Netscape-Cert-Type als "fremdes E-Mail Benutzer-Zertifikat" erkannt. Nachdem die Zertifikate akzeptiert wurden, werden sie allerdings in unterschiedliche NSC-Zertifikat-Rubriken, " People" und "Certificate/Signers" einsortiert. Die drei Zertifikat-Typen (nsCertType objCA, objsign, server), die in folgender Aufstellung fehlen, sind nach Akzeptieren des Zertifikats in keiner Rubrik des Browsers mehr aufzufinden.

[ mimeUserCert.gif ]

Der NSC akzeptiert Schlüssellängen von 2048 Bit für CA-Zertifikate. Für Benutzerzertifikate beträgt die max. Schlüssellänge 512 Bit bei der Export-Version des Browsers. Im Allgemeinen werden CA-Zertifikate von einem Server (die entsprechende Konfiguration des Servers vorausgesetzt) im binären DER-Format zur Verfügung gestellt. Der Benutzer kann dann das CA-Zertifikat als MIME-Type x-x509-ca-cert (in der Regel über eine HTML-Seite) in den Browser laden. Er wird dabei durch einen Interaktionmodus geführt, in dessen Verlauf er bestimmen kann, welches Vertrauen er dem Zertifikat entgegen bringt. Laut Steve Henson kann jedes Zertifikat, unabhängig von der Art der enthaltenen Extensions, nach Durchlaufen des Interaktions-Modus als CA für jeden Zweck akzeptiert werden. Ist in dem CA-Zertifikat z.B. kein Bit gesetzt, welches die CA als Herausgeber von S/MIME-Zertifikaten kennzeichnet, und wird ein von dieser CA herausgegebenes Zertifikat zum Signieren von E-Mail verwendet, wird die Mail beim Empfänger wegen des ungültigen CA-Zertifikats abgewiesen.

Die Möglichkeit, CA-Zertifikate über Benutzerzertifikate ohne Web-Server in den NSC zu importieren, wird in PFX bzw. PKCS12 beschrieben. Eine Schlüsselerzeugung mit anschließender Online-Zertifizierung wird unterstützt. Da der Schlüssel vom Browser erzeugt wird, ist hier bei der Export-Version die Schlüssellänge auf 512 Bit beschränkt. Bei Verwendung der oben genannten Programme ist es möglich, die max. Schlüssellänge für Benutzerzertifikate auf 2048 Bit zu erhöhen (getestet mit Version 4.0 und 4.05). SSL-Server-Zertifikate werden beim Anwählen eines SSL-Servers automatisch geladen. Liegt das CA-Zertifikat für einen solchen Server nicht vor, wird ebenfalls ein Interaktionsmodus gestartet, in dessen Verlauf der Benutzer selber entscheiden muß, welches Vertrauen er dem Server-Zertifikat entgegenbringt. Liegt dagegen das CA-Zertifikat vor, bekommt der Benutzer in Abhängigkeit von der vorgenommenen Einstellung am Browser keine oder nur eine kleine Meldung. (Es sei an dieser Stelle darauf hingewiesen, daß der Server beim Verbindungsaufbau die Möglichkeit hat, zusätzlich zu seinem eigenen Zertifikat auch die Zertifikate der übergeordneten CA(s) mitzuliefern.)

CRLs

Achtung:
Netscape-Browser akzeptieren (bisher) keine X.509v2 CRLs. Genaueres steht im Abschnitt über CRLs.

Die im folgenden verwendeten CRLs waren vom Typ X.509v1.

CRL als MIME-Type x-pkcs7-crl gesendet:

Der Browser (Vers. 4.03) akzeptiert die CRL, ohne eine Meldung auszugeben. Wird versucht, die CRL ein zweites Mal zu laden, wird die folgende Error-Box angezeigt:

[ crlNotLater.gif ]

Nachdem in einem Browser Vers. 4.05 eine CRL geladen wurde, taucht im Security Fenster nach Anwahl der Rubrik "Signers" ein neuer Button "Edit/View CRL's " auf. Darüber lassen sich CRLs anzeigen, löschen und neu laden.

CRL als MIME-Type x-x509-crl gesendet:

Der Browser (Vers. 4.03) lädt das CRL-Binary nicht als CRL, sondern als Text mit entsprechend kryptischen Zeichen im Browser-Fenster.

Wurde eine CRL, die ein widerrufenes SSL-Server Zertifikat enthielt, in einen Browser der Vers. 4.05 gebracht, wird anschließend eine Verbindung zu dem entsprechenden SSL-Server verweigert. Allerdings mit einer wenig hilfreichen Meldung der Art "Es gibt Schwierigkeiten..."

Der Browser gibt folgende Meldung aus, wenn der Gültigkeitszeitraum einer schon geladenen CRL überschritten ist:

[ crlExpired.gif ]

Es muß dann zunächst die aktuelle CRL geladen werden, bevor erneut eine Verbindung aufgebaut werden kann.

  4.3 Zertifikate und CRLs mit MS Internet Explorer

Der Internet Explorer (MSIE) unterstützt u.a. die Standard X509v3-Attribute wie Basic Constraints und Key Usage (siehe jedoch Zertifizieren). Um ein CA-Zertifikat für den MSIE als solches zu kennzeichnen, muß das "CA-Bit" in Form von Basic Constraints gesetzt werden. Außerdem kann über Key Usage die Verwendung des Zertifikats eingeschränkt werden. Der Browser interpretiert laut MS-Dokumentation Key Usage immer, egal ob Critical oder nicht.

Die folgende Angaben beziehen sich auf den MSIE 4.0. Es ist dabei zu berücksichtigen, daß sich das Verhalten des Browsers unter Windows NT in Abhängigkeit vom installierten Servicepack ändern kann.

Der MSIE akzeptiert Schlüssellängen von 2048 Bit für CA-Zertifikate. Für Benutzerzertifikate beträgt die max. Schlüssellänge 512 Bit bei der Export-Version des Browsers.

Allerdings lassen sich keine Zertifikate, deren Schlüssellängen größer als 1024 Bit ist, mit Browser-Versionen vor 4.0 verwenden. Ein solcher Browser bricht die Verbindung zu einem Server ab, wenn sich in der Zertifikatkette ein Zertifikat mit einem solchen langen Schlüssel befindet.

CA-Zertifikate können über einen Web-Server als MIME-Type x-x509-ca-cert gesendet werden (siehe Testbericht). Sie werden als CA-Zertifikate für "Netzwerk-Client-", "Netzwerk-Server-Authentifikation", "Sichere-E-Mail" und "Software-Herausgeber" akzeptiert. Der Benutzer wird dabei durch einen Interaktionmodus geführt, in deren Verlauf das Zertifikat entweder lokal auf der Festplatte gespeichert oder gleich geöffnet werden kann. Wurde das Zertifikat gespeichert, kann es später jederzeit durch einen "Doppelklick" geladen (akzeptiert) werden. Nach Akzeptieren findet sich das Zertifikat in der Rubrik "Ansicht / Internetoptionen / Inhalt / Agenturen". Es besteht die Möglichkeit, über Kontrollkästchen die Beschränkungen des Zertifikats einzeln zu (de-)aktivieren.

Benutzer-Zertifikate können auf zwei Arten in den MSIE gebracht werden. Die eine Art umfaßt die Schlüssel- und Request-Erzeugung mit den Browser durch Ausführen eines Java- oder VB-Skript. Anschließend wird der Request online zertifiziert. Wenn die Schlüsselerzeugung durch einen Export-MSIE erfolgt, ist die Schlüssellänge auf 512 Bit beschränkt. Durch Austausch einer Krypto-Bibliothek im Windows-System besteht die Möglichkeit, die Schlüssellänge zu erhöhen. Genaueres dazu findet sich auf Hensons PKCS#12-Seite. Auf die Methode Schlüsselerzeugung durch den Browser und anschließender Online-Zertifizierung wird hier nicht weiter eingegangen.

Die zweite Möglichkeit besteht darin, wie im Abschnitt Erzeugen von Requests beschrieben, einen mit OpenSSL erzeugten Request zu signieren und diesen anschließend als .p12-Datei in den Browser zu importieren. Allerdings besteht die Möglichkeit größere Schlüssel zu importieren, wenn der oben erwänhte Austausch einer Krypto-Bibliothek erfolgte. Um das Zertifkat (in Form der .p12-Datei) zu laden, muß in der Rubrik "Ansicht / Internetoptionen / Inhalt / Eigene" eine Dialogbox geöffnet werden, wo über den Button "Importieren" das Zertifikat importiert werden kann. Die in den Browser gebrachten Zertifikate stehen auch im MS-Mail Programm Outlook-Express (OE) zur Verfügung, wenn die im Zertifikat angegebene E-Mail-Adresse mit der im OE übereinstimmt.

Benutzer-Zertifikate erfahren keinen speziellen Schutz durch den MSIE. Der einzige Schutz besteht im Zugangsschutz durch das Betriebssystem... MS hat ein Kommandozeilen-Tool herausgegeben, mit dem die Sicherheitsstufe für Zertifikate und deren Privat-Keys erhöht werden kann. Genaueres dazu hat Steve Henson auf einer eigenen eigenen Seite zusammengetragen.

CRLs bezieht der MSIE über eine im Zertifikat angegebene URI. Die URI wird über die Extension "CRL Distribution Points" in ein Zertifikat gebracht. Leider unterstützt OpenSSL-0.9.2b diese Extension noch nicht. Eine Zertifikatprüfung erfolgt erst, wenn im Browser in der Rubrik "Ansicht / Internetoptionen / Erweitert" im Abschnitt "Sicherheit" das Kontrollkästchen "Auf zurückgezogene Zertifikate überprüfen" angewählt ist.


Copyright © 1996 - 2000 by DFN-PCA / certify@pca.dfn.de