zurück zum Artikel

Nachdem der vorige Artikel das notwendige Grundwissen zu eigenen Virtual Private Networks vermittelt hat, geht es nun daran, die eigene Zertifikatsverwaltung einzurichten, das Gateway zu installieren und die Clients richtig zu konfigurieren.

Als Basis für die eigene Certification Authority (CA) dient in diesem praktischen Beispiel das Open-Source-Projekt OpenSSL, das auch Bestandteil der meisten Linux-Distributionen ist. Bevor man damit jedoch Zertifikate erstellt, muss die Konfigurationsdatei openssl.cnf an das jeweilige Umfeld angepasst werden. Dazu gehören die Verzeichnisse, in denen OpenSSL seine Dateien abspeichert, da diese stark von der jeweiligen Distribution abhängen. Passende Voreinstellungen für die einzelnen Elemente des Distinguished Name erleichtern die Arbeit. Des Weiteren kann man die Gültigkeitsdauer von Endzertifikaten und Certificate Revocation Lists (CRLs) modifizieren.

Da OpenSSL über die Kommandozeile zu bedienen ist und selbst elementare Aktionen wie das Erstellen eines neuen User-Zertifikats mehrere Schritte mit einer Vielzahl kryptischer Optionen erfordern, stellen wir über den Soft-Link einige Skripte bereit, die diese Vorgänge soweit wie möglich automatisieren. Zum Verständnis der Arbeitsweise erklären die folgenden Absätze einige dieser Schritte en détail. Die folgenden Befehle beziehungsweise die Skripte sind im Default-Verzeichnis von OpenSSL aufzurufen (oft /usr/ssl/).

Zertifikate

Als erstes benötigt man einen 2048 Bit langen RSA Private Key für die Certification Authority:

openssl genrsa -des3 -out private/cakey.pem 2048 

Dieser Schlüssel sollte aus Sicherheitsgründen unbedingt mit der Option ‘-des3’ unter Eingabe einer ‘Passphrase’ verschlüsselt werden, damit kein Unbefugter eigene User-Zertifikate signieren kann. Der zweite Schritt generiert das selbst unterzeichnete Root CA-Zertifikat, cacert.pem, mit einer Gültigkeitsdauer von vier Jahren:

openssl req -new -x509 -days 1460 -key private/cakey.pem -out cacert.pem 

Dieser Befehl fragt die vorher festgelegte Passphrase des Private Key und die einzelnen Elemente des Common Name ab.

openssl x509 -in cacert.pem -noout -text 

zeigt das Zertifikat in lesbarer Form an, sodass man die Eingaben nochmals überprüfen kann.

Das Erstellen eines neuen Zertifikats für VPN-Endpunkte - also für das Gateway und die Roadwarrior - erfolgt in drei Schritten. Der Befehl

openssl genrsa -des3 -out private/gatewayKey.pem 1024 

generiert einen RSA-Schlüssel mit 1024 Bit. Falls dieser mit ‘-des3’ geschützt wird, muss man die speziell für den Gateway-Key gewählte Passphrase später in der FreeS/WAN-Konfiguration in /etc/ipsec.secrets zusätzlich zum Dateinamen gatewayKey.pem angeben, damit FreeS/WAN auf den Schlüssel zugreifen kann.

openssl req -new -key private/gatewayKey.pem -out gatewayReq.pem 

erstellt den Antrag auf ein Zertifikat (Certificate Request), der mit

openssl ca -notext -in gatewayReq.pem -out gatewayCert.pem 

durch die CA unterschrieben wird. Dazu ist wiederum die Passphrase für den Schlüssel der CA einzugeben.

Aus historischen Gründen muss das Zertifikat des Linux-Gateways unter dem Dateinamen /etc/x509cert.der in binärer Form vorliegen. Der Befehl

openssl x509 -in gatewayCert.pem -outform der -out /etc/x509cert.der 

bewerkstelligt die notwendige Konvertierung.

Certificate Revocation List

Wer nicht jede Verbindung einzeln konfigurieren möchte, sondern über den Parameter ‘%any’ alle Roadwarrior mit Zertifikaten der VPN-CA akzeptiert, muss über eine Certificate Revocation List (CRL) dafür sorgen, dass das Gateway kompromitierte Zertifikate nicht mehr annimmt. Dazu erstellt die herausgebende CA periodisch eine gültige CRL, die ihre Unterschrift trägt:

openssl ca -gencrl -out crls/crl.pem 

Abhängig davon, wie schnell ein VPN-Gateway beziehungsweise die Clients auf eine Sperrung eines Zertifikats reagieren sollen, kann man die Gültigkeitsdauer dieser CRL in der Datei openssl.conf von 30 Tagen auf wenige Tage oder im Extremfall sogar nur wenige Stunden festlegen. Mit den Parametern ‘-crldays’ respektive ‘-crlhours’ kann dies auch direkt auf der Kommandozeile geschehen.

openssl ca -revoke bodoCert.pem 

markiert Bodos Zertifikat in der Datei index.txt als gesperrt, was beim nächsten Aktualisieren der CRL in die Datei crl.pem übertragen wird. Der Kontrollaufruf

openssl crl -in crls/crl.pem -noout -text 

zeigt die Serienummern der gesperrten Zertifikate an. Vor allem wenn CRLs auf einem Server öffentlich zugänglich gemacht werden, empfiehlt es sich, die CRL vorher vom PEM- in das binäre DER-Format zu wandeln. Der Befehl

openssl crl -in crls/crl.pem -outform der -out crls/cert.crl 

erledigt dies.

FreeS/WAN installieren

Die Installation von FreeS/WAN selbst ist in der Online-Dokumentation ausführlich beschrieben. Um mit Zertifikaten arbeiten zu können, muss man zusätzlich noch den X.509-Patch [6] einspielen, der an der Zürcher Hochschule Winterthur entwickelt wurde. Die folgende Anleitung bezieht sich auf die Version 0.9.8 des X.509-Patch, die zur FreeS/WAN-Version 1.95 passt und den Umgang mit den Zertifikaten im Vergleich zu früheren Versionen deutlich vereinfacht.

Der Download enthält neben der Installations- und Konfigurationsanleitung den eigentlichen Patch ‘freeswan.diff’, der im FreeS/WAN Quellverzeichnis wie folgt anzuwenden ist:

patch -p1 < freeswan.diff 

Danach kann man FreeS/WAN entsprechend der Dokumentation in ‘INSTALL’ übersetzen und installieren. Läuft bereits ein Kernel mit IPSec-Unterstützung, genügt es, mit

make programs make install 

die IPSec-Programme zu aktualisieren.

Danach sind die notwendigen Zertifikate und Schlüssel an die richtigen Stellen zu kopieren. Das CA-Root-Zertifikat, welches die Host- und User-Zertifikate beglaubigt, gehört in das Verzeichnis /etc/ipsec.d/cacerts/, eine optionale Certificate Revocation List (CRL) mit der Liste der gesperrten Serienummern in /etc/ipsec.d/crls/ und das eigene Host-Zertifikat des VPN-Gateways muss unter dem Dateinamen /etc/x509cert.der abgespeichert werden. Der dazugehörige Private Key muss in /etc/ipsec.d/private/ liegen, auf das nur root Zugriffsrechte besitzen darf. Die ebenfalls zugriffsgeschützte Datei /etc/ipsec.secrets muss mit der Zeile

: RSA gatewayKey.pem "Geheime Passphrase" 

den Dateinamen des Private Key sowie gegebenenfalls die Passphrase enthalten.

Die Definition der Roadwarrior-Verbindungen erfolgt in der Konfigurationsdatei /etc/ipsec.conf. FreeS/WAN verwendet für die beiden Enden einer VPN-Verbindung die Bezeichnungen ‘left’ und ‘right’. Meist bezeichnet ‘left’ das VPN-Gateway und ‘right’ den Roadwarrior, aber FreeS/WAN akzeptiert auch vertauschte Rollen. Die folgenden Erläuterungen beschränken sich auf die Parameter, die für das Aufsetzen von VPN-Verbindungen mit X.509-Zertifikaten relevant sind. Einen vollständigen Überblick über alle Optionen gibt die FreeS/WAN-Dokumentation.

Die Konfigurationsdatei ipsec.conf besteht aus einem allgemeinen ‘setup’-Abschnitt und einer unbeschränkten Anzahl von ‘conn’-Abschnitten, welche einzelne VPN-Verbindungen definieren. Der Abschnitt ‘conn %default’ enthält Defaultwerte, die für alle Verbindungen gelten.

Die unten abgedruckte Beispielkonfiguration legt durch die Parameter ‘rsasig’ und ‘%cert’ fest, dass die Authentifizierung mit RSA-Signaturen und Zertifikaten erfolgen soll. ‘left=%defaultroute’ übernimmt automatisch die (externe) IP-Adresse des VPN-Gateways während ‘leftsunet=10.1.0.0/16’ das Firmennetz angibt, das sich hinter dem VPN-Gateway befindet. Und schließlich spezifiziert ‘leftid’ den X.500 Distinguished Name des VPN-Gateways.

Die erste eigentliche Verbindungsdefinition akzeptiert jeden Roadwarrior, der ein Zertifikat von einer akzeptierten CA vorweist. FreeS/WAN ‘vertraut’ jeder CA, deren Root-CA-Zertifikat sich in /etc/ipsec.d/cacerts befindet. Damit ermöglicht eine einzige Roadwarrior-Definition eine unbegrenzte Anzahl von VPN-Verbindungen.

Bei wenigen VPN-Verbindungen oder wenn man Zugriffsbeschränkungen nicht über CRLs realisieren möchte, kann man auch jede Roadwarrior-Verbindung durch zusätzliche Angabe des Distinguished Name explizit aufführen. Dadurch weist das VPN-Gateway alle Benutzer ab, die zwar ein Zertifikat der Kool CA besitzen, aber nicht in ipsec.conf eingetragen sind.

IPSec unter Windows

Windows 2000 und XP enthalten bereits eine eigene IPSec-Implementierung; für andere Versionen muss man einen IPSec-Client wie SSH Sentinel, SafeNet/SoftRemote oder PGPnet installieren.

Sentinel enthält ein eigenes Key-Management, bei dem der Client Private Keys selbst erzeugt, die diesen nie verlassen. Derzeit ist es nicht möglich, extern erstellte Schlüssel zu importieren (erst Version 1.3 soll auch den Import über Dateien im PKCS#12-Format unterstützen). Bei der Installation generiert das Programm automatisch einen Private Key und speichert diesen zusammen mit einem selbst unterschriebenen Host-Zertifikat ab. Dieses Zertifikat akzeptiert das VPN-Gateway jedoch mangels Beglaubigung durch die Kool CA nicht.

Deshalb muss man zunächst mit Sentinel einen Certificate Request erstellen. Dies geschieht im ‘Key Management’ des SSH Policy Editor. Über einen Klick der rechte Maustaste auf ‘Authentication Keys / primary host key’ öffnet ‘Add New Authentication Key’ ein Popup-Menü, in dem ‘Enroll for a new certificate’ auszuwählen ist. Als Kennung dient die ‘Administrator E-Mail’; die erweiterten Optionen enthalten Eingabefelder für die anderen Elemente des gewünschten Distinguished Name (Land, Organisation et cetera).

Das ‘File Based Enrollment’ erlaubt es, den Antrag in der Datei ‘antje.req’ abzuspeichern, damit ihn die OpenSSL-CA der Kool AG bearbeiten kann. Der Befehl

openssl ca -notext -in antje.req -out antjeCert.pem 

erstellt dort das unterschriebene User-Zertifikat, das man im SSH Policy Editor mit dem Menü ‘Authentication Keys/primary host key/Import New Authentication Key’ in Sentinel importiert. Das bereits vorhandene, selbstunterschriebene Zertifikat darf man trotzdem nicht löschen, da dies den Private Key mit ins Jenseits befördern würde. Um aber unmissverständlich klarzustellen, dass Sentinel das Zertifikat der Kool CA verwenden soll, erklärt man es im Auswahldialog der rechten Maustaste zur ‘Default IPSec Response’.

Damit Sentinel der FreeS/WAN-Gegenstelle das gebührende Vertrauen entgegenbringt, muss das Root-CA-Zertifikat ‘cacert.pem’ unter ‘Trusted Root CAs’ geladen werden. Ein anschließender Klick auf ‘Apply’ etabliert die Vertrauensstellung.

Nun gilt es, die VPN-Verbindung im Hauptmenü der ‘Security Policy’ aufzusetzen. Dazu genügt es, mit ‘Add’ unter VPN Connections den Hostnamen des Gateways, das Zertifikat und die Netzwerk-Parameter des Firmennetzes einzutragen. Es ist wichtig, die Option ‘Legacy Proposal’ anzukreuzen, die unter anderem dafür sorgt, dass zur Verschlüsselung 3DES ausgehandelt wird.

Via ‘Diagnostics’ versucht Sentinel probehalber eine Verbindung aufzubauen. Auch wenn das im ersten Anlauf nicht klappt, sollte man nicht vergessen, die Verbindung mit ‘Apply’ fest einzurichten. Bei einem Ping auf einen der Firmenrechner sollte jetzt Sentinel die VPN-Verbindung selbstständig öffnen.

Windows 2000 und XP

Die meisten anderen IPSec-Clients und auch Windows selbst können selbst erstellte Schlüssel und Zertifikate im PKCS#12-Format mit der Dateiendung ‘.p12’ in die Schlüsselverwaltung importieren. Dazu packt die ausstellende CA das Zertifikat, den Private Key, sowie das Root-CA-Zertifikat und eventuelle Intermediate-CA-Zertifikate mit

openssl pkcs12 -export -in bodoCert.pem -inkey private/bodoKey.pem -certfile cacert.pem -out bodo.p12

in die Datei bodo.p12. Der Import in die Zertifikatsverwaltung von Windows darf jedoch nicht über einen Doppelklick auf die Datei geschehen, da sonst der Wizard das Zertifikat unter dem Benutzerkonto abspeichert, wo es die IPSec-Erweiterungen nicht finden. Die Management-Konsole (Start-Menü/Ausführen und ‘mmc’ starten) stellt die notwendigen Importfunktionen bereit. Über ‘Datei/Snap-In hinzufügen’ aktiviert man das Plug-in für ‘Zertifikate’ und wählt dabei explizit das ‘Computerkonto’. Über ‘Aktion/Alle Tasks’ kann man die Datei dann schließlich importieren. Dabei stellt die Option ‘Zertifikatspeicher automatisch auswählen’ sicher, dass die enthaltenen Zertifikate alle an der richtigen Stelle landen.

Theoretisch kann man unter Windows 2000/XP die notwendigen Filter und Regeln für eine IPSec-Verbindung ebenfalls in der Management-Konsole selbst erstellen. Doch dieser Vorgang ist äußerst umständlich und vor allem fehlerträchtig, sodass es sich empfiehlt, dies dem kostenlosen IPSec-Tool von Marcus Müller zu überlassen. Es benutzt die Programme ipsecpol.exe (W2K) beziehungsweise ipseccmd.exe (XP), die Microsoft zur Verfügung stellt, um die notwendigen Regeln anhand einer einfachen Konfigurationsdatei zu erstellen.

In der Datei ‘ipsec.conf’, deren Format an die gleichnamige FreeS/WAN-Datei angelehnt ist, trägt man die IP-Adresse des FreeS/WAN-Gateways und die des Firmennetzes ein. ‘rightca’ spezifiziert den Distinguished Name der austellenden CA (Windows sucht sich das passende Zertifikat dann selbst) und ‘network’ legt fest, ob die Übertragungen über die Dial-up-Verbindung (‘ras’), ein Netzwerk-Interface (‘lan’) oder beide (‘both’) gesichert werden sollen. Der Aufruf von ipsec.exe erstellt die Regeln, sodass ein anschließendes ‘ping 10.1.0.1’ mit dem FreeS/WAN-Gateway eine gesicherte Verbindung aushandeln sollte. Mit dem Parameter ‘-delete’ aufgerufen, löscht ipsec.exe die Regeln wieder.

Nach dem erfolgreichen Ping sollten interne Webseiten und alle anderen LAN-Ressourcen zugänglich sein - der Roadwarrior kann zukünftig übers Internet ‘nach Hause telefonieren’. (ju [1])

conn %default        authby=rsasig       leftrsasigkey=%cert

conn Bodo   left=%any   right=193.X.Y.Z   rightsubnet=10.1.0.0/255.255.0

Der Aufbau eines X.509-Zertifikats ist in der äußerst flexiblen, aber auch sehr komplexen ‘Abstract Syntax Notation One’ (ASN.1) definiert. Die Kodierung erfolgt binär unter Anwendung der Distinguished Encoding Rules (DER). Die ASN.1-Notation und die dazugehörige DER-Kodierung sind in den ITU-T-Empfehlungen X.680 respektive X.690 niedergeschrieben, der Zertifikatsaufbau im X.509-Standard.

Um Zertifikate zum Beispiel per E-Mail zu versenden, werden sie häufig vom binären DER-Format in das gleichwertige Base64-kodierte PEM-Format gewandelt. Der Base64-Zeichensatz, der auch bei MIME-Anhängen zur Anwendung kommt, besteht aus 64 druckbaren ASCII-Zeichen und vergrössert durch die Abbildung von drei 8-Bit- auf vier 6-Bit-Zeichen die Zertifikatsdatei um etwa ein Drittel.

Das Bild unten zeigt den prinzipiellen Aufbau eines X.509-Zertifikats. An erster Stelle steht die Versionsnummer. IPSec verwendet Zertifikate der Version 3 (X.509v3). An zweiter Stelle folgt eine eindeutige Serienummer, deren Aufbau die CA festlegt. Das nächste Feld gibt Auskunft darüber, mit welchem Algorithmus das Zertifikat digital unterschrieben ist. Das Signaturverfahren beruht meist auf einem über das Zertifikat gebildeten MD5- oder SHA-1-Hashwert, der mit dem privaten RSA-Schlüssel des Herausgebers verschlüsselt wird.

Das Issuer-Feld enthält den Distinguished Name der herausgebenden CA. Im Beispiel der Kool CA lautet er ‘C=DE, O=Kool AG, CN=Kool CA’. Das Validity-Feld legt die Gültigkeitsdauer fest. Sie beträgt für User- und Host-Zertifikate häufig 365 Tage. Es ist jedoch sinnvoll, selbst erzeugten CA-Zertifikaten eine Gültigkeit von drei bis vier Jahren zu geben. Nun folgt schließlich mit dem Subject-Eintrag die Identität des Zertifikatsinhabers ebenfalls in Form eines Distinguished Name. Im Beispiel von Antjes Zertifikat lautet dieser ‘C=DE, O=Kool AG, CN=antje@kool.net’. In einem selbst signierten Root-CA-Zertifikat stimmen Subject- und Issuer-Feld überein.

Der eigentliche Zweck eines Zertifikats ist die beglaubigte Verknüpfung einer Identität mit einem Public Key, der an nächster Stelle folgt. Endzertifikate für IPSec-Anwendungen beinhalten normalerweise einen RSA-Schlüssel mit 1024 Bit, während CA-Zertifikate wegen der längeren Lebensdauer meist mit 2048-Bit-Schlüsseln ausgestattet werden.

Anschließend an den Public Key können einige optionale Felder folgen, von denen nur die v3-Extensions eine Bedeutung für IPSec haben. Mit der Extension ‘subjectAltName’ kann die E-Mail-Adresse eines Users (Beispiel: antje@kool.net) oder ein Rechnername eines Hosts (Beispiel: gateway.kool.net) angegeben werden, der dann anstelle des vollständigen Distinguished Name als ID dienen kann.

Häufig wird in der Extension ‘crlDistributionPoints’, ein Uniform Resource Identifier (URI) auf einen HTTP- oder LDAP-Server unterbracht (zum Beispiel www.kool.net/ca/cert.crl), über den der VPN-Client eine aktuelle CRL des Zertifikatherausgebers beziehen kann. Es existieren noch viele weitere v3 Extensions, wobei aber häufig die genaue Interpretation und Verwendung umstritten ist.

Über den Kern des Zertifikats wird der MD5- oder SHA-1-Hashwert gebildet und die CA verschlüsselt diesen mit ihrem Private Key und hängt ihn unter nochmaliger Angabe des verwendeten Signaturverfahrens an den Kernteil an.

X.509 beim Schlüsselaustausch

Authentifizierung und Schlüsselaustausch erfolgen bei IPSec über ein eigenständiges Protokoll für den Internet Key Exchange (IKE), in das sich die X.509-Zertifikate nahtlos einfügen. Wenn Antje oder Bodo eine VPN-Verbindung von außen aufbauen, senden sie eine IKE-Meldung an den UDP-Port 500 des VPN-Gateways der Firma Kool AG. Dieser Port muss also durch die Firewall immer freigeschaltet sein, damit ein Verbindungsaufbau von beliebigen IP-Adressen aus möglich ist.

In einem ersten IKE-Meldungsaustausch (Meldungen 1 und 2 ) einigen sich Roadwarrior und VPN-Gateway auf IKE-Verbindungsparameter wie den verwendeten symmetrischen Verschlüsselungsalgorithmus sowie die Authentifizierungsmethode. In einem zweiten Schritt (Meldungen 3 und 4) wird mit Hilfe des Diffie-Hellman-Verfahrens (DH) ein gemeinsamer symmetrischer Schlüssel generiert, damit der dritte IKE-Austausch (Meldungen 5 und 6), welcher der Identifizierung und Authentifizierung der beiden Verbindungspartner dient, verschlüsselt und damit unter Ausschluss der Öffentlichkeit erfolgen kann.

Zur Authentifizierung sendet Antjes VPN-Client eine digitale Signatur (Sig). Diese wird als MD5- oder SHA-1-Hashwert über alle bisher ausgetauschten Meldungen, das Diffie-Hellman-Geheimnis und die Zufallszahlen R_i und R_r gebildet. Dieser Wert wird anschließend mit Antjes Private Key verschlüsselt. Das VPN-Gateway kann nach Erhalt der IKE-Meldung 5 mit Hilfe von Antjes Public Key die Gültigkeit dieser Unterschrift mit dem ebenfalls übertragenen Zertifikat (Cert) überprüfen. Die Echtheit des Public Key beweist die digitale Unterschrift der vertrauenswürdigen Root CA, über deren Public Key beide Kommunikationspartner verfügen. Wichtig ist dabei, dass die ID der IKE-Nachricht mit dem im Zertifikat aufgeführten Distinguished Name übereinstimmt. (ju [2])

URL dieses Artikels:
https://www.heise.de/-288142

Links in diesem Artikel:
[1] mailto:ju@ct.heise.de
[2] mailto:ju@heise.de

Copyright © 2002 Heise Medien