Bei normalen Webservern ist es zwingend notwendig, dass die Zertifikate auf Wurzelzertfikate zurückführbar sind, die in den Webbrowsern durch die Hersteller eingepflanzt sind (Browser verankert). Ohne solche Zertifikate zeigen die Webbrowser dem Nutzer eine Zertifikatswarnung. Das Browser Forum gibt vor, welche Anforderungen die Zertifikate für Webserver und die ausstellenden PKIs erfüllen müssen, damit die Wurzelzertifikate in den Zertifikats-Speichern der Webbrowser aufgenommen werden dürfen. Die Anforderungen werden immer weiter verschärft, so dürfen Webserver-Zertifikate zur Zeit nur eine Laufzeit von 13 Monaten haben.

Es gibt sehr viele Anwendungsfälle für Zertifikate bei denen die strengen Anforderungen des Browser Forums wenig hilfreich sind und für die Zertifikate in einer PKI nützlich sind, die weitere Möglichkeiten zulässt.

Eine dieser PKIs ist die vom DFN-PKI-Team bereitgestellte DFN Community PKI. Diese PKI wird an der TUHH u.a. für die Zertifikate bei den Shibboleth IdP und SPs verwendet, weil eine Laufzeit bis 39 Monate möglich ist.

Ablauf im Überblick

Beachten Sie bitte, dass sich die Zertifikate der DFN Community PKI nicht für normale Webserver eignen, weil die Webbrowser das Wurzelzertifikat nicht kennen. Wenn man diese Zertifikate so nutzen möchte, muss jeder Nutzer das Wurzelzertifkat importieren. Für diesen Anwendungsfall raten wir von der Nutzung ab!

Zertifikate in der DFN Community PKI können von den uns bekannten, zuständigen Administratoren der Institute und Einrichtungen (den Organisationseinheiten) formlos beantragt werden. Dazu benötigen Sie

• Empfehlung: eine funktionsfähige Installation von OpenSSL  und erzeugen den digitalen PKCS#10-Zertifikatsantrag im PEM-Format manuell
• Oder: Sie erzeugen den Antrag komplett im Browser

Beim manuellen Weg über OpenSSL gibt es mehr Freiheitsgrade und das Ergebnis ist einfacher zu kontrollieren und bei Bedarf auch zu automatisieren

Mit diesen Informationen erstellen Sie einen elektronische Antrag im Portal der DFN Community PKI und melden sich bitte über servicedesk(at)tuhh(dot)de beim Rechenzentrum.

Der genaue Ablauf wird im Nachfolgenden beschrieben.

Empfehlung: PKCS#10-Zertifikatsantrag manuell erzeugen

Für die manuelle Erzeugung einen PKCS#10-Zertifikatsantrages benötigen Sie eine funktionsfähige OpenSSL-Installation. OpenSSL wird als fertiges Pakete bei den meisten Linux-Distributionen mitgeliefert. Sofern Sie auf ein Windows Betriebssystem angewiesen sind, gibt es auch ein Windows Installationspaket. OpenSSL ist ein Werkzeugkasten mit verschiedenen Programmen u.a. zur Verarbeitung und Erzeugung von elektronischen Zertifikatsanträgen und Zertifikaten. Alle OpenSSL-Programme sind Kommandozeilen orientiert, d.h. es gibt keine grafische Oberfläche. Sie benötigen also auch unter Windows ein Kommandozeilen-Fenster.

Der elektronische Zertifikatsantrag, (engl. Certificate Signing Request, CSR), enthält folgende Informationen:

• Eine Zeichenkette, den so genannten Distinguished Name (DN), der den Server eindeutig identifiziert und einer Organisationseinheit der TUHH zuordnet. Beispiel: C="DE", "ST=Hamburg", "L=Hamburg", "O="Technische Universitaet Hamburg", CN="xyz.tuhh.de"
• Die TUHH kann nur Zertifikate mit C="DE", "ST=Hamburg", "L=Hamburg", O="Technische Universitaet Hamburg" ausstellen.
• CN ist der Common Name, d.h. für einen Server der vollständige DNS-Name (Fully Qualified Domain Name, FQDN). Die TUHH kann nur Zertfikate ausstellen für DNS Domains, die durch das Rechenzentrum betrieben werden.
• Den öffentlichen Schlüssel eines von Ihnen persönlich erzeugten Schlüsselpaares.

Die inhaltliche Struktur für diesen elektronische Zertifikatsantrag ist als PKCS#10 genormt. Es gibt dann zwei Alternativen für das Dateiformat, nämlich ein binäres Format (DER) oder ein druckbares Format PEM. Im druckbaren PEM-Format lassen sich die Dateien in einem Editor ansehen und einfach per Mail versenden.

Wählen Sie zum Erzeugen des Zertifikatsantrages einen vertrauenswürdigen Computer, denn dabei wird ein Schlüsselpaar aus einem geheimen (private key) und einem öffentlichen (public key) Schlüssel erzeugt. Der geheime Schlüssel darf nicht in falsche Hände geraten!

Mit OpenSSL erzeugen Sie den Zertifikatsantrag mit nachfolgendem Befehl. Dabei muss der gesamte Befehl in einer Zeile stehen. Für die Übersichtlichkeit sind hier Zeilenumbrüche eingefügt. Am besten legen Sie sich eine Kommandodatei (Shell-Script, CMD/BAT-Datei) mit dem Befehl an (falls Sie sich vertippen).

Zur Erklärung (siehe auch req man page): es bedeuten

• openssl req ruft den Unterbefehl req auf, der zur Erzeugung und Verarbeitung von Zertifikatsanträgen verwendet wird.
• -batch bewirkt das Ausführen im nicht-interaktiven Modus.
• -sha256 gibt die SHA-2 (256bit) Prüfsumme (fingerprint) des Zertifikatsantrags aus.
• -newkey rsa:4096 erzeugt ein neues Schlüsselpaar mit 4096 bit Länge nach dem RSA-Verfahren.
• -passout pass:geheim sorgt dafür, dass der geheime Schlüssel mit dem Passwort geheim verschlüsselt wird. Bitte wählen Sie hier ein anderes, besseres Passwort. Allerdings hängt es später von der Konfiguration des Servers ab, ob der geheime Schlüssel verschlüsselt bleiben kann. Wenn der geheime Schlüssel verschlüsselt vorliegt, dann kann der Server ohne manuelle Eingabe dieses Passwortes nicht mehr starten. Beim Neustart müsste also immer dieses Passwort eingegeben werden.
• -keyout private_key_enc.pem speichert den geheimen Schlüssel (private key) verschlüsselt in der Datei mit Namen private_key.pem. Passen Sie gut auf diesen Schlüssel auf, denn Sie dürfen Ihn weder verlieren noch darf der Schlüssel in falsche Hände gelangen.
• -out csr.pem legt den neuen Zertifikatsantrag PKCS#10 in der Datei csr.pem im PEM-Format ab.
• -subj "/C=DE/ST=Hamburg/L=Hamburg/O=Techn…" gibt den Distinguished Name für den Server an. FQDN-Hostname ist der vollständige Domainname des Servers (z.B. xyz.tu-harburg.de). Ein Zertifikat kann auch für verschiedene FQDNs ausgestellt werden. Dafür muß aber tiefer in die OpenSSL-Trickkiste gegriffen werden. Melden Sie sich bei Bedarf dazu im RZ.

Falls Sie schon einen Schlüsselpaar besitzen, z.B. weil Sie das Zertifikat erneuern möchten, geben Sie ein:

• -new erzeugt einen neuen Zertifikatsantrag
• -sha256 gibt die SHA-2 (256bit) Prüfsumme (fingerprint) des Zertifikatsantrags aus
• -key xyz.tu-harburg.de.key gibt den Dateinamen (z.B. xyz.tu-harburg.de.key) mit dem vorhandenen Schüsselpaar an
• -out xyz.tu-harburg.de.csr legt den neuen Zertifikatsantrag in der Datei xyz.tu-harburg.de.csr im PEM-Format ab.
• -subj "/C=DE/O=Techn…" gibt den Distinguished Name für den Server an. FQDN-Hostname ist der vollständige Domainname des Servers (z.B. xyz.tu-harburg.de).

Wenn Sie den Zertifikatsantrag nochmal überprüfen möchten, können Sie sich den Zertifikatsantrag im Klartext anschauen mit dem Befehl:

Zertifikat über Portal DFN Community beantragen

Das Portal für die DFN Community PKI erreichen Sie über

Wenn Sie manuell wie oben beschrieben einen PKCS#10-Antrag erzeugt haben, dann wählen Sie auf der Portal-Seite die Punkt Eigene CSR-Datei (PKCS#10) einreichen  aus und folgen den Anweisungen.

Alternativ können Sie auch über Serverzertifikat (inkl. Schlüsselerzeugung)  das Schlüsselpaar im Browser erzeugen und den Antrag stellen. Dabei wir eine Datei mit dem Schlüsselpaar erzeugt, die Sie speichern und auf die Sie gut aufpassen müssen.

Beachten wählen Sie auch das für Ihren Anwendungsfall passende Zertifikatsprofil. Bei Shibboleth SPs/IdPs wählen Sie das Profil Shibboleth IdP SP aus.

Wurzelzertifikat und Issuing CA

Die DFN Community PKI hat eine dreistufige Zertifikatskette und das Wurzelzertifikat und die Issuing CA finden Sie unter: https://doku.tid.dfn.de/de:dfnpki:dfnpki_root_certs#dfn-verein_community_pki

Information an das Rechenzentrum

Damit das Rechenzentrum den Antrag prüfen und das Zertfikat ausstellen kann, benötigen wir vom Antragssteller eine Information. Schreiben Sie dazu bitte eine Mail an servicedesk(at)tuhh(dot)de  und teilen Sie uns den geplanten Verwendungszweck mit.