3. Zum Gebrauch von OpenSSL

  3.1 OpenSSL-Konfigurationsdatei, openssl.cnf

Eine Beispiel-Konfigurationsdatei findet sich im Anhang openssl.cnf.

Die Belegung von Aufruf-Optionen der OpenSSL-Applikationen wird weitestgehend durch die Konfigurationsdatei $(SSL_DIR)/lib/openssl.cnf bestimmt. Sie ist ähnlich aufgebaut wie eine Windoze-Ini-Datei. Einzelne Abschnitte sind gekennzeichnet durch Bezeichner der Form [ uvwxyz ]. Innerhalb dieser Abschnitte können Variablen vereinbart werden. Dabei ist es auch möglich, Umgebungsvariablen zu überschreiben, z.B. mit

ENV::PATH = /usr/local/ssl/bin:$PATH

Außerdem können Werte von gesetzten Umgebungsvariablen einzelnen Variablen der Konfigurationsdateien zugeordnet werden, z.B. mit

ca_default = $ENV::ENV_CA_DEFAULT

Enthält die Umgebungsvariable ENV_CA_DEFAULT den Wert Server_CA, wird bei der nächsten Zertfizierung durch die Applikation ca der Abschnitt ca_default gewählt.

Die Datei gliedert sich grob in zwei Abschnitte: [ ca ], in dem Voreinstellungen für die Erzeugung eines Zertifikats vorgenommen werden, und entsprechend [ req ] für die Erzeugung eines "Zertifizierungswunsches" (Request). Auf diese voreingestellten Abschnitte wird zugegriffen, wenn openssl mit dem Parameter ca bzw. req aufgerufen wird. (Anm.: openssl req parameter... erzeugt einen Request, openssl ca parameter... signiert einen Request.)

Sowohl ca als auch req bieten die Möglichkeit, über die Option -config die zu verwendende Konfigurationsdatei explizit anzugeben. So könnte jeweils eine Konfigurationsdatei speziell für Netscape-Browser und eine andere für Microsoft-Browser gestaltet sein.

Es ist auch möglich, innerhalb einer Konfigurationsdatei mehrere CA-Abschnitte zu definieren, je nachdem, welche Art Request signiert werden soll. Dadurch kann innerhalb einer Konfigurationsdatei eine CA-Konfiguration zur Server-Zertifizierung (z.B. [ Server_CA ]), eine Konfiguration zur Client-Zertifizierung (z.B. [ Client_CA ]) und eine zur S/MIME-Zertifizierung (z.B. [ SMIME_CA ]) verwaltet werden. Bei Aufruf von openssl mit dem Parameter ca kann dann mit der Option -name Client_CA z.B. auf eine Client-CA-Konfiguration zugegriffen werden (Anm.: Statt der oben erwähnten zwei speziellen Konfigurationsdateien kann das gleiche auch über entsprechende Konfigurationsabschnitte innerhalb einer Datei erreicht werden).

Innerhalb von CA-Abschnitten werden drei Schlüsselwörter erkannt, die auf weitere Abschnitte in einer Konfigurationsdatei verweisen. Die Schlüsselwörter lauten:

x509_extensions verweist auf einen Abschnitt, in dem Zertifikaterweiterungen (Extensions) für neue Zertifikate festgelegt sind. In diesem Abschnitt könnten die Extensions fü ein Benutzer- oder ein CA-Zertifikat festgelegt werden. crl_extensions verweist auf einen entsprechenden Abschnitt für Extensions die in eine Zertifikat-Widerrufliste (Certificate revocation list, CRL) gebracht werden sollen. policy schließlich weist auf einen Abschnitt in dem festgelegt wird, inwieweit der Name in einem zu signierenden Request mit dem des CA-Zertifikats übereinstimmen muß. Beispielsweise kann festgelegt werden, daß die Angaben zum Land übereinstimmen müssen.

Im req-Abschnitt werden ebenfalls drei Schlüsselwörter erkannt:

req_distinguished_name weist auf einen Abschnitt, in dem festgelegt wird, welche Namensfelder bei der Erzeugung des Requests abgefragt werden, sowie deren Default-Werte. Über attributes werden optionale Felder festgelegt, die zusätzlich in den Request gebracht werden können. Diese dienen zum Widerruf eines Zertifikats bei Verlust des Privat-Key. Genaueres siehe Erzeugen von Requests. In dem Bereich, auf den x509_extensions verweist, werden die Zertifikaterweiterungen festgelegt, die bei Erzeugung eines selbsignierten Zertifikats (Wurzel-Zertifikat) in dieses Zertifikat gebracht werden.

Ein ausführliches Beispiel einer Konfigurationsdatei mit mehreren Abschnitten findet sich im Anhang openssl.cnf

  3.2 Zufallszahlen mit OpenSSL

Anmerkung:
Die folgenden Angaben beziehen sich auf SSLeay-0.8.1. Möglicherweise sind sie auch noch für OpenSSL-0.9.5-dev gültig.

OpenSSL bringt einen eigenen Zufallszahlen-Generator (ZZG) mit. Im folgenden ein paar erläuternde Worte zur Funktion des ZZG. Vor der ersten Schlüsselerzeugung mit OpenSSL sollte in jedem Fall der ZZG initialisiert werden. Andernfalls ist die zur Schlüsselerzeugung heranziehbare Zufalls-Datenmenge sehr klein. Die Initialisierung kann erfolgen, indem eine beliebige Datei, die als Zufallsdaten brauchbare Daten enthält, unter dem für den ZZG-Status vorgesehenen Namen abgespeichert wird. Vorgesehener Name heißt, ein vor der Kompilierung festgelegter Name ($(SSLSRC)/e_os.h, Zeile 187), ein über eine Umgebungsvariable $RANDFILE festgelegter Name oder ein über die Konfigurationsdatei festgelegter Name. Wird allerdings eine Schlüsselerzeugung mit dem Kommando "openssl genrsa" durchgeführt, muß vorher $RANDFILE gesetzt sein, da das Kommando die Konfigurationsdatei nichtauswertet. Es wird dann die in e_os.h festgelegte Default-Datei angelegt.

Die Initialisierung des ZZG-Status könnte also z.B. durch nachstehendes Kommando erfolgen:

cp ~/.pgp/randseed.bin $RANDFILE

Beim ersten Zugriff auf die so initialisierte Status-Datei durch openssl wird die Datei nach der ersten Schlüsselerzeugung auf eine Länge von 1024 Byte begrenzt, unabhängig davon, ob weniger oder mehr Byte zur Initialisierung verwendet wurden. Jede neue Schlüsselerzeugung beeinflußt den ZZG-Status. Der Status und neue Zufallsdaten werden in Blöcke zu 16 Byte zerlegt und diese dann anschließend paarweise durch den MD5-Hash-Algorithmus geleitet. Das Ergebnis wird in einer Variable md zwischengespeichert. Dieser Zwischenspeicher (md) wird dann XOR mit dem ZZG-Status an derselben Stelle, aus der vorher die 16 Byte entnommen worden, verknüpft. Bei jedem schreibenden oder lesenden Zugriff auf den ZZG-Status wird ein Zeiger inkrementiert, so daß nicht dieselben 16 Byte des ZZG-Status verwendet werden. Durch dieses Vorgehen sollen Rückschlüsse vom ZZG-Status auf die verwendeten Zufallsdaten unmöglich gemacht werden.

Die Entnahme von Zufallszahlen aus dem ZZG geschieht folgendermaßen: Je 8 Byte werden aus dem ZZG-Status entnommen und durch den MD5-Hash-Algorithmus geleitet. Von der MD5-Ausgabe werden die ersten 8 Bytes als Zufallszahl zurückgegeben und die zweiten 8 Bytes über XOR in den ZZG-Status gebracht. Nachdem die benötigten Zufallsdaten erzeugt worden sind, werden der Wert des Zeigers auf die Position im ZZG-Status sowie der aktuelle Wert von md wieder durch den MD5-Algorithmus geleitet und das Ergebnis wird in md gehalten. Werden Schlüsselpaare über genrsa erzeugt, kann zur Initialisierung und auch bei jedem weiteren Aufruf mit der Option -rand file1:file2:... eine Liste von Dateien angegeben werden, die alle als Zufallsdaten Verwendung finden.

Wird ein Schlüsselpaar erzeugt, ohne daß der Status existiert, gibt das Programm die Meldung unable to load 'random state' aus. Werden auch keine Initialisierungs-Daten mitgegeben, meldet das Programm ferner warning, not much extra random data, consider using the -rand option. In diesem Fall werden die System-Funktionen getpid(), getuid(), time() sowie stat() auf die nicht vorhandene Status-Datei angewendet. Eine Schlüsselerzeugung findet also statt, und die entsprechend "zufälligen" Daten der obigen Systemfunktionen werden dann zur Initialisierung des Status' herangezogen.

  3.3 Zertifizieren mit OpenSSL

OpenSSL in der Version 0.9.2b unterstützt die folgenden X509.v3-Erweiterungen (Extensions):

Zertifikaterweiterungen steuern den Verwendungszweck von Zertifikaten, sofern die Anwendungssoftware diese Erweiterungen korrekt interpretiert. Üblicherweise werden diese Erweiterungen durch eine (P)CA beim Signieren eines Request in das dann erstellte Zertifikat gebracht. Die Bedeutung der "Certificate Standard Extensions" wird im " RFC 2459, Internet X.509 Public Key Infrastructure - Certificate and CRL Profile" beschrieben.

Es ist auch möglich, eigene Erweiterungen zu registrieren (was Netscape mit den "Netscape Certificate Extensions" gemacht hat). Solange diese Erweiterungen nicht als "Critical" markiert sind, sollte jede Anwendung, die diese Erweiterungen nicht kennt, diese ignorieren (das Zertifikat also akzeptieren).

Wegen der besonderen Bedeutung von Basic Constraints und Key Usage an dieser Stelle noch ein paar Anmerkungen:

Key Usage steuert den Verwendungszweck des zu einem Zertifikat gehörenden Schlüssels: z.B. darf ein Schlüssel nur zum Signieren von CRL´s, nur zur Daten-Verschlüsselung oder nur zum Unterschreiben verwendet werden. Laut Netscape Dokumentation vom 13.08.97, " NetscapeCertificate Extensions - Communicator 4.0 Version ", wird Key Usage vom Netscape Browser (NSC) zur Beschränkung der Verwendung von Zertifikaten ausgewertet. Allerdings nur, wenn Key Usage als Critical ( s.u.) markiert ist. Liegen andererseits mehrere Zertifikate vor (z.B. eins zum Signieren, eins zum Verschlüsseln) bestimmt Key Usage (Critical oder nicht), welches Zertifikat vom Browser verwendet wird.

Laut Microsoft-Dokumentation " Structuring X.509 Certificates for Use with Microsoft Products" wertet der MS-Internet-Explorer (MSIE) Key Usage aus, egal ob Critical oder nicht. Das deckt sich aber nicht ganz mit den gemachten Erfahrungen (siehe Key Usage).

Mittels Basic Constraints kann eine Anwendung erkennen, ob es sich um ein CA-Zertifikat handelt oder nicht. Diese Extension sollte in jedem CA-Zertifikat verwendet und als Critical markiert werden, auch wenn möglicherweise einige Anwendungen wegen der Critical-Markierung das Zertifikat zurückweisen.

Critical Bit

  Die oben aufgeführten Extensions Basic Constraints und Key Usage können als Critical markiert werden. Bei korrekter Implementierung einer Anwendung muß diese eine als Critical markierte Extension interpretieren. Ist die Anwendung dazu nicht in der Lage, hat sie das Zertifikat, das diese Extension enthält, zurückzuweisen, auch wenn es ansonsten technisch korrekt ist. Allerdings gibt es verschiedene Ansichten über die Verwendung der einzelnen Key Usage Attribute, so daß eine Critical-Markierung nicht ohne "Risiko" ist.

Zu den Netscape Certificate Extensions ist anzumerken, daß diese nicht Critical gesetzt werden sollten. Ein SSL-Server-Zertifikat, das beispielsweise das Netscape-SSL-Server-Bit (nsCertType) als Critical gesetzt hat, wird von einem Microsoft-Browser (der die Extension nicht kennt) zurückgewiesen. Ein solches Server-Zertifikat würde also eine SSL-Verbindung von Microsoft-Clients zum Server ausschließen.

Im folgenden ein paar weitere Anmerkungen zu den Erweiterungen.

  3.3.1 Key Usage

Key Usage wird von OpenSSL-0.9.2b direkt unterstützt. Üblicherweise wird Key Usage eingesetzt, um die Verwendung des Public Keys (und somit auch des Private Keys), an den diese Extension durch die Zertifizierung gebunden wird, zu beschränken. Das funktioniert natürlich nur, wenn die Applikation, mit der das Zertifikat verwendet wird, diese Extension auch interpretiert. Der Netscape Browser (4.06) beispielsweise verweigert den Kontakt zu einem SSL-Server, wenn im Server-Zertifikat das Flag für Digital Signature gesetzt und dieses Critical markiert ist. Laut Netscape Dokumentation sollte dieses Flag in einem SSL-Client-Zertifikat gesetzt sein. Für einen SSL-Server hätte dagegen Key Encipherment gesetzt sein müssen. Der Browser läßt daher keine SSL-Verbindung zu und bricht den Verbindungswunsch mit der Meldung "The certificate is not approved for the attempted operation" ab. Dasselbe Zertifikat wurde aber vom Microsoft-Browser (Ver. 4.01) problemlos akzeptiert. In der Microsoft-Dokumentation " Structuring X.509 Certificates for Use with Microsoft Products" vom 4.12.97 steht im Abschnitt zum Thema Key Usage: "The only Microsoft Application that currently enforces KeyUsage is Microsoft Outlook."

Die nachstehende Beschreibung erfolgt in Anlehnung an die oben erwähnte Netscape-Dokumentation und den RFC 2459. Es stehen neun Werte für das Schlüsselwort keyUsage in der Konfigurationsdatei openssl.cnf zur Verfügung:

[ keyUsage.gif ]

(Für genauere Angaben siehe RFC 2459 sowie die Beispiel-Konfigurationsdatei weiter unten.)

In der Konfigurationsdatei:

keyUsage = [critical,] und ein oder mehrere der obigen Bezeichner (mittlere Spalte) 

  3.3.2 Basic Constraints

Basic Constraints besteht aus einem Feld cA, welches ein BOOLEAN ist, sowie einem optionalen INTEGER-Feld, pathLenConstraint. Für CA-Zertifikate muß das cA-Feld auf TRUE gesetzt werden, für andere auf FALSE. Laut PKIX sollte Basic Constraints in nicht-CA-Zertifikaten nicht verwendet werden, also auch nicht wenn die Extension FALSE markiert ist. pathLenConstraint ist nur sinnvoll in CA-Zertifikaten und gibt an, wieviele CA-Ebenen unterhalb des CA-Zertifikats maximal zulässig sind. Ein Wert 0 bedeutet hierbei, diese CA gibt nur Anwendungs-/Benutzerzertifikate heraus. Basic Constraints sollte immer als Critical markiert werden.

Laut Steve Henson ist die Basic Constraints Extension unbedingt erforderlich in CA-Zertifikaten, die S/MIME Benutzer zertifizieren. Andernfalls wird die S/MIME-Mail beim Empfänger aufgrund eines ungültigen CA-Zertifikats zurückgewiesen.

Sowohl der Netscape- als auch der Microsoft-Browser interpretieren die Extension. (Henson hat allerdings die Erfahrung gemacht, daß "Microsoft Outlook Express 98" grundsätzlich Schwierigkeiten mit Critical markierten Extension hat: "Unfortunately Microsoft Outlook 98 chokes on critical extensions...".)

(Für genauere Angaben siehe RFC 2459 sowie die Beispiel-Konfigurationsdatei weiter unten.)

In der Konfigurationsdatei:

basicConstraints = [critical,] CA:<TRUE|FALSE>[, pathlen:n]

  3.3.3 Subject Key Identifier

Die Extension enthält den Hash-Wert eines Public Keys. Dadurch kann ein zu einem Public Key gehörendes Zertifikat effizient gesucht werden. So wird die Überprüfung von Zertifikatketten unterstützt und bei mehreren Anwendungszertifikaten die Auswahl des richtigen Zertifikats. Diese Extension sollte sowohl in CA-Zertifikaten als auch in Anwendungszertifikaten enthalten sein.

(Für genauere Angaben siehe RFC 2459 sowie die Beispiel-Konfigurationsdatei weiter unten.)

In der Konfigurationsdatei:

subjectKeyIdentifier = hash

  3.3.4 Authority Key Identifier

Diese Erweiterung besteht aus drei Feldern: keyIdentifier, authorityCertIssuer und authorityCertSerialNumber. Laut PKIX kann ein Schlüssel mittels dieser Extension auf zwei Arten identifiziert werden: entweder durch alleiniges Setzen des keyIdentifier-Feldes, oder durch Setzen der anderen beiden Felder. Diese Extension unterstützt die Überprüfung von Zertifikatketten.

Microsoft empfiehlt die zweite Variante, damit eine Zertifikatkette überprüft werden kann. PKIX empfiehlt die erste Variante.

(Für genauere Angaben siehe RFC 2459 sowie die Beispiel-Konfigurationsdatei weiter unten.)

In der Konfigurationsdatei:

authorityKeyIdentifier = <[keyid[:always]][, issuer[:always]]>

Ist keyid gesetzt, wird Subject Key Identifier (siehe oben) des Herausgeber-Zertifikats kopiert. Kann der Wert dieser Extension nicht kopiert werden (weil Subject Key Identifier nicht gesetzt war) und ist keyid auf always gesetzt, wird mit einer Fehlermeldung abgebrochen. Ist keyid nicht always gesetzt, wird alternativ das Issuer-Feld und die Seriennummer kopiert. Ist issuer auf always gesetzt, wird immer das Issuer-Feld und die Seriennummer kopiert.

  3.3.5 Subject Alternative Name

Diese Erweiterung kann verwendet werden, um weitere Bezeichner für ein Subject in das Zertifikat zu bringen. Es sind E-Mail-Adressen, DNS-Namen, IP-Adressen, URIs und registrierte IDs (RIDs), jeweils "beliebig" viele, möglich. Diese können auch beliebig kombiniert werden.

(Für genauere Angaben siehe RFC 2459 sowie die Beispiel-Konfigurationsdatei weiter unten.)

In der Konfigurationsdatei:

subjectAltName=<[email:<copy|name@mail.de>][, URL:http://my.url.here/][, RID:1.2.3.4][, IP:1.2.3.4]>

  3.3.6 Issuer Alternative Name

Diese Extensions ist wie Subject Alternative Name aufgebaut.

Hier wird allerdings nicht "email:copy" sondern "issuer:copy" unterstützt. Dabei werden die Angaben vom Subject Alternative Name des Herausgeber-Zertifikats kopiert.

(Für genauere Angaben siehe RFC 2459 sowie die Beispiel-Konfigurationsdatei weiter unten.)

In der Konfigurationsdatei:

subjectAltName=<[issuer:copy][, URL:http://my.url.here/][, RID:1.2.3.4][, IP:1.2.3.4]>

  3.3.7 Netscape Certificate Extensions

Zu den Netscape Certificate Extensions ist anzumerken, daß diese nicht Critical gesetzt werden sollten. Ein SSL-Server-Zertifikat, in dem beispielsweise das Netscape-SSL-Server-Bit (nsCertType=critical,server) Critical gesetzt ist, wird von einem Microsoft-Browser (der diese Extension nicht kennt) zurückgewiesen werden. Ein solches Server-Zertifikat würde also eine SSL-Verbindung von Microsoft-Clients zum Server ausschließen.

Folgende Netscape-Erweiterungen werden von OpenSSL-0.9.2b unterstützt (die Schlüsselwörter für die OpenSSL-Konfigurationsdatei stehen in Klammern):

Wichtig ist die Erweiterung Netscape Cert Type, um für die mit OpenSSL erzeugten Zertifikate den Verwendungszweck (zumindest für Netscape-Browser) zu beeinflussen. Der Internet-Explorer scheint die Netscape-Extensions zu ignorieren. Für die Erweiterung Netscape Cert Type stehen die folgenden acht Werte für das Schlüsselwort nsCertType in der Konfigurationsdatei zur Verfügung:

[ nsCertType.gif ]

Es sind auch Kombinationen der einzelnen Bezeichnungen möglich, so steht z.B. "nsCertType=objCA, emailCA, sslCA" für ein CA-Zertifikat, mit dem Zertifikate für Objekt-Signierung, S/MIME-Benutzer und SSL-Server/-Clients herausgegeben werden können. Die Bedeutung der anderen Attribute kann dem Anhang openssl.cnf entnommen werden.

  3.4 Erzeugen eines Root-CA-Zertifikats

Die oben aufgeführten Erweiterungen werden üblichererweise beim Zertifizieren eines Requests mit OpenSSL durch eine CA in das Zertifikat gebracht. In der Konfigurationsdatei (siehe openssl.cnf) gibt es einen Abschnitt [ v3_ca ], in dem festgelegt werden kann (und sollte !), welche Zertifikat-Erweiterungen bei Erzeugung eines (selbstsignierten) Root-Zertifikats gesetzt werden.

Im folgenden ein Beispiel zur Erzeugung eines Root-CA-Zertifikats:

  1. Editieren von openssl.cnf, Setzen der Zertifikat-Erweiterungen. Um z.B. ein Root-CA-Zertifikat zu erzeugen, mit dem SSL-CA-, S/MIME-CA- und Object-Signing-CA-Zertifikate herausgegeben werden können, sollte die Netscape Certificate Extension folgenderweise gesetzt sein:
    nsCertType = sslCA, emailCA, objCA 
                  
    
  2. Mögliche Werte für die anderen Extensions:
    basicConstraints       = critical, CA:TRUE
    keyUsage               = cRLSign, keyCertSign
    subjectKeyIdentifier   = hash
    authorityKeyIdentifier = keyid, issuer:always
    subjectAltName         = email:copy
    issuerAltName          = issuer:copy
                  
    
    Diese und die unter 1. aufgeführten Einträge müssen in dem beim Schlüsselwort x509_extensions des Request-Abschnitts genannten Bereich gemacht werden, also z.B. im Bereich [ v3_ca ].
  3. Initialisieren des Zufallszahlen-Status, z.B.:
    cp ~/.pgp/randseed.bin $RANDFILE
    
  4. Erzeugen eines 2048-Bit-Schlüssels: Spätestens vor Aufruf dieses Befehls muß $RANDFILE gesetzt sein, sonst findet das folgende Kommando die Datei mit dem Zufallszahlen-Status nicht, und ein einkompilierter Default wird wirksam (siehe Zufallszahlen).
    openssl genrsa -des3 -out $(SSLDIR)/private/CAkey.pem -rand Zufallsdaten 2048
    
    Achtung:
    Ohne die Option -des3 (oder -des, -idea) wird der Schlüssel unverschlüsselt abgespeichert!
  5. Erzeugen des selbstsignierten Root-CA-Zertifikats:
    openssl req -new -x509 -days 730 -key $(SSLDIR)/private/CAkey.pem -out ./CAcert.pem
    
    Achtung:
    Über die Option -days wird die Gültigkeitsdauer des Root-Zertifikats in Tagen festgelegt. Beginn des Zeitraums ist der Zeitpunkt der Erzeugung des Zertifikats.
  6. Anzeigen des erzeugten Zertifikats:
    openssl x509 -in ./CAcert.pem -text | more
    
  7. Das Zertifikat an den gewünschten (bzw. an den in der Konfigurationsdatei unter "certificate=" benannten) Ort kopieren, z.B.
    cp ./CAcert.pem $(SSLDIR)/CAcert.pem
    

Das Zertifikat muß jetzt noch in das Verzeichnis $(SSLDIR)/certs als 00.pem kopiert werden. Der Name ergibt sich aus der hexadezimalen Seriennummer des Zertifikats (hier 00) und dem Anhang .pem. Anschließend sollte das Zertifikat noch über seinen Hash-Wert verlinkt werden (siehe Anmerkung).

Alternativ zu dem Link-Befehl kann auch das Shell-Skript c_rehash in $(SSLDIR)/bin aufgerufen werden. Das Skript erzeugt für alle im Verzeichnis certs gefundenen Zertifikate die nötigen Links. Der Hash-Wert besteht aus 64 Bit und wird aus den Angaben des Issuer-Feldes (also Distinguished Name und evtl. Email-Adresse des Herausgebers) des Zertifikats gebildet.

  Anmerkung:
Bis auf das nach obigem Verfahren erzeugte Root-Zertifikat finden sich erzeugte Zertifikate (zusätzlich zu dem bei -out angegebenen Namen) unter $(SSLDIR)/newcerts/xx.pem. Das xx steht für die Seriennummer des neuen Zertifikats. Alle neuen Zertifikate sollten von $(SSLDIR)/newcerts/ nach $(SSLDIR)/certs/ kopiert und anschließend über ihren Hash-Wert verlinkt werden. Das ist deshalb von Bedeutung, weil die Suche nach Zertifikaten und der damit verbundene Vergleich ausschließlich über die Hash-Werte der Zertifikate erfolgt.

  3.5 Erzeugen von Certificate Requests

Zur Erzeugung eines beliebigen Requests (CA, Server, Client) muß zunächst ein Schlüsselpaar generiert werden. Mit folgendem Befehl wird ein 1024-(512)-Bit Schlüssel erzeugt:

openssl genrsa -des3 -out MyKey.pem -rand file1:file2:... 1024 (512)

Vorher sollte allerdings die Umgebungsvariable $RANDFILE gesetzt und der Zufallszahlen-Status initialisiert worden sein (siehe Zufallszahlen). Die nach der Option -rand angegebenen Dateien dienen als zusätzliche Zufallsdaten für die Schlüsselerzeugung. Abhängig vom später verwendeten Browser ist die Schlüssellänge zu beachten. Für den MS-Internet-Explorer in der internationalen (Export-)Version ist die Schlüssellänge für ein Benutzerzertifikat grundsätzlich auf 512 Bit begrenzt. Für die Netscape Navigator/Communicator (NSC)Export-Version gilt im Prinzip die gleiche Beschränkung. Die Schlüssellänge kann aber bis auf 2048 Bit erhöht werden, wenn das Zertifikat extern (z.B. durch openssl) erzeugt und anschließend als .p12-Datei (siehe Hensons PKCS#12-Seite) in den NSC importiert wird (siehe PFX bzw. PKCS12).

Die Schlüsselerzeugung hätte bei dem folgenden Request-Kommando gleichzeitig mit der Request-Erzeugung durch die Option -newkey veranlaßt werden können; diese Variante bietet aber keine Möglichkeit, zusätzliche Zufallsdaten anzugeben.

Die Erzeugung des Requests erfolgt durch folgenden Befehl:

openssl req -new -key MyKey.pem -out MyReq.pem

Nach Eingabe des Befehls müssen folgende Angaben gemacht werden (beispielhafte Eingaben sind in doppelten Anführungsstrichen):

Using configuration from /usr/local/ssl/lib/openssl.cnf
Enter PEM pass phrase:  "passphrase"
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]: "DE"
State or Province Name (full name) [Some-State]: "Schleswig-Holstein"
Locality Name (eg, city) []: "Kiel"
Organization Name (eg, company) [Internet Widgits Pty Ltd]: "Universitaet Kiel"
Organizational Unit Name (eg, section) []: "Studis"
Common Name (eg, YOUR name) []: "Fred Neumann"
Email Address []: "neumann@inf.uni-kiel.de"

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: "passphrase vergessen"
An optional company name []: "Informatik Uni Kiel"
            

(Für den genauen Inhalt muß die zertifizierende CA bzw. deren Policy konsultiert werden.)

Die beiden letzten Angaben tauchen als Klartext im Attribut-Bereich des Requests auf. Soll später ein Zertifikat zurückgerufen werden, kann sich der Inhaber gegenüber der CA, auch bei Verlust des Private Keys, durch Angabe dieser Felder als Inhaber "ausweisen". Die Verwaltung dieser Angaben kann von der CA durchgeführt werden.

Je nach Verwendungszweck des späteren Zertifikats muß bei den Angaben folgendes beachtet werden:

Der so erzeugte Request (also nur die Datei MyReq.pem, nicht der Schlüssel) kann dann auf Diskette kopiert und einer CA zum Signieren (also: Zertifizieren, siehe Abschnitt Signieren) vorgelegt werden. Nach der Zertifizierung kann dann das Zertifikat zusammen mit dem privaten Schlüssel als .p12-Datei in den jeweiligen Browser importiert werden (siehe PFX und PKCS12).

  3.6 Signieren von Certificate Requests

Das Signieren eines einzelnen Requests erfolgt durch folgenden Befehl:

openssl ca -name ca_name -keyfile CAkey.pem -in MyReq.pem -out MyCert.pem

Der Wert von ca_name steht hier für den gewünschten Abschnitt der Konfigurationsdatei, also z.B. Client_CA.

Nach Eingabe des Befehls kommt eine Meldung folgender Art:

          
Using configuration from /usr/local/ssl/lib/openssl.cnf
Enter PEM pass phrase: "passphrase"
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName           :PRINTABLE:'DE'
stateOrProvinceName   :PRINTABLE:'Schleswig-Holstein'
localityName          :PRINTABLE:'Kiel'
organizationName      :PRINTABLE:'Universitaet Kiel'
organizationalUnitName:PRINTABLE:'Studis'
commonName            :PRINTABLE:'Fred Neumann'
emailAddress          :IA5STRING:'neumann@inf.uni-kiel.de'
Certificate is to be certified until Mar 18 09:51:41 1999 GMT (365 days)
Sign the certificate? [y/n]: "y"

1 out of 1 certificate requests certified, commit? [y/n] "y"
Write out database with 1 new entries
Data Base Updated
          

Findet sich die Konfigurationsdatei (KD) openssl.cnf nicht in dem bei der Kompilation angegebenen SSL-Verzeichnis, kann die Angabe im CA-Kommando bei -config /pfad/Konfigname erfolgen. Oder es wird die Umgebungsvariable OPENSSL_CONF (aber nur nachdem die Anpassungen vorgenommen wurden) auf /pfad/Konfigname gesetzt. Wenn die Datei mit dem CA-Key in der KD angegeben ist, kann die Angabe bei -keyfile ebenfalls wegfallen. Mit der Option -name kann ein spezieller Eintrag in der KD, z.B. der Abschnitt Server_CA, abgearbeitet werden (siehe Anhang openssl.cnf). Durch das Signieren werden möglicherweise einige Extensions in das Zertifikat gebracht. Vor dem Signieren eines Request muß unbedingt sichergestellt sein, daß die richtigen Extensions gesetzt sind bzw. der richtige Abschnitt in der KD gewählt wird (siehe Zertifizieren und Anhang openssl.cnf).

Sind in der KD keine anderen Angaben gemacht worden, befindet sich das neu erstellte Zertifikat in der bei -out angegebenen Datei. Außerdem wird im Verzeichnis $(SSLDIR)/newcerts eine Kopie abgelegt. Der Name der Kopie setzt sich aus der Seriennummer des Zertifikats und der Endung .pem zusammen, also z.B. 0a.pem. Die Seriennummer des gerade herausgegebenen Zertifikats findet sich im Zertifikat selber (openssl x509 -in myCert.pem -serial) oder in der Datei $(SSLDIR)/serial.old. Die Kopie muß dann nach $(SSLDIR)/certs kopiert (wird stattdessen das Original genommen, muß diese umbenannt werden) und über ihren Hash-Wert verlinkt werden:  

ln -s 0a.pem `openssl x509 -in 0a.pem -hash -noout`.0

Für ein S/MIME-Zertifikat könnte Key Usage (keyUsage) auf Digital Signature und Data Encipherment gesetzt werden, sowie Netscape Cert Type (nsCertType) auf email.

  3.7 Certificate Revocation Lists (CRL)

In Abhängigkeit vom Status der Zertifikate, die in der Indexdatei $(SSLDIR)/index.txt durch Gültigkeit, Seriennummer und Distinguished Name (DN) repräsentiert werden, kann mit dem Kommando

openssl ca -gencrl -outform der -out $(SSLDIR)/crl/crl.der

eine Certificate Revocation List (CRL) erzeugt werden. Um ein Zertifikat zurückrufen zu können, muß die Indexdatei mit einem Texteditor geändert werden (siehe Widerruf eines Zertifikats).

  Auch CRLs können Extensions enthalten. Sie werden beim Signieren einer CRL durch eine CA in die CRL gebracht. OpenSSL unterstützt bisher die Extensions CRL Authority Key Identifier und CRL Issuer Alternative Name. Die Verwendung dieser Extensions zeichnet (u.a.) eine X.509v2-CRL aus. Werden diese Extensions nicht verwendet (durch Löschen oder Auskommentieren des Schlüsselworts crl_extensions in openssl.cnf), erzeugt obiges Kommando eine X.509v1-CRL. Das ist deshalb von Bedeutung, weil Netscape Browser mit v2 CRLs (noch) nicht umgehen können. Beim Laden einer CRL gibt der Browser die folgende Meldung aus: "The certificate revocation list you are trying to load has an invalid format".

  3.7.1 Aufbau der Indexdatei index.txt

Beispieleintrag eines Zertifikats in index.txt:

V    981210145000Z   "leer"   01   unknown   /C=DE/O=Uni/OU=Inf/CN=TestCA/Email=testca@uni.de
            

Die Indexdatei besteht aus sechs Spalten, jeweils getrennt durch einen Tabulator (nicht durch Leerzeichen). Die Einträge in den einzelnen Spalten haben die folgende Bedeutung:

  1. Status des Zertifikats. Einer der Buchstaben R (revoked), E (expired) oder V (valid).
  2. Ablaufzeitpunkt des Zertifikats. Format ist YYMMDDHHMMSSZ
  3. Ist in obiger Beispielzeile leer. Die Spalte kann aber ebenfalls einen Ablaufzeitpunkt YYMMDDHHMMSSZ enthalten. Ist hier ein Datum eingetragen, entspricht dies dem Widerrufzeitpunkt des Zertifikats. Dann muß in der ersten Spalte (statt V) ein R stehen. Für ein gültiges Zertifikat ist diese Spalte leer.
  4. Hexadezimale Seriennummer des Zertifikats.
  5. Wo das Zertifikat zu finden ist. Wird derzeit immer mit "unknown" besetzt.
  6. Der Name des Zertifikatinhabers. Üblicherweise der Distinguished Name und die E-Mail-Adresse.

  3.7.2 Widerruf eines Zertifikats

Soll ein Zertifikat widerrufen werden, muß mit einem Editor die Indexdatei (von Hand oder per Skript) geändert werden. In der ersten Spalte muß das V durch ein R ersetzt und in der dritten (bisher leeren) Spalte muß der Widerrufzeitpunkt eingetragen werden.

Dann kann mit dem obigen Kommando ca -gencrl eine CRL mit dem widerrufenen Zertifikat erzeugt werden.

  3.7.3 CRL Authority Key Identifier

Diese Extension besteht aus drei Feldern: keyIdentifier, authorityCertIssuer und authorityCertSerialNumber. Laut PKIX kann der Schlüssel mittels dieser Extension auf zwei Arten identifiziert werden: entweder durch alleiniges Setzen des keyIdentifier-Feldes oder durch Setzen der beiden anderen Felder. Die Extension dient dazu, Zertifikate der Herausgeber-CA zu identifizieren.

PKIX empfiehlt die erste Variante.

(Für genauere Angaben siehe RFC 2459 sowie die Beispiel-Konfigurationsdatei weiter unten.)

In der Konfigurationsdatei:

authorityKeyIdentifier = <[keyid[:always]][,issuer[:always]]>

  3.7.4 CRL Issuer Alternative Name

Diese Extension ist wie Subject Alternative Name aufgebaut und dient dazu, zusätzliche Information zum Herausgeber in die CRL zu bringen.

(Für genauere Angaben siehe RFC 2459 sowie die Beispiel-Konfigurationsdatei weiter unten.)

In der Konfigurationsdatei:

subjectAltName=<[issuer:copy][, URL:http://my.url.here/][, RID:1.2.3.4][, IP:1.2.3.4]>  

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