Wie man am LRZ ein Zertifikat beantragt

Die konkreten Schritte zur Beantragung eines X.509-Zertifikats beim LRZ werden beschrieben und es wird kurz auf die Verwendung des Zertifikats eingegangen.

Das Zertifikat beglaubigt die Zugehörigkeit eines öffentlichen Schlüssels zu einem Zertifikatnehmer (englisch „subject“), der entweder ein „Nutzer“, also eine Person oder ein Angehöriger einer Gruppe von Personen, oder ein „Server“, also ein von einem Rechner erbrachter Dienst wie WWW, E-Mail oder LDAP, sein kann. Der Zertifikatnehmer muss dabei im Besitz des zugehörigen privaten Schlüssels sein, sonst kann er mit dem Zertifikat nichts anfangen. Für andere hingegen, die sich nicht als der Zertifikatnehmer ausgeben wollen, reicht das Zertifikat allein zur Identifizierung des Zertifikatnehmers, zur Verschlüsselung von Nachrichten an den Zertifikatnehmer und zur Verifikation elektronischer Unterschriften des Zertifikatnehmers aus. Die zugrundeliegenden Mechanismen sind im Übersichtsartikel über Zertifizierung eingehend beschrieben.

Ein Zertifikat zu beantragen, erzeugen zu lassen und zu installieren erfordert eine Reihe von Schritten, die nur zum Teil technischer Art sind; daneben gibt es Verwaltungsschritte wie die Abgabe von Erklärungen mit persönlichem Erscheinen.

Weitere Hinweise finden Sie in der FAQ-Liste Fragen und Antworten zum Thema DFN-PKI.

Gesamter Ablauf

Gehen Sie bei der Beantragung eines Zertifikats am LRZ der Reihe nach wie folgt vor:

  • Überzeugen Sie sich, dass das LRZ dafür zuständig ist, Ihnen für den Zweck ein Zertifikat zu erteilen. Einen Überblick finden Sie im Artikel Zertifizierung durch das LRZ; bei Rückfragen wenden Sie sich per E-Mail an die Zertifizierungsstelle des LRZ.

  • Die Zertifizierungsstelle des LRZ hat keine eigene Benutzerverwaltung, in der Name und Anschrift Ihres Instituts mit den Namen der Verantwortlichen festgehalten sind. Wenn Ihr Institut noch nicht Kunde des LRZ ist, müsste es das durch Abgabe eines Antrags werden; das ist aber der weitaus seltenere Fall. Klären Sie das gegebenenfalls.

  • Legen Sie fest, wer das Zertifikat beantragt. Bei Nutzerzertifikaten ist das die zertifizierte Person selbst, bei Serverzertifikaten die Person, die im Auftrag des Betreibers die Erzeugung des Schlüsselpaares vornimmt und Schlüssel und Zertifikate in das Serversystem einbringt, die also eine Gewähr für die korrekte Handhabung bieten kann, so dass der Schlüssel nicht durch viele Hände geht. Die Beauftragung dieser Person wird durch ein formloses Schreiben des Serverbetreibers nachgewiesen, die Akkreditierung. Diese wird durch jemanden ausgesprochen, der dem LRZ als Leiter der Einrichtung (oder für die TUM auch: als Master-User eines einschlägigen Projekts) bekannt ist. Sich selbst braucht man nicht zu akkreditieren; die Akkreditierung entfällt dann.

  • Erzeugen Sie (das ist von hier an die Person, die das Zertifikat beantragen wird) ein Schlüsselpaar und beantragen Sie das Zertifikat dafür über das Web-Interface der Registrierungsstelle. Wie das geht, steht unten unter „Technischer Ablauf“. Bei dieser Gelegenheit können Sie eine Erklärung ausdrucken, die Sie später unterschrieben der Registrierungsstelle vorlegen.

  • Vereinbaren Sie per E-Mail einen Termin mit der Registrierungsstelle (TUM: tum-ra@lrz.de; LMU: lmu-ra@lrz.de; alles andere außer Grid: pki@lrz.de; Grid: grid-ra@lrz.de). Erscheinen Sie dort unter Vorlage eines gültigen Reisepasses oder Personalausweises und geben Sie die im letzten Schritt erzeugte Erklärung und gegebenenfalls die Akkreditierung ab.

  • Ihr Zertifikat wird Ihnen dann per E-Mail zugesandt. Was Sie damit machen, steht wieder unten unter „Technischer Ablauf “.

Technischer Ablauf

Bei der Erzeugung von Zertifikaten spielen vier Datensätze eine Rolle, die entweder als Dateien vorliegen oder während der Bearbeitung nur im Inneren der beteiligten Programme gehalten werden:

  1. Der private Schlüssel wird vom Zertifikatnehmer selbst erzeugt und nie aus der Hand gegeben, auch nicht für die Erzeugung des Zertifikats. Am Ende des gesamten Vorgangs ist er auf allen Softwaresystemen installiert, die den Schlüssel zur Kommunikationssicherung und zur Verschlüsselung oder Entschlüsselung von Daten im Namen des Zertifikatnehmers brauchen. In der Regel ist jede Datei, die den privaten Schlüssel enthält, mit einem vom Benutzer gegebenen Passwort chiffriert, um ihn vor der Verwendung durch Dritte zu schützen.

  2. Der Zertifikatantrag (CSR = Certificate Signing Request) enthält den öffentlichen Schlüssel und weitere Angaben. Er muss nicht vertraulich behandelt werden. Wenn das Zertifikat erzeugt ist, wird er nicht mehr gebraucht.

  3. Das Zertifikat muss zusammen mit dem privaten Schlüssel jedem Softwaresystem zur Verfügung stehen, das den privaten Schlüssel benutzt. Außerdem ist es das Mittel der Wahl, mit dem der öffentliche Schlüssel nach außen bekanntgemacht wird.

  4. Die Zertifikatkette, also eine Kette von Zertifikaten, bei denen jedes das voranstehende beglaubigt, wird zusammen mit dem Zertifikat von der Software vorgelegt. Sie muss also ebenfalls jedem Softwaresystem zur Verfügung stehen, das den privaten Schlüssel benutzt.

Dateien, die den privaten Schlüssel enthalten, sind selbst wieder kryptografisch gesichert. Das ist insbesondere der Zertifikatspeicher der Applikation, die den privaten Schlüssel enthält (die Produkte der Mozilla-Suite fragen dann nach dem „master passwort for the Software Security Device“), außerdem alle Dateien, mittels derer Schlüsseldaten von einer Anwendung zur anderen transportiert werden. In der Hoffnung, die Verwirrung zu reduzieren, werden in diesem Artikel die Wörter „Schlüssel“ und „verschlüsseln“ nur verwendet, wo es um die Anwendung des im Zertifikat beglaubigten Schlüsselpaares geht, und die Wörter „Passwort“ und „chiffrieren“, wo es um den Schutz des privaten Schlüssels geht.

Wie kommt nun alles an seinen Platz? Dafür gibt es zwei Möglichkeiten.

Die erste, sehr viel komplizierter aussehende, ist die allgemeinere, die immer funktioniert. Für Serverzertifikate ist sie die einzig gangbare; für Nutzerzertifikate empfiehlt sie sich mindestens dann, wenn man die Zertifikate noch an anderer Stelle braucht als nur in dem Programm, das die Schlüssel generiert.

Die zweite verwendet einen Browser zur Schlüsselerzeugung; derselbe Browser behält dann den Überblick über alle vier obengenannten Dateien. Wenn man die Dateien aber woanders braucht, muss man erst den Browser überreden, sie wieder herauszurücken – das geht, macht aber die schöne Einfachheit zunichte. Deswegen wird sie nur für Nutzerzertifikate unterstützt.

1. Möglichkeit: Alles einzeln bauen und später zusammenfügen

Das Programm der Wahl heißt openssl und steht auf vielen Systemen zur Verfügung. Im folgenden bezeichne xyz einen beliebigen Dateipfad, der vom Benutzer frei wählbar ist; die verschiedenen Dateien werden dann wie üblich durch ihre Endung unterschieden.

Man erzeugt ein Schlüsselpaar, bestehend aus öffentlichem und privatem Schlüssel, mit dem Kommando

openssl genrsa -des -out xyz.key 2048

Für die Ablage des Schlüssels wird ein Passwort verlangt, auch „Passphrase“ genannt, die zur Chiffrierung des Schlüsselpaars in der Datei verwendet wird. Das muss man sich unbedingt merken, weil sonst die entstandene Datei nicht mehr lesbar ist.

Damit hätten wir den privaten Schlüssel (Punkt 1 oben).

Als zweites erzeugt man eine Konfigurationsdatei xyz.conf für die nachfolgende Erzeugung des Zertifikatantrags. Sie bekommt folgenden Inhalt:

  • für Serverzertifikate (nicht Grid) aus der TUM:

    prompt = no
    distinguished_name = req_distinguished_name
    [ req_distinguished_name ]
    countryName = DE
    stateOrProvinceName = Bayern
    localityName = Muenchen
    organizationName = Technische Universitaet Muenchen
    commonName = Name des Zertifikatnehmers
    emailAddress = E-Mail-Adresse des Zertifikatnehmers
  • für Serverzertifikate (nicht Grid) aus der LMU:

    prompt = no
    distinguished_name = req_distinguished_name
    [ req_distinguished_name ]
    countryName = DE
    stateOrProvinceName = Bayern
    localityName = Muenchen
    organizationName = Ludwig-Maximilians-Universitaet Muenchen
    1.organizationalUnitName = Organisationseinheit
    commonName = Name des Zertifikatnehmers
    emailAddress = E-Mail-Adresse des Zertifikatnehmers
  • für Zertifikate (nicht Grid) aus der BAdW oder dem LRZ:

    prompt = no
    distinguished_name = req_distinguished_name
    [ req_distinguished_name ]
    countryName = DE
    stateOrProvinceName = Bayern
    localityName = Muenchen
    organizationName = Bayerische Akademie der Wissenschaften
    commonName = Name des Zertifikatnehmers
    emailAddress = E-Mail-Adresse des Zertifikatnehmers
    prompt = no
    distinguished_name = req_distinguished_name
    [ req_distinguished_name ]
    countryName = DE
    stateOrProvinceName = Bayern
    localityName = Garching b. Muenchen
    organizationName = Bayerische Akademie der Wissenschaften
    0.organizationalUnitName = Leibniz-Rechenzentrum
    commonName = Name des Zertifikatnehmers
    emailAddress = E-Mail-Adresse des Zertifikatnehmers
  • für Serverzertifikate (nicht Grid) aus anderen Einrichtungen im MWN:

    prompt = no
    distinguished_name = req_distinguished_name
    [ req_distinguished_name ]
    countryName = DE
    stateOrProvinceName = Bayern
    localityName = Muenchen
    organizationName = Bayerische Akademie der Wissenschaften
    0.organizationalUnitName = Muenchner Wissenschaftsnetz
    commonName = Name des Zertifikatnehmers
    emailAddress = E-Mail-Adresse des Zertifikatnehmers
  • für Grid-Zertifikate aus TUM, LMU oder LRZ:

    prompt = no
    distinguished_name = req_distinguished_name
    [ req_distinguished_name ]
    countryName = DE
    organizationName = GridGermany
    0.organizationalUnitName = Einrichtung
    commonName = Name des Zertifikatnehmers
    emailAddress = E-Mail-Adresse des Zertifikatnehmers
  • für Grid-Zertifikate aus der UniBW:

    prompt = no
    distinguished_name = req_distinguished_name
    [ req_distinguished_name ]
    countryName = DE
    organizationName = GridGermany
    0.organizationalUnitName = Universitaet der Bundeswehr Muenchen
    commonName = Name des Zertifikatnehmers
    emailAddress = E-Mail-Adresse des Zertifikatnehmers

Die Angaben zu Name des Zertifikatnehmers, E-Mail-Adresse, Organisationseinheit und Einrichtung müssen dabei entweder durch Ersetzung der rechten Seite korrekt ausgefüllt werden, oder es muss die ganze Zeile entfernt werden. Die Angabe der E-Mail-Adresse ist bei allen Zertifikaten empfohlen, aber nur bei Grid-Zertifikaten Pflicht. Die übrigen Angaben sind immer dann Pflicht, wenn sie im entsprechenden farbig unterlegten Muster aufgeführt sind. Diese Angaben haben folgende Bedeutung:

  • Name des Zertifikatnehmers bei Servern: vollständiger DNS-Name des Servers
  • Name des Zertifikatnehmers bei Personen: Vor- und Zuname ohne Umlaute und andere Nicht-ASCII-Zeichen, ansonsten wie in einem amtlichen Ausweis (der dann auch vorgelegt werden muss!)
  • E-Mail-Adresse: bei Servern E-Mail-Adresse der Betreibermannschaft, nicht einer einzelnen Person
  • Organisationseinheit: offizieller Name der Fakultät, des Departments oder des Lehrstuhls
  • Einrichtung: Leibniz-Rechenzentrum für das LRZ selbst, Bayerische Akademie der Wissenschaften für die BAdW mit Ausnahme des LRZ (diese beiden als organizationName), bei Grid-Zertifikaten auch Technische Universitaet Muenchen, Ludwig-Maximilians-Universitaet Muenchen, sonst mit der Einrichtung vereinbarte Bezeichnung (als organizationalUnitName)

Aus diesen beiden Dateien (Schlüsselpaar xyz.key und Konfigurationsdatei xyz.conf) kann man einen CSR erzeugen und in der Datei xyz.csr ablegen:

openssl req -config xyz.conf -new -key xyz.key -sha256 -out xyz.csr

Man hätte auch Schlüsselpaar und CSR mit einem einzigen Aufruf erzeugen können:

openssl req -config xyz.conf -newkey rsa:2048 -sha256 -keyout xyz.key -out xyz.csr

Damit hätten wir auch den Zertifikatantrag (Punkt 2 oben). Diesen liefert man im Web-Interface der Registrierungsstelle ab, nämlich:

(In dem Web-Formular wird nach einer „PEM-formatierten“ Datei gefragt. Die wie beschrieben erzeugte Datei xyz.csr hat dieses Format und passt für den Zweck, auch wenn ihr Name nicht auf .pem endet.)

Bei dieser Gelegenheit wird ein Formular erstellt und weitgehend ausgefüllt, das dann der Registrierungsstelle (RA) vorgelegt wird, wenn man das Zertifikat dort beantragt (siehe unten). Nach Genehmigung durch die RA erhält man per E-Mail das Zertifikat (Punkt 3 oben) und erfährt, wo man die Zertifikatkette (Punkt 4 oben) herbekommt.

Will man das Zertifikat in der Datei xyz.pem lesen, so geht das mit dem Kommando

openssl x509 -in xyz.pem -noout -text

CSRs kann man übrigens fast genauso lesen, mit req statt x509.

Jetzt hat man alles in Einzelteilen: das Schlüsselpaar xyz.key, das Zertfikat xyz.pem und die Zertifikatkette cacerts.pem. Wie man die Teile dort zusammenbringt, wo man sie braucht, richtet sich nach der Applikation. Hier sind ein paar mögliche Fälle:

  • Die Applikation benutzt für den Import der Schlüssel eine Datei xyz.p12 im Format PKCS#12, z.B. Mozilla, Firefox, Thunderbird. Eine solche Datei kann man aus dem Einzelteilen mit dem folgenden Kommando zusammenbauen:

    openssl pkcs12 -export -inkey xyz.key -certfile cacerts.pem -out xyz.p12 -in xyz.pem

    Dabei muss man insgesamt dreimal ein Passwort eingeben: einmal das Passwort, mit dem xyz.key chiffriert ist, und dann zweimal ein Passwort, mit dem die neue xyz.p12 chiffriert wird und das dann beim Import in die Applikation wieder angegeben werden muss.

    Nach dem Import in Mozilla, Firefox, Thunderbird müssen noch die Berechtigungen für die neuen Zertifikate händisch gesetzt werden.

  • Wenn die Applikation den Schlüssel unchiffriert braucht, wird man so die Passphrase auf der Schlüsseldatei los:

    openssl rsa -in xyz.key -out xyz-unchiffriert.key

2. Möglichkeit: Alles den Browser machen lassen und gegebenenfalls auseinandernehmen

Man geht sofort ins Web-Interface der Registrierungsstelle, nämlich:

Dort folgt man den Pfaden für Nutzerzertifikate und füllt alles aus. Manche Angaben werden zweimal erfragt, insbesondere die „Abteilung“ und die E-Mail-Adresse. Einmal handelt es sich um die Daten, die ins Zertifikat sollen (da ist praktisch immer die Angabe „Abteilung“ einfach wegzulassen) und einmal um Kontaktdaten des Antragstellers für Rückfragen und für den Versand des Zertifikats. Mit dem Ausfüllen entsteht sowohl das Schlüsselpaar (Punkt 1 oben) als auch der CSR (Punkt 2 oben). Beide sieht man nicht: das Schlüsselpaar bleibt im Browser gespeichert und der CSR wird an die Registrierungsstelle gesandt.

Kommt dann das Zertifikat per E-Mail, dann verwendet man nicht das zugesandte Zertifikat, sondern die in der E-Mail angegebene Adresse zum Herunterladen des eigenen Zertifikats. Das funktioniert aber nur aus demselben Browser, mit dem das Schlüsselpaar generiert wurde, denn nur der ist im Besitz des Schlüsselpaars. Der Browser kann dann die Verbindung zwischen vorhandenem Schlüsselpaar und neuem Zertifikat herstellen.

Ist dieser Browser die einzige Software, die Schlüssel und Zertifikat braucht, ist man fertig. Um diese Information von einem System auf ein anderes zu übertragen, kann man sie exportieren und woanders wieder importieren. Braucht man aber die Information einzeln, etwa das Schlüsselpaar, muss man nach dem Export die entstandene Datei auseinandernehmen, die dann im Format PKCS#12 vorliegt. Das geschieht mit dem Kommando

openssl pkcs12 ...

Welche Parameter dieses Kommandos dabei gebraucht werden, richtet sich danach, welche Information an welcher Stelle in welchem Format gebraucht wird. Ein Beispiel fürs Grid-Computing findet sich im Wiki der GridSite.

Besonderheiten

Mehrere Servernamen

Tritt ein und derselbe Server unter mehr als einem Namen auf, muss das Zertifikat alle diese Namen enthalten. Das geschieht in der Zertifikaterweiterung „subject alternative name“, und zwar am zuverlässigsten in der Weise, dass alle Namen, auch der eindeutige Name (distinguished name) des Zertifikatnehmers, als alternative Namen im Zertifikat enthalten sind. Ob die Applikationssoftware dann diese alternativen Namen akzeptiert, bleibt ihr überlassen ...

Ob Sie diese zusätzlichen Namen in den CSR mit aufnehmen können, ist von CA zu CA verschieden. Bei der Grid-CA geht es nicht, bei der LRZ-CA, der LMU-CA und der TUM-CA dagegen schon. Leider ist es ein wenig umständlich, aber immer noch einfacher, als die zusätzlichen Namen von Hand nachzutragen. Ergänzen Sie die Datei xyz.conf um einige weitere Zeilen folgenden Inhalts:

[ req_exts ] subjectAltName = @SAN [SAN] DNS.0=DNS-Name wie im Common Name DNS.1=weiterer DNS-Name DNS.2=weiterer DNS-Name

und fügen Sie zum Kommando „openssl req“ das Parameterpaar „-reqexts req_exts“ hinzu, mit dem diese zusätzlichen Teile der Konfigurationsdatei mit bearbeitet werden.

Bei der Grid-CA, bei der das nicht so geht, brauchen Sie nicht zu versuchen, diese Namen in den CSR mit aufzunehmen – sie werden dort eh wieder entfernt. Teilen Sie Ihre Anforderung einfach der Registrierungsstelle mit, die sich dann darum kümmert.

Domain Controller

Wenn Sie ein Zertifikat mit dem Profil „Domain Controller“ erstellen möchten, müssen Sie vor der Genehmigung des Antrags von der Registrierungsstelle noch die GUID des Domain Controllers als alternativen Namen „Microsoft_GUID“ eintragen lassen. Diese GUID finden Sie mit Ldp.exe heraus; der Name wird ohne die von Ldp angezeigten Bindestriche eingetragen.

Zertifikatprofile

In den Zertifikaten sind Angaben zu den erlaubten Verwendungszwecken enthalten. Da die meisten Zertifikatnehmer die Details nicht kennen, sind die häufigsten Kombinationen von Verwendungszwecken zu Zertifikatprofilen zusammengestellt worden, von denen bei der Abgabe des CSR eines ausgewählt wird.

Hier finden Sie zu den Profilen, was dahintersteckt. Sie sollten sich erst dann mit solchen Details vertraut machen, wenn die Standardvorgaben für Sie nicht passen. In diesem Fall ist es nicht sinnvoll, den CSR sehr individuell zu gestalten – der wird eh wieder normiert. Teilen Sie Ihre Anforderung einfach der Registrierungsstelle mit, die sich dann darum kümmert.

Es gibt folgende Profile:

keyUsage (critical) extendedKeyUsage
non
Repudia
tion
digital
Signature
key
Encipher
ment
data
Encipher
ment
client
Auth
server
Auth
code
Signing
email
Protec
tion
microsoft
Smartcard
Logon
Web Server X X X X   X      
LDAP Server X X X   X X      
Mail Server X X X   X X      
Radius Server X X X   X X      
Shibboleth IdP SP X X X   X X      
VPN Server X X X            
Domain Controller   X X   X X      
802.1X User   X X   X     X  
User X X X   X     X X
Code Signing X X X   X   X X X
RA Operator X X X   X     X