Skip to topic | Skip to bottom
Linux.ZertifikatHandlingr1.1 - 18 Apr 2008 - 11:25 - TWikiGuest? [Zum Ende]

Start of topic | Direkt zum Menü

Zertifikate unter Linux

Wenn's um Verschlüsselung, Signaturen, Zertifikate und Schlüssel geht, kann man schonmal den Überblick verlieren. Hier soll kurz erklärt werden, was zu beachten ist. Diese Seite geht zusätzlich speziell auf gegenheiten innerhalb der Max-Planck-Gesellschaft ein.

X.509-Zertifikate und was man damit macht

X.509-Zertifikate bauen auf einer hierarchischen Struktur auf. Grundelement ist dabei asymetrische Verschlüsselung. X.509 bietet heutzutage die einzige verbreitete Möglichkeit, verschlüsselt zu kommunizieren, ohne die eigene digitale Identität der Gefahr einer Kompromitierung auszusetzen. Die entsprechenden geheimen Schlüssel kann man nämlich in spezieller Hardware speichern, die diese Schlüssel dann nicht mehr herrausrückt - man kann nur noch digital unterschreiben bzw. entschlüsseln, wobei ausschliesslich der Hardware-Token selbst mit dem Schlüssel arbeitet.

Asymetrische Kryptographie

Es ist möglich zwei Zahlen G (Geheim) und N (nicht geheim) zu berechnen, die miteinander mathematisch verbunden sind - jedoch so kompliziert, dass man aus Zahl N nur mit extrem viel Aufwand (sprich: es dauert Jahrtausende ) G berechnen kann. Es gibt verschiedene Arten auf die diese Zahlen mathematisch verbunden sein können - gänging sind RSA und DSA, wobei bei X.509 hauptsächlich RSA benutzt wird.

Man kann mit G einen Text so unterschreiben , dass man - wenn man N kennt - zweifelsfrei testen kann, ob der Text mit G unterschrieben wurde.

Daraus folgt:

  • Es ist wichtig, dass niemand ausser dem Besitzer G kennt, sonst könnte dieser Jemand so tun, als hätte der Besitzer einen Text unterschrieben, den dieser aber gar nicht unterschrieben hat.
  • Es ist wichtig, dass niemand es schafft, andere dazu zu bringen, ein falsches N zu benutzen, um einen Text auf korrekte Unterschrift mit G zu testen. Würde das jemand schaffen - also jemanden N2 als N zu verkaufen, dann könnte dieser Jemand einen Text mit G2 unterschreiben und alle würden glauben, der Text wäre tatsächlich vom Besitzer von G unterschrieben worden.

Zertifikatsketten

Die asymetrische Kryptographie spinnt man jetzt etwas weiter:

  • Eine Sicherheitsfirma erzeugt sich ein Schlüsselpaar GC und NC und überzeugt Programmieren von Programmen, die sicher kommunizieren wollen (Webbrowser, eMail-Programme, ...), den öffentlichen Schlüssel NC auszuliefern.
  • Interessierte Anwender (z.B. Webserver-Betreiber) erzeugen sich eigene Schlüssel Gx und Nx .
  • Die Sicherheitsfirma bekommt von diesen Anwendern Nx vorgelegt, unterschreibt diesen Text (+einige Zusatzinformationen) - ein unterschriebenes N nennt man Zertifikat (wir nennen es Zx ) - einen beglaubigten öffentlichen Schlüssel.
  • Wenn ein Anwender seinen öffentlichen Schlüssel Nx weitergibt, legt er immer Zx dazu.
  • Wenn man einen öffentlichen Schlüssel Nx und das zugehörige Zertifikat Zx bekommt, und ein Programm benutzt, in dem NC gespeichert ist, kann man testen, ob es sich bei Zx um ein von der Sicherheitsfirma unterschriebenes Nx handelt und kann dadurch zweifelsfrei feststellen, dass man den richtigen öffentlichen Schlüssel bekommen hat.

Das ist ja noch relativ unkompliziert :-) - jetzt wirds baumförmig:

  • Es gibt eine andere Sicherheitsfirma. Diese will aber nicht immer mit Programmierern feilschen, so dass diese den öffentliche Schlüssel NE in alle Programme legen. Das spart Zeit, muss jedoch der ersten Sicherheitsfirma bezahlt werden.
  • Die erste Sicherheitsfirma unterschreibt den öffentlichen Schlüssel ( NE ) der zweiten und gibt ihr das Zertifikat ZE .
  • Die zweite Sicherheitsfirma hat auch Anwender und stellt diesen Zertifikate aus. Damit ein Anwender mit dem Schlüssel Ny jemand anderem nachweisen kann, dass er diesem den richtigen Schlüssel gibt, muss der Anwender nun folgende Daten übertragen: Ny , ZE und ZC .

Klingt auch noch einfach - aber:

  • Jetzt gibt es drei Ebenen:
    • Erste Sicherheitsfirma ( Root-CA )
    • Zweite Sicherheitsfirma ( CA )
    • Benutzer
  • Es kann beliebig viele Ebenen geben!

Ein neues Zertifikat von meiner CA

Situation: Meine Zertifizierungsstelle hat mir ein persönliches Zertifikat geschickt. Das soll nun in möglichst viele Programm eingebaut werden. Es ist auch denkbar, dass man nur darüber informiert wird, dass man sich das neue Zertifikat irgendwo herunterladen kann. In diesem Fall soll man versuchen eine komplette Zertifikatkette zu bekommen.

Hintergrund: Ich habe (z.B. zuhause) ein Public-/Private-Key-Paar erzeugt. Den privaten Schlüssel hab' ich im Tresor verschwinden lassen, den öffentlichen hab' ich der CA geschickt. Die CA hat meinen öffentlichen Schlüssel kryptografisch mit dem geheimen CA-Schlüssel unterschrieben, womit sie ausdrückt, dass sie mir glaubt, dass ich und der private Schlüssel im Tresor zusammengehören. Das Zertifikat (üblicherweise sind es mehrere - genauer: eine Kette von signierten öffentlichen Schlüsseln bis zu einer allgemein bekannten CA) aus der eMail (oder von der Website) ist kein Geheimnis - jeder, der sich dafür interessiert, darf es einsehen. Mir persönlich nützt das Zertifikat nichts, solange mein privater Schlüssel nicht damit verbunden ist.

Erzeugen eines PKCS#12 -Files

Im folgenden wird der private Schlüssel mit der zugeschickten Zertifikatskette verbunden, wodurch ein .p12 -File ( PKCS#12 , ein Paket aus Zertifikatskette und privatem Schlüssel - verschlüsselt mit einem Passwort) entsteht. Der private Schlüssel liegt üblicherweise in einer Datei mit der Endung .key , die Zertifikatkette kommt als ein .p7b -File. Mit openssl kann man es zusammenbauen.

Zuerst erzeugen wir ein .pem -File, in dem die einzelnen Zertifikate der Kette sichtbar getrennt voneinander liegen:

user@host > openssl pkcs7 -in aus_der_email.p7b -inform der -print_certs -out zertifikatkette.pem

Diese Datei ist noch kein Geheimnis. Jetzt muss man mit dem Editor ansetzen und aus der Textdatei zertifikatskette.pem zwei Einzeldateien user.pem (Der Block mit dem Benutzerzertifikat) und nurkette.pem (Alles andere) erzeugen.

Jetzt fügt man alle Teile zusammen. Dabei muss man zum einen das Passwort für das Schlüsselfile wissen und sich ausserdem gleich ein neues (oder das selbe) für das neu zu erstellende PKCS#12-File ( geheim.p12 ) ausdenken. Ausserdem gibt man dem fertigen Zertifikatspaket einen textuellen Namen. Diesen sollte man sinnvoll wählen, wenn man mehrere Schlüssel einsetzt.

user@host > openssl pkcs12 -export -in user.pem -certfile nurkette.pem\
-inkey schluessel.key -out geheim.p12 -name "MPG-User"

Das .p12 -file enthält nun geheime Informationen - man sollte es nirgends herumliegen lassen, ohne sich der Gefahr bewusst zu sein. Je laenger das Passwort, desto sicherer ist das File, allerdings hat ein Angreifer beliebig viele Versuche und unendlich viel Zeit, um ein solches File zu knacken.

Hier eine Auswahl von Programmen, die mit diesem File klarkommen:

  • Mozilla (Firefox, Thunderbird)
  • KDE (Konqueror, KMail)

Kleopatra kommt - obwohl der Import-Dialog es vorgibt - nicht mit .p12 -Files zurrecht. Man muss in diesem Fall das .pem -File benutzen.

Aladdin eTokens

Ein PKCS#12-File auf einen eToken kopieren

Ein eToken kann mehrere Identitäten enthalten. Die Identität wird durch die auth-id definiert. Man kann diese einfach hochzählen. Das --label= ist ein textueller Name, den ein Programm bei der Auswahl der gewünschten Identität vom eToken anzeigt. Identitäten sind jeweils an eigene Passworte gebunden - das ist z.B. für folgende Situationen gut:

  • Das eToken wird von mehreren Personen benutzt
  • Der Besitzer des eTokens hat mehrere Rollen inne (z.B. als Benutzer sowie als RA eines Instituts)

Hinweis: Unter Debian führt die Benutzung von pcscd gelegentlich dazu, dass man bei allen eToken-Kommandos noch -r [nummer] angeben muss. [nummer] ist die ID des eTokens, die man mit opensc-tool -l in Erfahrung bringen kann.

Zuerst legt man eine neue PKCS#15-Struktur an (sprich: eine Identität):

user@host > pkcs15-init -P --auth-id 01 --label "Meine Identitaet"

user@host > pkcs15-init -f pkcs12 --auth-id 01 --split-key -S geheim.p12

Für weitere Identittäten (spring PKCS12-Dateien), geht man genauso vor - ersetzt jedoch die auth-id -Nummern durch jeweils höhere.

pkcs15-init beschwert sich über ein zu kleines Profil

Fehlermeldungen der Art

File 3f0050154404 too small (require 529, have 512) - please increase size in profile

können einem den ganzen Tag versauen. Allerdings enthalten sie alle nötigen Informationen, um dem Fehler auf die Schliche zu kommen. Der "Dateiname" ist ein Pfad aus 16bit-Werten durch einen numerischen "Dateibaum". Die hintere Angabe ist die eigentliche Datei ( 4404 ).

Hintergrund: pkcs15-init benutzt statische Dateigrößen auf dem eToken. Diese sind in Profilen definiert, die in /usr/share/opensc liegen - üblicherweise hat man mit der Datei pkcs15.profile zu tun.

Lösung: Man suche nun einfach nach der Dateinummer ( 4404 in diesem Fall) und gehe intelligent vor. Diese Nummer ist z.B. ein einen Block wie diesem eingebettet:

       EF PKCS15-CDF {
           file-id      = 4404;
      size     = $cdf-size;
      acl      = $protected;
       }

Der Schlüssen size sticht ins Auge - ebenso wie die Variable $cdf-size , die weiter oben in der Profildatei gesetzt wird:

option default {
    macros {
        protected = *=$SOPIN, READ=NONE;
        unprotected  = *=NONE;
   so-pin-flags   = local, initialized, needs-padding, soPin;
   so-min-pin-length = 6;
   so-pin-attempts   = 2;
   so-auth-id  = FF;
   so-puk-attempts   = 4;
   so-min-puk-length = 6;
   unusedspace-size = 128;
   odf-size = 256;
   aodf-size   = 256;
   cdf-size = 512;
   prkdf-size  = 256;
   pukdf-size  = 256;
   dodf-size   = 256;
    }
}

Man muss nun den entsprechenden Wert ersetzen und von neuem mit der Grundinitialisierung beginnen, da pkcs15-init den eToken nach der fehlgeschlagenen Installation des Zertifikates in einem inkonsistenten Zustand hinterlassen hat.

Einrichtung eines eTokens

Mit diesem Kommando initialisiert man den eToken, wenn er neu ist oder wenn man alles, was drauf ist, runterschmeissen will.

Hinweis: Der --no-so-pin -Parameter verhindert, dass man ein sog. Security-Officer -Passwort festlegt. Mit diesem kann man den eToken später wieder löschen (mehr kann man damit nicht machen). Allerdings ist das Schein-Sicherheit, da man den eToken unter Windows auch ohne dieses Passwort wieder löschen kann.

user@host > pkcs15-init -E -C --no-so-pin

Dieses Kommando legt ein gewisses Verzeichnis-Skelett an, das später mit Identititäten gefüllt wird.

Dabei muss - wenn vorhanden - das letzte Security-Officer -Passwort angegeben werden. Wenn man das nicht mehr hat, ist der nächste Abschnitt dieser Seite zu konsultieren.

Löschen eines blockierten eTokens

Das geht leider nur unter Windows. Aladding hat dafür eine Software vorrätig. Diese Software funktionert unter Windows 2000, XP und 2003 und heisst eToken RTE.

Achtung: Es geht nur die Version 3.60 . Sowohl 3.65 wie auch der neuere PKIClient4.0 sind dafür nicht zu gebrauchen.

In der Registry muss allerdings noch ein Key angepasst werden.

HKEY_LOCAL_MACHINE\SOFTWARE\Aladdin\eToken\eTProperties\Advanced

muss auf

"0x0000001f"

gesetzt werden. Die Software läuft problemlos unter Qemu und Vmware, da beide in der Lage sind, USB-Geräte durchzureichen.

Der genaue Ablauf

Ist das Etoken-Tool installiert, muss man die Etoken-Hardware verfuegbar machen und das EToken Properties Tool starten - es sollte automatisch den kleinen Stick finden. Dann ist folgendes zu tun:

  • Man wähle Initialisation und dort Parameters
  • Im Passwords - Tab muss Initialize eToken und Create administrator password aktiviert sein.
  • Im Settings - Tab gibt man einen sinnvollen Namen ein, wählt die Farbe und Aktiviert Initialize the PKCS#11 user PIN
  • Im Initialization Key - Tab darf nur Use Default Initialization Key aktiviert sein.
  • Man schliesse den eToken Initialization Parameters - Dialog und klicke Start
  • Zumindest unter Qemu beschwert sich die Software während des Vorgangs über ein Kommunikationsproblem - das ist OK - der eToken kann jetzt unter Linux bearbeitet werden.

Nützlichen Anwendungen von PKI und asynmetrischer Kryptographie

Zertifikate im Apache

Apache mit SSL-Zertifikaten und Schlüsseln ausstatten

Der Apache ist vermutlich die am Meisten mit SSL benutzte Serversoftware - der Support und die Dokumentation ist entsprechend erstklassig. Hier trozdem einige Hinweise (alle bezogen auf Apache2 unter Debian):

Im Verzeichnis /etc/apache2/ssl legt man 2 Dateien an:

  1. key.pem - Der Schluessel des Apache als PEM-Datei
  2. cert.pem - Die Zertifikatskette die von einer in den Browsern der angenommenen Zielgruppe gültigen Root-CA zum öffentlichen Schlüssel des Apache führt.

Hinweis: Beide Dateien zusammen entsprechen dem Informationsgehalt eines PKCS#12-Files.

Und so sieht dann der SSL-Block in einem entsprechenden Virtualhost (oder auch in der globalen Konfiguration) aus:

   SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+SSLv2:+LOW:+EXP:+eNULL
   SSLCertificateFile /etc/apache2/ssl/cert.pem
   SSLCertificateKeyFile /etc/apache2/ssl/key.pem
   SSLEngine on

Beantragen eines Zertifikates - z.B. für Apache

Man benötigt dafür einen geheimen Schlüssel, mit dessen Hilfe man ein Certificate Request erzeugt. Der Schlüssel kann man für spätere Anträge wiederverwenden. So erzeugt man den Schlüssel:

user@host > openssl genrsa -out key.pem 2048

In diesem Fall handelt es sich um einen RSA-Schlüssel mit 2048bit Breite. Der Request wird wie folgt erstellt:

user@host > openssl req -new -kew key.pem -out request.csr

Man wird jetzt nach den diversen Details des Zertifikates (Geografische Position, Domaine, ..) gefragt. wichtig ist der Common Name (CN) - das muss der Servername des Apache sein.

Clientseitige Authentifikation mit Apache

Der Apache kann als Authentifikationsmethode die per Browser zur Verfügung gestellte X.509-Identität benutzen. Das Prinzip ist wie folgt:

  • Der Apache kennt den öffentlichen Schlüssel (sprich: selbst signiertes Zertifikat einer CA).
  • Baut ein Benutzer eine Verbindung aus, muss (kann, sollte, ... mehr dazu später) er eine Zertifikatkette übertragen, die seinen öffentlichen Schlüssel mit der im Apache gespeicherten CA verbindet.
  • Erkennt der Apache das Zertifikat an, beweist der Benutzer durch Verschlüsselung einer vom Server gesendeten Zufallszahl, dass er den geheimen Schlüssel des öffentlichen Schlüssels am Ende der Zertifikatskette wirklich hat.
  • Der Browser hat jetzt die Information, dass der Benutzer der ihm bekannten CA bekannt ist.

Der Apache benötigt im Verzeichnis /etc/apache2/ssl jetzt eine weitere Datei ca.pem , die den öffentlichen Schlüssel der CA enthält.

Folgender Block in der Apache-Konfiguration aktiviert die Client-Authentifikation per Zertifikaten:

   SSLCACertificateFile /etc/apache2/ssl/ca.pem
   SSLVerifyClient optional
   SSLVerifyDepth 4

Hinweise:

  • SSLVerifyClient kann ausser optional auch required sein. Im required Fall wird keine Verbindung aufgebaut, wenn der Benutzer kein Zertifikat vorgelegt hat.
  • SSLVerifyDepth ist die maximale Länge einer Zertifikatskette, die vom Benutzer vorgelegt werden darf. Ist die Kette länger - man ahnt es - geht die Verbindung schief.

Testen, ob der Apache SSLt

OpenSSL? hat dafür ein Kommando parat:

user@host > openssl s_client -connect [hostname]:[port] -showcerts

Dieses Kommando spielt SSL-Client, baut einen entsprechenden Tunnel auf und die -showcerts -Option sorgt dafür, dass der gesammte Zertifikataustausch angezeigt wird.

Apache mit SSL und mehreren Virtualhosts

Dadurch, dass der Name des virtual Hosts erst nach dem SSL-Verbindungsaufbau übertragen wird, kann der SSL-Server im Apache nicht wissen, welches Zertifikat er dem Client präsentieren soll, um korrekt identifiziert zu werden.

Es existieren derzeitig zwei Lösungen für dieses Problem:

  1. Man kann alle Namen, die an der IP-Addresse zur Verfügung stehen als Aliase ins Zertifikat eintragen, wobei es da verschiedene Techniken gibt. Daraus folgt, dass ein neu hinzugefügter virtueller Host immer ein neues Zertifikat nach sich zieht. Hier und hier gibt's einige Informationen zum Thema.
  2. TLS Server Name Indication arbeitet ähnlich wie starttls z.B. bei ESMTP. Der Hostname wird dabei im Klartext übertragen, anschliessend wird die verschlüsselte Verbindung aufgebaut - der Server kennt beim Austausch der Zertifikate also bereits seinen virtuellen Hostnamen. Unter http://journal.paul.querna.org/articles/2005/04/24/tls-server-name-indication?postid=70 gibt's eine Erklärung dazu.
  3. Wildcards können benutzt werden, um auf mehrere Subdomains zu matchen. Das Zertifikat wird dabei z.B. für *.example.com ausgestellt und passt dann z.B. auf test.example.com . Allerdings können das nicht alle Browser. Hier gibt's weitere Informationen.

eToken als HSM (Hardware Security Module)

Es ist möglich, ein eToken zu benutzen, um jegliche signaturbezogenen Operationen in externer Hardware und damit ausser Reichweite von Angreifern durchführen zu lassen.

Normalerweise benutzt Apache Files, um den geheimen Schlüssel und eine Zertifikatskette zu präsentieren. Die Zertifikatskette ist unkritisch, allerdings kann ein geknackter Server zu einem kompromitierten privaten Schlüssel führen.

Der naheliegendste Lösungsansatz ist, den privaten Schlüssel selbst zu verschlüsseln. Nachteil: Der Apache kann niemals ohne manuellen Eingriff hochfahren.

Wenn man ein alternatives Openssl-Backend installiert, braucht man sich diese Mühe nicht mehr zu machen. Man kann einen eToken benutzen und das Passwort zu diesem im Klartext auf dem Server lagern. Wird der Server nun geknackt, ist der geheime Schlüssel nur solange kompromitiert, wie der Einbruch unbemerkt bleibt. Danach zieht man den eToken ab und der Spuk ist vorbei. Der Angreifer kann vom eToken keine geheimen Schlüssel extrahieren.

Hinweis: Ein eToken bietet keine physische Sicherheit. Es gilt immer die Regel: An Informationen, die ich in Händen halte, komme ich irgendwie herran (Ausnahme One-Time-Pad-verschlüsselte Daten, was für eTokens nicht gilt). Auch wenn Aladdin anderes glauben machen will, der eToken ist bereits physisch geknackt worden.

Zertifikate und SSH

SSH unterstützt verschiedene Authentifikationsmethoden - eine davon basiert auf Public-Key, allerdings nicht auf einer PKI. SSH kommt mit RSA- und DSA-Schlüsseln zurrecht - MPG-Zertifikate enthalten mit hoher wahrscheinlichkeit einen RSA-Schlüssel.

eToken als SSH-Identität benutzen

Die Idee ist folgende:

  • Der SSH-Agent wird bei grafischen Logins im Hintergrund gestartet und kümmert sich um die Authentifikation, wenn SSH-Sitzungen diese Dienste anfordern.
  • Praktischerweise geht SSH nicht davon aus, dass der geheime Schlüssel den Agent irgendwann einmal verlassen muss.
  • Es reicht also, den Agent ein wenig aufzumotzen, so dass er Authentifikationsanfragen an den eToken durchleitet.

SSH kann das bereits - allerdings ist diese Funktionalität in den Debian-OpenSSH-Paketen abgeschaltet. Das InstantAFS-Projekt stellt ein modifiziertes Debian-Paket zue Verfügung.

Hinweis:

  • Man muss dem SSH-Paket nicht vertrauen - wenn man den eToken abzieht, kann nicht mehr authentifiziert werden - der geheime Schlüssel verläßt den eToken niemals.

Um einen Schlüssel aus einem eToken mit SSH zu benutzen, muss man folgendes eingeben:

user@host > ssh-add -s [Kartenid]

Die Kartenid ist die Nummer der Smartcard wie von opensc-tool -l angezeigt - in den meisten Fällen 0 .

PKCS#12-File als SSH-Identität benutzen

OpenSSH kann per PKCS#12-Files - allerdings nur im .pem -Format als Identitäten benutzen. Man braucht diese einfach nur wie normale SSH-Identitäten zu benutzen - z.B. so:

user@ssh-client > ssh-add id.pem

... oder auch so:

user@ssh-client > ssh -i id.pem benutzer@host

ssh-add wie auch ssh fragen bei Bedarf das Password des PKCS#12-Files ab.

Allerdings weiss SSH nichts von PKI - es benutzt lediglich den RSA-/DSA-Schlüssel im PKCS#12-File. Deshalb muss auf dem SSH-Server der passende Public-Key hinterlegt werden. Diesen extrahiert man wie folge aus dem PKCS#12-File...

user@ssh-client > ssh-keygen -y -f id.pem
Enter passphrase: [Passwort des .pem-Files]
ssh-rsa AAAAB3Nza[...]
user@ssh-client >

Die Zeile mit ssh-rsa bzw. ssh-dsa am Anfang kopiert man in die Datei ~/.ssh/authorized_keys auf dem SSH-Server.

Achtung: Die Zeile ist sehr lang und produziert Umbrüche im Terminal. In der authorized_keys -Datei muss es aber trotzdem genau eine Zeile (pro Identität) ergeben.

OpenSSL-Anwendungen eTokenifizieren

Alle Anwendungen die OpenSSL benutzen (Subversion, ...) können von dem Plugin-System profitieren, das OpenSSL mitbringt. Auf diese Weise kann z.B. die Authentifikation an einem Webserver per eToken passieren, ohne, dass die Anwendungs selbst irgendetwas von Smartcards weiss.

Unter Debian ist dazu ein zusätzliches Paket nötig:

root@host > =apt-get install libengine-pkcs11-openssl=

Informationen gibt's unter http://www.opensc-project.org/opensc/wiki/QuickStart .

eToken zum einloggen am KDE benutzen

Mit einem Entsprechenden PAM-Modul kann man eTokens benutzen, um sich am KDE (eigentlich an einem beliebigen Programm, das PAM unterstützt) mit einem eToken (eigentlich mit jeder beliebigen PKCS#11 kompatiblen Smartcard) einzuloggen.

Mehr dazu gibt's unter: http://www.opensc-project.org/pam_pkcs11/. Das PAM-Modul wird gerade debianisiert.

Zertifikate in der MPG

Die MPG betreibt eine eigene CA, die Benutzern nach physischem Kontakt Benutzerzertifikate ausstellt. Jeder Benutzer kann - unabhängig davon, dass er sein eigenes Zertifikat verlängern kann - neue Zertifikate beantragen - z.B. für Webserver. Ein Institut kann ausserdem Benutzer selbst identifizieren und für diese Zertifikate beantragen. Alle von der MPG-CA ausgestellten Zertifikate können unter http://user-ca.mpg.de in verschiedenen Formaten heruntergeladen werden.

Integration in gängige Root-CAs

Unbestätigten Gerüchten zufolge DFN-Verein versucht der DFN-Verein seine CAs (zumindest einen der Teilbäume) in Kürze von einer der üblichen Root-CAs zert ifizieren zu lassen. Derzeitig muss man noch mühsam alle interessierten Anwendungen mit dem selbstsignierten Zertifikat der DFN-CA-Wurzel bestücken.

Verlängern von Zertifikaten

Zertifikate müssen unbedingt vor ihrem Ablaufdatum verlängert werden, ansonsten kann man seine Identität (aus Sicht der MPG-CA) nicht mehr nachweisen und muss alles neu beantragen. Die Verlängerung kann ca 1 Monat vor Ablauf des Zertifikats durchgeführt werden - das dann neu entstehende Zertifikat trägt anschliessend eine andere ID und wird automatisch per eMail zugeschickt. Verlängerungsanträge können unter http://user-ca.mpg.de .

Beantragen weiterer Zertifikate

Jeder Benutzer der MPG-CA darf weiterer Zertifikate beantragen, die irgendwie Mit der MPG zu tun haben. Dererlei Zertifikatsanträge werden in der GWDG händisch geprüft. Solche Zertifikate können z.B. für Web-, IMAPS- oder auch SSH-Server benutzt werden.

Hinweise:

  • Das bringt erst wirklich etwas, wenn die MPG-CA eine Zertifikatskette zu einer gängigen Root-CA vorweisen kann.
  • Wenn man einen neues Schlüsselpaar benutzen will (z.B. weil man dem per GWDG-Mobile-CA erzeugten geheimem Schlüssel nicht traut), muss man ebenfalls ein neues Zertifikat beantragen.

Der CA vertrauen?

Die MPG-User-Ca hat den ehrenvollen Vorsatz, es dem Benutzer so leicht wie möglich zu machen. Das schliesst ein, dass man auf der Website ein Passwort eingibt - später kann man dann das fertige PKCS#12-File herunterladen. Der Schlüssel im PKCS#12 ist mit dem eingegebenen Passwort gesichert.

Der paranoide Sicherheitsfanatiker sieht darin zwei Probleme:

  • Das Passwort muss irgendwie einmal über das Netzwerk wandern und kann später für Angriffe auf das PKCS#12-File benutzt werden. (Ja, es gab schon erfolgreiche MitM-Angriffe auf HTTPS-Server).
  • Der geheime Schlüssel wird über's Netzwerk übertragen bzw. kann sogar einfach so im PKCS#12-Format heruntergeladen werden. Das dieses File per Passwort gesichert ist, spielt dabei keine Rolle - ein Offline-Angriff ist dadurch möglich.

Es geht auch anders. Laut X.509 ist es nicht nötig, dass eine CA jemals den privaten Schlüssel oder irgendein Passwort des Benutzers sieht. Sie bekommt eigentlich nur einen Request - bestehend aus öffentlichem Schlüssel und einigen Angaben und liefert ein Zertifikat (oder auch eine ganze Kette) als PKCS#7 zurück.

Einen Request kann man leicht selbst erzeugen:

user@host > openssl req -new -keyout schluessel.pem -out request.pem -days 365

Dieses Kommando erzeugt einen neuen Schlüssel und daraus einen Request. Bei Bedarf kann man auch einen vorhanden Schlüssel benutzen ( Option -in ). Man muss ein Passwort eingeben, mit dem das Schlüsselfile gesichert wird (mit Bestätigung). Ausserdem müssen noch einige Daten eingegeben werden, die dann von der CA mitunterschrieben werden - z.B. das Land, in dem man wohnt.

Der Schlüssel liegt nach dem Aufruf in schluessel.pem , kann anschliessend in den Tresor wandern. Der Request request.pem ist frei von geheimen Daten und kann an die CA geschickt.

Achtung: Der Request hat den Status eines öffentlichen Schlüssel. Das bedeutet, dass böse Buben daran interessiert sein könnten, den Request auf dem Weg zu seinem Ziel (der CA) zu manipulieren. Die Übertragung muss also selbst gesichert sein - z.B. per HTTPS.

Zertifikate über eine Institutseigene RA beantragen

Da es unpraktisch ist, wenn jeder, der mit Verschlüsselung arbeiten will, erst nach Göttingen fahren muss (obwohl das eine sehr schöne Stadt ist), kann man die physische Benutzeridentifizierung bei Bedarf in die einzelnen Institute verlegen. Das Prinzip ist dabei folgendes:

  • Ein Benutzer geht auf die Seite http://user-ca.mpg.de/request und beantrage ein Zertifikat. Er bekommt eine Seite, die er ausdrucken muss, die einen Fingerabdruck des Requests enthält.
  • Der Benutzer geht zu einem Institut auf dieser Liste und zeigt bei dem Ansprechpartner seinen Ausdruck vor.
  • Der Ansprechpartner lädt seine RA-Identität entweder in den Browser oder wechselt zu dieser auf dem eToken - diese Identität ist nicht sein normales Benutzerzertifikat.
  • Der Ansprechpartner geht auf eine unter http://user-ca.mpg.de/ras/ aufgeführte Seite. Diese ist üblicherweise im Layout des lokalen Instituts gehalten, wird jedoch in der GWDG gehostet.
  • Nach Überprüfung eines Lichtbildausweises und dem Fingerabdruck auf dem Ausdruck des Benutzers, signiert der Ansprechpartner auf der RA-Seite den Antrag des Benutzers.
  • Alles weitere macht die Mpg-CA in Göttingen. Der Benutzer bekommt sein Zertifikat per eMail.

Andere Plattformen

MacOSX?

Unter http://ata.cit.cornell.edu/cit/ata/Try-PKI.cfm gibt's downloadbare eToken-Middleware, unter http://ata.cit.cornell.edu/cit/ata/upload/Signed-Encryped-Email.pdf gibt's ein PDF mit Anleitung dafür.
[Zurück zum Start]


Aktuelle Wiki-Seite: Linux > LinuxAnLeitungen > ZertifikatHandling

[Zurück zum Start]