OpenSSL

Dieses Howto beschäftigt sich mit der Einrichtung einer CA, mit dem Erstellen von Certificate Requests, dem Zeichnen dieser unter OpenSSL. Ferner behandelt es die Themen erneuern von abgelaufenen Zertifikaten, sowie die Certificate Revokation List.

Ich möchte in diesem Howto nicht auf die Installation von OpenSSL selbst eingehen. Dies aus dem einfach Grund, als dass OpenSSL mittlerweile wohl mit jeder Distribution ausgeliefert wird und nahezu immer bereits in der Standardinstallation dieser enthalten ist. Wer tatsächlich sein eigenes Linux gestrickt hat, der dürfte mit der Installation von OpenSSL per Hand nicht an seine Grenzen stossen.

Bevor wir nun also damit beginnen, uns mit OpenSSL zu beschäftigen, wollen wir uns überlegen, wo und wie wir unsere Daten halten wollen. Wir werden einen Root-Ordner für unsere CA benötigen. Ausserdem benötigen wir einen Root-Ordner für unsere Zertifikate, da wir diese sauber struckturiert aufbewahren wollen.

Für dieses Howto legen wir uns die folgende Ordnerstrucktur an.

/data
 +-openssl
   +-myCa
   +-myCerts
     +-server
       +-www

Das folgende Kommando sollte dies für uns tun.

-bash-3.1# mkdir -p /data/openssl/{myCA,myCerts/server/www}

OpenSSL verwenden, bedeutet immer wieder die selben Argumente und Angaben von Hand einzugeben. Um dies zu umgehen, erstellen wir uns eine Konfigurationsdatei, welche die Standardwerte für alle möglichen Fragen, die einem z.B. bei der Erstellung eines neuen Zertifikates gestellt werden, definiert.

Unter openssl.cfg finden Sie eine Vorlage für eine solche Konfigurationsdatei. Bitte achten Sie darauf, die in der folgenden Tabelle aufgeführten Platzhalter mit auf Ihre Umgebung zutreffenden Angaben zu ersetzen, wobei Vorkommen Ihnen angibt, wie oft der jeweilige Platzhalter in der Vorlage verwendet wird. Laden Sie sich diese Datei herunter und speicher Sie sie unter ihrem Originalname im Verzeichnis /data/openssl.

Platzhalter	Vorkommen	Beschreibung
%YOUR_COUNTRY_CODE%	1	Der zweistellige Ländercode für Ihren Heimatstaat. Z.B. DE
%YOUR_STATE%	1	Der Bundesstaat, das Bundesland, usw., welches Sie in Ihren Zertifikaten angeben möchten. Z.B. Baden-Württemberg
%YOUR_CITY%	1	Der Name der Stadt, welcher in Ihren Zertifikaten angegeben sein soll. Z.B. Berlin
%YOUR_ORGANIZATION%	2	Der Name der Organisation, wie er in Ihren Zertifikation angegeben sein soll. Z.B. MYDOM
%YOUR_ORGANIZATIONAL_UNIT%	1	Der Name der Organisationseinheit, wie er in Ihren Zertifikation vermerkt sein soll

Bevor Sie damit beginnen können, selbst Zertifikate zu erstellen, benötigen Sie eine eigene Certification Authority. Hierzu stehen Ihnen wie immer mehrere Wege zur Verfügung. Ich möchte Ihnen an dieser Stelle zwei davon näher vorstellen. Diese sind zum einen die Verwendung eines Perl Script und zum Anderen das Erstellen der CA von Hand.

Das Perl Script ca.pl eignet sich hervoragend zur Erstellung einer neuen CA. Alles was Sie tun müssen, ist es unter dem Originalnamen unter /data/openssl zu speichern und auszuführen.

-bash-3.1# ./ca.pl -newca

An Stelle des Perl Scripts ca.pl könne wir uns unsere Certification Authority auch von Hand erstellen. Das ist zwar mit Hinblick auf das Script nicht notwendig, jedoch denke ich, dass es wohl schon mal interessant ist zu sehen, was dazu eigentlich notwendig ist und wie es von statten geht.

Beginnen wir damit, die notwendige Ordnerstrucktur zu erstellen

-bash-3.1# mkdir -p ./myCA/{certs,crl,newcerts,private}
-bash-3.1# chmod -Rfv 0775 ./myCA

Nun erstellen wir Dateien, welche später bei der Verwendung der CA von der OpenSSL Library benötigt werden.

-bash-3.1# echo "01" > ./myCA/serial
-bash-3.1# touch ./myCA/index.txt

Zu guter letzt erstellen wir die CA.

-bash-3.1# openssl req -new -x509 -keyout ./myCA/private/cakey.pem -out ./myCA/cacert.pem -days 3650 -config ./openssl.cfg

Bei der Ausführung dieses Kommandos werden Sie einige Fragen beantworten müssen. Die meisten davon sollten mit den Werten aus der durch Sie angepassten openssl.cfg vorbelegt sein, sodass Sie jeweils lediglich die Entertaste betätigen müssen. Zwei Dinge sollten Sie jedoch noch anpassen. Diese sind zum einen Enter PEM pass phrase:, bzw. Verifying - Enter PEM pass phrase:, wo Sie ein starkes Passwort angeben sollten.

Zum Anderen sollten Sie bei der Frage Common Name (eg, YOUR name) []: eine Beschreibung Ihrere CA angeben. Diese könnte in etwa My Main Certification Authority lauten oder was auch immer Ihnen passend erscheinen mag.

Gratulation, Sie sind nun stolzer Eigentümer einer eigenen Certification Authority.

Nun, da Sie eine selbst erstellte CA Ihr Eigen nenne, ist es an der Zeit, ein erstes Server-Zertifikat zu erstellen. Wir wollen uns dies anhand eines Beispiels anschauen, in welchem wir ein Zertifikat erstellen, welches wir in einem Apache zur Aktivierung von HTTPS verwenden werden. Hierzu müssen Sie zunächst einen Certificate Reqeust erzeugen, welchen Sie anschliessend durch Ihre CA zeichnen und somit authorisieren lassen.

Bevor wir damit fort fahren, den Certificate Request zu erstellen, wechseln Sie bitte in das hierfür vorgesehene Verzeichnis.

-bash-3.1# cd /data/openssl/myCerts/server/www

Nun erstellen Sie mit dem folgenden Kommando einen Certificate Request.

-bash-3.1# openssl req -new -nodes -out certreq.pem -config /data/openssl/openssl.cfg

Bestätigen Sie alle anderen Fragen mit einem einfachen Betätigen der Entertaste.

Ein Auflisten des Ordnerinhalts sollte nun wie folgt aussehen.

-bash-3.1# ls -al
insgesamt 16
drwxr-xr-x 2 root root 4096  4. Nov 15:09 .
drwxr-xr-x 3 root root 4096  4. Nov 15:08 ..
-rw-r--r-- 1 root root  708  4. Nov 15:09 certreq.pem
-rw-r--r-- 1 root root  887  4. Nov 15:09 privkey.pem

Der soeben erstellte Certificate Request ist in der Datei certreq.pem gespeichert. privkey.pem speichert den privaten Schlüssel des Requests und ebenfalls den privaten Schlüssels des Zertifikats, nachdem es durch die CA gezeichnet wurde.

Nachdem der Certificate Request erfolgreich erstellt wurde, muss er durch die CA gezeichnet werden, um so ein gültiges Zertifikat zu erhalten. Hierzu ist lediglich der Aufruf des folgenden Kommandos von nöten.

-bash-3.1# openssl ca -out ./certificate.pem -config /data/openssl/openssl.cfg -infiles ./certreq.pem

Bei der Aufforderung zur Eingabe des Passwortes für die CA (Enter pass phrase for /data/openssl/myCA/private/cakey.pem:) geben Sie bitte das Passwort ein, welches Sie bei der Erstellung der CA verwendet haben. Die beiden anderen male, wenn Sie aufgefordert werden, eine Eingabe vorzunehmen, geben Sie jeweils y ein und bestätigen mit der Entertaste.

Lief alles rund, sollte der Ordnerinhalt nun wie folgt aussehen.

-bash-3.1# ls -al
insgesamt 20
drwxr-xr-x 2 root root 4096  4. Nov 15:18 .
drwxr-xr-x 3 root root 4096  4. Nov 15:08 ..
-rw-r--r-- 1 root root 3795  4. Nov 15:18 certificate.pem
-rw-r--r-- 1 root root  708  4. Nov 15:09 certreq.pem
-rw-r--r-- 1 root root  887  4. Nov 15:09 privkey.pem

Man bemerke die neue Datei certificate.pem. Wie der Name schon vermuten lässt, handelt es sich hierbei um das durch die CA gezeichnete Server-Zertifikat.

Soll ein Zertifikat zur Authentifizierung eines Windows XP Wireless LAN Clients dienen, z.B. von einem Radius Server verwendet werden, so ist es zwingend notwendig, das Zertifikat um entsprechende Extensions zu erweitern, damit dieses von Windows XP akzeptiert werden wird. Windows XP überprüft sowohl Server-, wie auch Client-Zertifikate auf die Existenz bestimmter Attribute, welche man dem selbst erstellten Zertifikat hinzufügen kann. Hierzu muss zunächst eine weitere Datei mit dem Namen xpextensions angelegt werden. Am besten speichern Sie dies ebenfalls im Verzeichnis /data/openssl, wo bereits die openssl.cfg abgelegt ist. Der Inhalt der Datei hat wie folgt aus zu sehen:

[ xpclient_ext]
extendedKeyUsage = 1.3.6.1.5.5.7.3.2

[ xpserver_ext ]
extendedKeyUsage = 1.3.6.1.5.5.7.3.1

Zu guter letzt muss beim Zeichnen des Zertifikats das entsprechende Kommando erweitert werden.

-bash-3.1# openssl ca -out ./certificate.pem -config /data/openssl/openssl.cfg -extensions xpserver_ext -extfile /data/openssl/xpextensions -infiles ./certreq.pem

Wenn Sie sich den Inhalt des Zertifikats anschauen

-bash-3.1# cat ./certificate.pem

fällt auf, dass in diesem sowohl die Klartext-, wie auch die kodierte Version des Zertifikats enthalten ist. Da dies nicht immer gewünscht ist, bzw. benötigt wird, wollen wir die beiden Teile des Zertifikats nun noch von einander trennen.

-bash-3.1# openssl x509 -in certificate.pem -out certificate.encoded.pem

Woraufhin eine weitere Datei mit dem Namen certificate.encoded.pem erstellt wird, welche lediglich das kodierte Zertifikat beinhaltet.

Bis hier hin wurde gezeigt, wie ein Server-Zertifikat erstellt werden kann. Normalerweise verwendet man bei der Erstellung einse Server-Zertifikats den DNS Name für das CN Attribute, welcher später auch von den Clients zum Herstellen einer Verbindung benutzt wird.

Manchmal ist es wichtig, dass ein und das selbe Zertifikate unter der Verwendung mehrerer, unterschiedlicher DNS Hostnames verwendet werden kann. Mögliche Gründe sind beispielsweise:

• Ein SMTP-Server ist für unterschiedliche Domänen zuständig und soll entsprechend unter diesen angesprochen werden können.
• Ein Server ist Teil eines Clusters, auf welches über einen Load Balancer unter einem globalen DNS Namen zugegriffen wird.

Es gibt der gleichen noch viele Gründe, welche gar nicht alle hier wieder gegeben werden können. Viel wichtiger ist es jedoch auch, wie es sich bewerkstelligen lässt, dies zu ermöglichen. Hierzu muss man wissen, dass es bei Zertifikaten die Möglichkeit gibt, über das subjectAltName Attribute multible Betrefs für ein Zertifikat zu vergeben, was in diesem Falle mehreren DNS Namen entspricht.

Unter OpenSSL kann die Vergabe von mehreren DNS Namen über unterschiedliche Wege erfolgen. Der einfachste ist es, die openssl.cfg zu erweitern. Suchen Sie hierzu in Ihrer openssl.cfg nach dem folgenden Abschnitt:

commonName                      = Common Name (eg, YOUR name)
commonName_max                  = 64

Ersetzen Sie diesen durch das folgende:

# Add as many commonName definitions as needed
# using an incrementing integer number as the leading sign.
0.commonName                    = Common Name (eg, YOUR name) #1
0.commonName_max                = 64
 
1.commonName                    = Common Name (eg, YOUR name) #2
1.commonName_max                = 64

Der Haupt-DNS-Name, normalerweise der FQDN des Servers selbst, sollte als erster commonName Wert angegeben werden, was hier 0.commonName = … entspricht. Dies aus dem einfachen Grund, als dass lediglich dieser im Betreffeld des Zertifikats eingetragen wird. Alle anderen commonName Parameter - inklusive dem ersten - werden im subjectAltName Feld des erstellten Zertifikats eingetragen.

Ein weiterer Weg zum selben Ergebnis zu gelangen ist es, mit den Parametern des openssl Kommandos zu spielen. Für diesen Zweck ist der -subj Parameter von besonderem Interesse. Besonders nützlich ist dies, wenn das Schlüsselpaar bereits erstellt wurde.

Das folgende Beispiel soll dies veranschaulichen:

-bash-3.1# openssl req -new -key myserver.key -subj "/C=BE/O=inst_name/CN=first_fqdn/CN=second_fqdn/CN=third_fqdn" -text

Sie können dies sogar bei der Erstellung eines neuen Schlüsselpaars verwenden:

-bash-3.1# openssl req -new -newkey rsa:2048 -keyout myserver.key -subj "/C=BE/O=inst_name/CN=first_fqdn/CN=second_fqdn/CN=third_fqdn" -text

Es kann sehr hilfreich sein, wenn man weiss, wie man sich die Daten, welche in einem Zertifikat verschlüsselt abgespeichert sind, im Klartext anzeigen lassen kann.

Mit Hilfe der folgenden Anweisung kann dies unter der Verwendung den openssl x509 Kommandos bewerkstelligt werden:

-bash-3.1# openssl x509 -text -in server.crt

Manchmal ist es notwendig, dass ein Zertifikat von einem Format in ein anderes umgewandelt werden muss, damit es von einer bestimmten Anwendung verwendet werden kann. Dies ist beispielsweise der Fall, wenn wie weiter oben beschrieben, ein Zertifikat erstellt wurde, welches nun von Fedora Directory Server verwendet werden soll.

Mit dem folgenden Kommando können Sie sich ein im x509-Format vorliegendes Zertifikat in ein PKCS12-formatiertes Zertifikat umwandeln lassen.

-bash-3.1# openssl pkcs12 -export -in /path/to/ssl-cert.pem -inkey /path/to/ssl-key.pem -out ssl-cert.p12 -name "Server-Cert"

From OpenSSL manual page: „The DER format is the DER encoding of the certificate and PEM is the base64 encoding of the DER encoding with header and footer lines added“. File in DER format is binary and PEM is plain text(ascii). Use command „openssl x509 …“ with options -inform/-outform to convert between formats.

-bash-3.1# openssl x509 -in  file.der -inform  DER -out file.pem -outform PEM

We must distinguish between file extension and file format/content. We suppose that file with der extension contain a X.509 certificate in DER format. File with cer or crt extension can contain either one certificate in DER format or one or more certificates in PEM format. A file with pem extension can contain text, private keys, certificates and other data. Use text editor to see its content.

You can extract private key, user certificates and/or CA certificates from a PKCS #12 file.

• private key:

  -bash-3.1# openssl pkcs12 -in file.p12 -nocerts ...

• user certificates:

  -bash-3.1# openssl pkcs12 -in file.p12 -nokeys -clcerts ...

• user private key and certificates:

  -bash-3.1# openssl pkcs12 -in file.p12 -clcerts ...

• CA certificates:

  -bash-3.1# openssl pkcs12 -in file.p12 -nokeys -cacerts ...

• all certificates:

  -bash-3.1# openssl pkcs12 -in file.p12 -nokeys ...

• all:

  -bash-3.1# openssl pkcs12 -in file.p12 ...

• all with input from stdin:

  -bash-3.1# cat file.p12 | openssl pkcs12 ...

Output from command by default is to stdout and format is PEM only(!). You can use other openssl commands to convert private key or a certificate to DER format. Note on „Microsoft Windows“ OS-es input from stdin might fail, due LF to CR/LF conversion. This is well know bug - these OS-es open pipes in text mode instead of binary.

You do not needed. File with cer/crt extension contain one or more certificates. PKCS #12 file should contain private key, certificate that match private key and other certificates. PKCS #12 file without private key and certificate that match private key is useless. Let file.crt contain certificate that match private key in file.key and both files are in PEM format. To create p12 file run command:

-bash-3.1# openssl pkcs12 -export -in file.crt -inkey file.key ...

or get all from stdin:

-bash-3.1# (
 cat file.key
 cat file.crt
 cat file2.crt
 ....
) | openssl pkcs12 -export ...

Es kann auf zwei unterschiedliche Arten dazu kommen, dass ein Zertifikat nicht mehr gültig ist. Diese sind

• * Das Server|User Zertifik ist abgelaufen
• * Das CA-Zertifikat ist abgelaufen

In diesem Fall kommen Sie nicht umher, eine neu CA zu erstellen. Anschliessend müssen sie alle durch diese CA gezeichneten Zertifikate entweder neu erstellen oder mittels ihrer Certificate Requests neu zeichnen.

Ist ein Zertifikat, beispielsweise das Server-Zertifikat Ihres Webservers abgelaufen, haben Sie wiederum zwei Möglichkeiten.

• Sie können neue Certificate Request erstellen und wie weiter oben beschrieben zeichnen
• Sie können mittels der aufgehobenen Certificate Requests diese neu zeichnen und somit erneuern

In beidem Fällen kommen Sie nicht umher, das alte Zertifikate in die Certificate Revokation List Ihrer CA aufzunehmen und das bis anhin verwendete Zertifikat durch das neu gezeichnete zu ersetzen. Dies beruht auf der simplen Tatsache, dass Sie per default nicht zwei Zertifikate mit dem selben Subject herausgeben können.

Es gibt unterschiedliche Beweggründe, ein Zertifikat für ungültig zu erklären. Einer ist beispielsweise gegeben, wenn ein Zertifikat abgelaufen ist.

Um ein Zertifikat offiziell ungültig zu erklären, muss es in die CRL, der sogenannten Certificate Revokation List der CA aufgenommen werden, welche das Zertifikat einst zeichnete. OpenSSL erstellt beim Zeichnen eines jeden Zertifikats eine Kopie dessen im Unterordner newcerts, welcher im Rootverzeichnis der CA zu finden ist. In diesem Howto ist dies der Ordner /data/openssl/myCA/newcerts. Bei der Erstellung dieser Kopie wird diese mit einem Dateinamen versehen, welcher hauptsächlich aus einem fortlaufenden, positiven nummerischen Index, beginnend mit 01, besteht. Des weiteren wird bei der Zeichnung eines Zertifikates eine Zuordnung des Index zum jeweiligen Zertifikat in die Datei index.txt unterhalb des CA Root-Ordners eingetragen.

Betrachtet man den Inhalt dieser Datei

-bash-3.1# cat /data/openssl/myCA/index.txt
V       081106141845Z           01      unknown /C=DE/ST=MyState/O=MyDom/OU=MyOU/CN=www.my.domain.tld/emailAddress=webmaster@my.domain.tld

so ist in diesem Beispiel gut zu sehen, dass der Index 01 dem Zertifikat mit dem Common Name www.my.domain.tld zugeordnet ist. Da OpenSSL lediglich die einmalige Verwendung eines Common Name zulässt, kann über diesen der benötigte Index schnell in der index.txt ermittelt werden.

Hat man den Index ausfindig gemacht, genügt der Aufruf des folgenden Kommandos, um das Zertifikat in die CRL aufnehmen zu lassen.

openssl ca -revoke newcerts/01.pem -config /data/openssl/openssl.cnf