openssl.cnf
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
crl_extensions
policy
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
attributes
x509_extensions
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
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.
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.
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:
(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)
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]
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
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.
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]>
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]>
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):
nsCertType
)nsBaseUrl
)nsRevocationUrl
)nsCaRevocationUrl
)nsRenewalUrl
)nsCaPolicyUrl
)nsSslServerName
)nsComment
)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:
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.
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:
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
Diese und die unter 1. aufgeführten Einträge müssen in dem beim SchlüsselwortbasicConstraints = critical, CA:TRUE keyUsage = cRLSign, keyCertSign subjectKeyIdentifier = hash authorityKeyIdentifier = keyid, issuer:always subjectAltName = email:copy issuerAltName = issuer:copy
x509_extensions
des
Request-Abschnitts genannten Bereich gemacht werden, also z.B. im
Bereich [ v3_ca ]
.
cp ~/.pgp/randseed.bin $RANDFILE
$RANDFILE
gesetzt sein, sonst
findet das folgende Kommando die Datei mit dem Zufallszahlen-Status
nicht, und ein einkompilierter Default wird wirksam (siehe Zufallszahlen).
Achtung:openssl genrsa -des3 -out $(SSLDIR)/private/CAkey.pem -rand
Zufallsdaten2048
-des3
(oder -des
,
-idea
) wird der Schlüssel unverschlüsselt
abgespeichert!
Achtung:openssl req -new -x509 -days 730 -key $(SSLDIR)/private/CAkey.pem -out ./CAcert.pem
-days
wird die
Gültigkeitsdauer des Root-Zertifikats in Tagen festgelegt.
Beginn des Zeitraums ist der Zeitpunkt der Erzeugung des
Zertifikats.
openssl x509 -in ./CAcert.pem -text | more
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).
<mv|cp> $(SSLDIR)/CAcert.pem
$(SSLDIR)/certs/00.pem
cd $(SSLDIR)/certs
ln -s 00.pem `openssl x509 -hash -noout -in
00.pem`.0
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.
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:
www.site.com
.
Ebenfalls sinnvoll ist es, den Server-Namen zusätzlich über
die Extension nsSslServerName
zu setzen (Aufgabe der
CA).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).
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.
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".
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:
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.
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]]>
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]>