Serverzertifikate

Serverzertifikate

Die Hochschule für Technik und Wirtschaft Dresden bietet als Teilnehmer an der Public-Key-Infrastruktur des Deutschen Forschungsnetzes (DFN-PKI) Serverzertifikate nach X.509-Standard an. Dies ermöglicht Serverbetreibern an der Hochschule, Serverdienste TLS-verschlüsselt (z.B. Webseiten über HTTPS) anzubieten. Da das Wurzelzertifikat der DFN-PKI in Clientgeräten hinterlegt ist, werden die verschlüsselten Verbindungen von den üblichen Clients automatisch als sicher und vertrauenswürdig eingestuft.

Serverzertifikate mit OpenSSL beantragen

Hier ist das Vorgehen beschrieben, wie Sie ein x.509-Serverzertifikat mittels OpenSSL erstellen können. OpenSSL ist üblicherweise auf jedem Linux-Betriebsystem verfügbar (evtl. muss das entsprechende Paket installiert werden) und kann auch für Windows bezogen werden.

Als Ergänzung zu dieser Anleitung sei auch auf die OpenSSL-Anleitung des DFN verwiesen.

Vorab sei darauf hingewiesen, dass Sie für das Erstellen eines Serverzertifikates die "Informationen für Zertifikatinhaber in der DFN-PKI" lesen und selbigen zustimmen müssen. Kurz nachdem der unterschriebene Zertifikatsantrag (siehe Schritt 2) beim Rechenzentrum bearbeitet wurde (Hauspost oder direkt abgeben), erhalten Sie das Serverzertifikat direkt vom DFN per Mail.

1. Schritt: Privaten Schlüssel und CSR erstellen

Folgendermaßen erstellen Sie mit OpenSSL einen neuen privaten Schlüssel und gleichzeitig die benötigte CSR-Datei ("Certificate Signing Request"). Passen Sie den Befehl zumindest bezüglich Servernamen und OU (Fakultät/Dezernat anpassen) an:

  • openssl req -newkey rsa:4096 -sha256 -keyout mailserver.htw-dresden.de-key.pem -out mailserver.htw-dresden.de-csr.pem -subj "/C=DE/ST=Sachsen/L=Dresden/O=Hochschule fuer Technik und Wirtschaft Dresden/OU=Rechenzentrum/CN=mailserver.htw-dresden.de"

Es empfiehlt sich jedoch, den Befehl zu erweitern und in der CSR-Datei den Servernamen (und evtl. weitere benötigte alternative Hostnamen) ebenfalls als "Subject Alternative Names" (SANs) einzubauen (siehe auch Blogeintrag dazu vom DFN bzw. diesen Hilfe-Artikel zu Google Chrome). Das nachfolgende Beispiel funktioniert so nur in der Bash-Shell und benötigt die OpenSSL-Konfigurationsdatei unter /etc/ssl/openssl.cnf. In dem Beispiel wurden die Hostnamen mailserver.htw-dresden.de (was auch der CN ist), mail.htw-dresden.de und webmail.htw-dresden.de als SANs erweitert:

  • openssl req -newkey rsa:4096 -sha256 -keyout mailserver.htw-dresden.de-key.pem -out mailserver.htw-dresden.de-csr.pem -subj "/C=DE/ST=Sachsen/L=Dresden/O=Hochschule fuer Technik und Wirtschaft Dresden/OU=Rechenzentrum/CN=mailserver.htw-dresden.de" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:mailserver.htw-dresden.de,DNS:mail.htw-dresden.de,DNS:webmail.htw-dresden.de"))

Nach der Eingabe dieses Befehls fragt OpenSSL nach einem Passwort, mit welchem die neue Datei mit dem privaten Schlüssel (im Beispiel mailserver.htw-dresden.de-key.pem) geschützt wird. Außerdem erhalten Sie laut Beispiel die Datei mailserver.htw-dresden.de-csr.pem - die im nächsten Schritt notwendige CSR-Datei.

2. Schritt: Beantragen eines Zertifikates über Webschnittstelle

Besuchen Sie mit einem Browser das DFN-PKI-Portal (DFN-PKI 2. Generation)

und wählen dort "Serverzertifikat". Klicken Sie auf "Durchsuchen..." und wählen die csr.pem-Datei aus dem vorherigen Schritt. Vergewissern Sie sich, dass Sie wirklich die csr.pem-Datei, und nicht den privaten Schlüssel auswählen. Bei dem Auswahlbutton "Zertifikatsprofil" wählen Sie das Profil, dass Ihre Serveranwendung entspricht. Üblicherweise dürfte das "Web Server" sein. Füllen Sie die weiteren Punkte aus.

Vergeben Sie eine PIN, welche sicher verwahrt werden sollte. Diese wird benötigt, wenn Sie das Zertifikat vor seiner Ablaufzeit sperren wollen, z.B. weil der private Schlüssel unberechtigten Personen in die Hände gekommen sein könnte.

Bestätigen Sie, die "Informationen für Zertifikatinhaber" gelesen zu haben. Der Veröffentlichung des Serverzertifikates brauchen Sie nicht zustimmen, da dies nur bei Nutzerzertifikaten relevant ist.

Klicken Sie dann auf "Weiter". Wenn alles korrekt ist, können Sie die Zertifikatsdaten als nächstes einsehen und mit einem Klick auf "Bestätigen" absenden. Im letzten Fenster erhalten Sie die Antragsdatei als PDF, welche Sie ausfüllen und dem Rechenzentrum ausgedruckt und unterschrieben übergeben müssen (direkt oder über die Hauspost).

3. Schritt: Einbinden des Zertifikates in den Serverdienst

Kurz nachdem der Zertifikatsantrag vom Rechenzentrum bestätigt wurde, erhalten Sie direkt vom DFN die Zertifikatsdatei an die von Ihnen angegebene E-Mail-Adresse.

Dieses Zertifikat müssen Sie jetzt zusammen mit dem privaten Schlüssel (im Beispiel die Datei "mailserver.htw-dresden.de-key.pem") in Ihren Serverdienst einbinden. Konsultieren Sie dafür bitte die Anleitung Ihres Serverdienstes.

1. Hinweis: Passwortschutz des privaten Schlüssels

Zu beachten ist, dass die Datei mit dem privaten Schlüssel selbst noch mit dem bei Schritt 1 von OpenSSL abgefragten Passwort geschützt ist. Bei einigen Serverdiensten ist es möglich, dieses Passwort beim Starten des Dienstes einzugeben (sehr sicher aber unpraktisch, da so kein unbeaufsichtigter Dienststart möglich ist) bzw. es in der Serverkonfiguration zu hinterlegen (bitte dafür die Anleitung befragen). Ansonsten kann mit OpenSSL folgendermaßen auch der Passwortschutz von der Datei entfernt werden:

  • openssl rsa -in mailserver.htw-dresden.de-key.pem  -out mailserver.htw-dresden.de-key_unprotected.pem

Bei unverschlüsselter Passwortdatei oder dem Angeben des Schutz-Passworts in der Konfigurationsdatei des Serverdienstes gibt es keinen zusätzlichen Schutz mehr gegen das Abgreifen des privaten Schlüssels. Der entsprechende Server muss also stets im besonderen Maß vor Zugriffen  diesbezüglich geschützt sein (Zugriff nur durch berechtigte Personen, Installation von Updates, minimale Anzahl an laufenden Diensten, ...).

2. Hinweis: Dateiformate

Nach dieser Anleitung liegen privater Schlüssel und Zertifikate PEM-Codiert vor, was von den meisten Serverdiensten direkt verwendet werden kann. Überprüfen Sie in der Dokumentation Ihrer Serversoftware, welche Zertifikatsformate unterstützt werden. Sollte doch eine Konvertierung notwendig sein, kann diese bei einigen Formaten direkt mit OpenSSL durchgeführt werden (siehe z.B. diesen Artikel).

3. Hinweis: Zertifikatskette korrekt ausliefern

Bei verschlüsselten Verbindungen mit dem TLS-Standard sollte stets vom Serverdienst die korrekte Zertifikatskette mit ausgeliefert werden. Dies hilft dem Client, die Kette der Vertrauensstellung aufzubauen und kann so einige Probleme vermeiden.

Eine vollständige Kette nach 2. Generation der DFN-PKI enthält

  1. Das neu erstellte Zertifikat des Servers,
  2. Zwischenzertifikat "DFN-Verein Global Issuing CA",
  3. Zwischenzertifikat "DFN-Verein Certification Authority 2".

Das Stammzertifikat "T-TeleSec GlobalRoot Class 2" braucht nicht mit in der Kette ausgeliefert zu werden, da es den Clients ja bereits als vertrauenswürdig bekannt ist.

Abhängig von Ihrer Serversoftware kann eine Zertifikatskette oft separat angegeben werden. In diesem Fall können Sie diese vorbereitete Datei verwenden:

Bei anderen Serverdiensten ist es evtl. notwendig, Serverzertifikat und Zwischenzertifikate in einer gemeinsamen Datei vorzuhalten. Kopieren Sie in diesem Fall das vom DFN erhaltene Serverzertifikat an den Anfang der verlinkten Kettendatei und verwenden die resultierende Datei.

4. Hinweis: Dienste ausschließlich verschlüsselt anbieten

Mit dem Aktivieren der TLS-Verschlüsselung wird üblicherweise ein Dienst gleichzeitig verschlüsselt und unverschlüsselt ausgeliefert. Oft ist es sowohl der Sicherheit und der Einfachheit zuträglich, einen Dienst dann nur noch verschlüsselt auszuliefern. Prüfen Sie für Ihren Anwendungsfall am besten, ob dies möglich ist.

Bei HTTP ist es üblich, vom unverschlüsselten Dienst auf Port 80 ausschließlich Weiterleitungen auf den verschlüsselten HTTPS-Port 443 ausliefern zu lassen (siehe z.B. Konfigurationsbeispiel für Apache).

5. Hinweis: Serverkonfiguration prüfen lassen

Nutzen Sie den automatisierten Test von Qualys SSL Labs, um die TLS-Konfiguration einer HTTPS-Seite auf bekannte Fehler oder Schwachstellen zu überprüfen. Bei Nicht-HTTPS-Diensten und nicht aus dem Internet erreichbare Dienste lässt sich ein ähnlicher Test mit testssl.sh durchführen.

Es empfiehlt sich, diese Tests auch bei Diensten im Produktivbetrieb regelmäßig zu wiederholen. So kann mit recht wenig Aufwand ermittelt werden, ob die Verschlüsselung noch "State of the art" ist.

Serverzertifikate verlängern

Jedes Serverzertifikat hat eine begrenze Gültigkeitsdauer, nach deren Überschreiten Clients keine verschlüsselten Verbindungen mehr zu dem Server zulassen. Das Start- und Ablaufdatum kann mit OpenSSL z.B. folgendermaßen angezeigt werden (siehe Attribute "Not Before" und "Not After"):

  • openssl x509 -noout -text -in certificat.pem

Jeder Zertifikatseigentümer ist eigenverantwortlich dafür, vor dem Erreichen des Ablaufdatums seine Zertifikate zu erneuern.

Für die Erneuerung eines Serverzertifikates gehen Sie hier beschrieben vor. Achten Sie darauf, den gleichen Servernamen ("Common Name", abgekürzt CN) und, falls verwendet, die gleichen "Subject Alternative Names" (abgekürzt SANs) wie im alten Zertifikat anzugeben. Es wird wie gehabt ein neues Schlüsselpaar (öffentlicher + privater Schlüssel) generiert und das Zertifikat aus dem öffentliche Schlüssel mittels "Certificate Signing Request" (abgekürzt CSR) vom DFN ausgestellt.

Es wäre zwar auch möglich, das bereits verwendete alte Schlüsselpaar weiter zu nutzen - das ist jedoch komplizierter und bringt keine Vorteile.

Wenn Sie das Serverzertifikat vom DFN erhalten habe, konfigurieren Sie alle entsprechenden Serverdienste so um, dass diese das neue Serverzertifikat und den neuen privaten Schlüssel verwenden.

Für die Nutzer/Clients des Servers verläuft der Wechsel bei korrektem Vorgehen ohne merklichen Unterschied im Hintergrund ab.

Weitere Informationen