X.509
Inhaltsverzeichnis
Betrieb einer CA
Wer nur wenige Zertifikate verwalten muss, ist mit dieser X.509 Lösung gut bedient. Wer jedoch viele Zertifikate verwalten muss, sollte sich mal den Artikel ejbca ansehen.
X.509 mit OpenSSL
Zu einer X.509 Infrastruktur gehört immer ersteinmal eine Root-CA. Man kann da kommerzielle Anbieter, wie z.B. Verisign bemühen, aber das kostet richtig Geld - oder man macht alles selbst. Ansonsten gibt es noch CAcert, dort kann man sein Zertifikat ebenfalls signieren lassen. Bei dem Stammtisch können CAcert "Assurance Punkte" vergeben werden. Bitte aber vorher in der Mailingliste bescheid sagen, so dass die CAcert Assurer wissen, dass etwas zu tun ist...
Smartcards
Unter X.509 mit Smartcards wird beschrieben, wie man X.509 mit Smartcards implementiert und ssh mit Smartcards einsetzt.
Quellen für OpenSSL
Den Sourcecode gibt es unter http://www.openssl.org, bei den meisten Linuxdistributionen liegt es als Paket bei. Bei Debian wird es mit apt-get install openssl installiert. Für Windows gibt es unter http://www.slproweb.com/products/Win32OpenSSL.html fertige Binaries.
Root CA generieren
Dazu wird das Skript CA.pl verwendet, es ist Teil des OpenSSL Sourcecodes. Nach dem Auspacken des Archivs ist sie unter ./openssl-.../apps/CA.pl zu finden. Bei Debian ist sie unter /usr/lib/ssl/misc/CA.pl zu finden, wenn man mit apt-get install openssl die Installation von OpenSSL vorgenommen hat.
Die CA sollte sich auf einem PC ohne Netzwerkanbindung befinden. Der PC sollte auch ausschließlich für CA Aufgaben verwendet werden. Ein alter Notebook mit einer 400MHz CPU und 1 GByte Platte sind hier völlig ausreichend, wenn man auf ein GUI verzichten kann. Ein USB Stick für den private Key sollte auch vorhanden sein. Der USB Stick ist dann quasi der Schlüssel für die CA und sollte bei Nichtgebrauch sicher aufbewahrt werden.
Bevor wir nun unsere CA in Berieb nehmen können, ist wieder mal der vi oder ein anderer Editor gefragt. Zunächst wird die Default openssl.cnf in das CA Verzeichnis kopiert, das hier in den Beispielen mit
mkdir /home/ca
angelegt wurde. Damit die verwendeten Skripte auch wissen, welche openssl.cnf zu verwenden ist, wird mit
export SSLEAY_CONFIG="-config /home/ca/openssl.cnf"
diese Datei im Environment festgelegt. Nun sollten ein paar Grundeinstellungen vorgenommen werden:
[ CA_default ]
dir = /home/ca/pugCA # Hier findet die OpenSSL "Buchführung" statt
default_days = 365 # Solange gilt ein Zertifikat (default)
# Für die Einrichtung der CA sollte da ein
# größerer Wert eingetragen werden, z.B. 7300
default_crl_days= 30 # In diesen Abständen sollten CRL Listen publiziert werden
policy = policy_anything # Damit wird eine Policy festgelegt
# Je nach Policy müssen bestimmte Felder des Subjects mit der
# CA übereinstimmen
# For the CA policy
# Hier müssen countryName, stateOrProvinceName und organizationName
# Mit denen der CA übereinstimmen.
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
# Hier werden alle Werte mit beliebigem Inhalt akzeptiert, aber
# diese Felder des Subjects müssen vorhanden sein
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Im folgenden Abschnitt der openssl.cnf können nun Defaultwerte gesetzt werden, die Benutzung von OpenSSL erleichtern. Die Namen der Felder sprechen eigentlich für sich und bedürfen keiner weiteren Erklärung.
[ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = DE countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Hessen localityName = Locality Name (eg, city) 0.organizationName = Organization Name (eg, company) 0.organizationName_default = Penguin User Group organizationalUnitName = Organizational Unit Name (eg, section) organizationalUnitName_default = Trustcenter commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 unstructuredName = An optional company name
Unter [ v3_ca ] sollten für eine richtige CA noch folgende Daten hinzugefügt werden:
crlDistributionPoints = URI:http://ca.pug.org/crl.pem nsCaRevocationUrl = http://ca.pug.org/taunusstein.net-crl.pem nsBaseUrl = http://ca.pug.org nsRevocationUrl = https://ca.pug.org/revoke.php nsRenewalUrl = https://ca.pug.org/renew.php nsCaPolicyUrl = http://ca.pug.org/ca-policy.html
Damit ist im Root Zertifikat auch festgelegt, unter welchen URLs Revocation Lists etc. zu finden sind. ca.pug.org muss natürlich durch den eigenen Server ersetzt werden.
In unser CA Verzeichnis wird nun die vorhandene CA.pl kopiert. Hier sollten sich dann openssl.cnf und CA.pl befinden. Will man nicht als CA Verzeichnis demoCA haben, dann muss man in der CA.pl noch die Zeile
$CATOP="/home/ca/pugCA";
eintragen werden. Die Zeile $CATOP="./demoCA"; ist zu entfernen.
Nun können wir endlich unsere CA anlegen. Von dem CA.pl Skript werden alle Dateien und Verzeichnisse automatisch angelegt. Bevor wir unsere neue CA generieren, sollte noch die Zeile
$CADAYS="-days 1095"; # 3 years
durch
# $CADAYS="-days 1095"; # 3 years $CADAYS="-days 7300";
ersetzt werden. Damit ist unser Root Zertifikat für rund 30 Jahre gültig. Unsere Root CA wird nun endlich mit
CA.pl -newca
erstellt. Es wird nach einer Passphrase gefragt. Weiterhin werden auch Name und diverse andere Daten abgefragt. Diese erscheinen dann im CA Zertifikat und allen Zertifikaten, die von dieser CA signiert werden. Die Passphrase sollte nicht zu einfach sein und sollte an einem sicheren Ort aufbewahrt werden. Es entsteht ein Verzeichnisbaum pugCA, in dem zwei Dateien zu finden sind:
private/cakey.pem cacert.pem
Die cacert.pem muss veröffentlicht werden, das ist das öffentliche CA Zertifikat.
Zertifikat generieren
Dieser Vorgang kann auf jedem Client durchgeführt werden, der sich von unserer PUG CA ein Zertifikat signieren lassen will. Die Datei server.key wird keinesfalls weitergegeben, weil diese den private Key enthält. Nur die Datei server.csr ist an die CA zu übergeben. Von der CA erhält man eine server.crt zurück. Es werden zunächst ein Key und ein Signing Request erzeugt:
openssl req -config /home/ca/openssl.cnf \ -subj "/C=de/ST=Hessen/L=Wiesbaden/O=pug.org/OU=Tux/CN=www.pug.org/emailAddress=nobody@example.com" \ -newkey rsa:4096 -keyout server.key -out server.csr
Hier ist erneut eine Passphrase einzugeben. Diese sollte (oder besser - darf) nicht mit der CA Passphrase identisch sein. Man kann die Daten unter -subj natürlich auch anders setzen, das soll hier nur ein Beispiel sein. Mit
openssl req -noout -subject -in server.csr
Kann man sich das Subject des Requests ansehen. Wird auf ein X.509 Zertifikat referenziert, so ist damit immer der Inhalt des Subjects gemeint. Bei der Erstellung von Zertifikaten muss immer darauf geachtet werden, dass das Subject innerhalb der CA eindeutig ist. Wenn bei der CA alles richtig konfiguriert ist, dann wird OpenSSL eine Signierung eines Zertifikats mit nicht eindeutigem Subject mit einer Fehlermeldung verweigern. Leider sagen die OpenSSL Fehlermeldungen nur wenig oder nichts über die tatsächliche Fehlerursache aus, sondern man bekommt nur cryptische Library Fehlermeldungen.
Elliptische Kurven
OpenSSL erlaubt es auch Schlüssel auf der Basis von Elliptischen Kurven zu erzeugen.
umask 177
CURVETYPE=sect571r1
openssl ecparam -out www.pug.org.key -name ${CURVETYPE} -genkey
umask 022
erzeugt einen privaten Schlüssel nach dem Standard ect571r1. Mit
openssl req \ -new \ -subj "/CN=www.pug.org" \ -key www.pug.org.key -out www.pug.org.csr
kann wie gewohnt ein CSR erstellt werden. Eine Warnung noch: Apache kann mit Schlüsseln, die auf Elliptischen Kurven basieren, (noch) nichts anfangen.
Zertifikat signieren
Die CA benötigt nur die server.csr Datei. Diese wird nun signiert:
openssl ca -config /home/ca/openssl.cnf -batch \ -keyfile pugCA/private/cakey.pem -cert pugCA/cacert.pem \ -in server.csr -days 365 -out server.crt -notext
Die nun entstandene server.crt Datei ist dem Benutzer zu übergeben. Der Parameter -days kann natürlich auch einen anderen Wert als 365 enthalten. Entsprechend lange ist das Zertifikat gültig.
Wer auch hier CA.pl verwenden will kann statt des o.g. Kommandos das auch wie folgt tun:
ln -s server.csr newreq.pem ./CA.pl -sign
Nach Angabe des CA Passworts hat man ein signiertes Zertifikat.
Zertifikat exportieren
Dafür gibt es das PKCS12 Format. Zunächst muss man die drei Komponenten
- CA Zertifikat
- private Key des beantragten Zertifikats
- Signiertes Zertifikat
in eine Datei kopieren. Mit
cp pugCA/cacert.pem tmp-cert cat server.key >> tmp-cert cat server.crt >> tmp-cert openssl pkcs12 -export -in tmp-cert > server.pkcs12
Zunächst muss man die Passphrase des private Keys angeben, danach ist eine Passphrase festzulegen, mit der das PKCS12 Päckchen verschlüsselt wird. Dies ist notwendig, weil der private Key entschlüsselt wird, wenn ein PKCS12 File erzeugt wird.
Anwendungen
Hier ein paar Anmerkungen und Besonderheiten bei verschiedenden Anwendungen
Webserver (SSL)
Wird das Zertifikat für einen Webserver verwendet, dann muss bei Request als CN der Hostname angegeben werden. Im o.g. Beispiel ist das www.pug.org. Damit kann man dann https Aufrufe auf den betreffenden Server machen. Die cacert.pem, die man auch nach ca.crt umbenennen kann, sollte der Benutzer installieren. Es reicht ein einfacher Link auf diese Datei, der Browser erkennt dann diesen Dateityp automatisch.
Damit der Apache ohne Passwort starten kann, muss der private key unverschlüsselt gespeichert werden. Hier besteht ein großes Risiko, also nur machen, wenn man weiss, was man da tut.
umask 177 openssl rsa -in server.key -out server-uncrypted.key
In der ssl.conf muss nun server-uncrypted.key verwendet werden. Es versteht sich hier von selbst, dass ausser Root niemand irgendwelche Rechte auf dieses File hat, muss also max. -rw------- sein.
IPsec
OpenCA, racoon und isakmpd können X.509 Zertifikate zur Authentifizierung benutzen. Auch Windows XP kann solche X.509 Zertifikate benutzen.
E-Mail Verschlüsselung
Thunderbird und Mozilla unterstützen S/MIME, dieses benutzt X.509 Zertifikate zum Verschlüsseln und signieren.
TLS-SMTP
Sendmail, Postfix und Exim4 können mit X.509 Zertifikaten Authetifizieren und verschlüsseln. Die Verschlüsselung ist allerdings nicht sehr wirksam, weil nur zwischen den beiden, miteinander kommunizierenden MTAs eine Verschlüsselung stattfindet.
POPS / IMAPS
Auch hier werden X.509 Zertifikate verwendet. Für Cyrus gibt es da ein sehr gutes How-To
Besonderheiten bei einer Windows 2003 Server CA
Bevor ein Windows 2003 sich einer mit OpenSSL generierten CA unterordnet, werden gewisse Anforderungen an die Root CA gestellt, die in der openssl.conf erfüllt werden können:
x509_extensions = v3_ca # V3 Extensions werden unterstützt nsCertType = server, client, email, objsign # Diese CA ist für alles zuständig, was signierbar ist [ v3_ca ] # die folgenden Pfade müssen existieren und für den Windows Server # zugreifbar sein !!! crlDistributionPoints = URI:http://ca.pug.org/ca/crl.pem nsCaRevocationUrl = http://ca.pug.org/ca/crl.pem nsBaseUrl = http://ca.pug.org/ca nsRevocationUrl = http://ca.pug.org/ca/revoke.php nsRenewalUrl = http://ca.pug.org/ca/renew.php nsCaPolicyUrl = http://ca.pug.org/ca/policy.html
Nur dann akzeptiert Windows 2003 Server ein mit einer openssl CA signiertes Zertifikat. Weiterhin müssen die oben mit "mandatory" gekennzeichneten Felder im Certificate Request zur CA passen.
