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:
newcerts
nach certs
kopiert werden.
Anschließend müssen die Zertifikate über ihren
Hash-Wert "verlinkt" werden.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:
application/x-x509-email-cert
application/x-x509-user-cert
application/x-x509-ca-cert
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:
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.
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:
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:
Es muß dann zunächst die aktuelle CRL geladen werden, bevor erneut eine Verbindung aufgebaut werden kann.
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.