Server mit TLS absichern

Wenn Sie verantwortlich für den Betrieb eines Servers im von der Zertifizierungsstelle (CA) der Universität Münster versorgten Bereich betreiben, dann können Sie ein Server-Zertifikat beantragen und damit den Nutzenden Ihres Servers ermöglichen, sichere Verbindungen zum Server aufzubauen.

Als verantwortlich zählt, wer in der zentralen Rechnerdatenbank der Universität Münster den Eintrag für diesen Server bearbeiten darf.

Es gibt verschiedene Wege, sich ein Schlüsselpaar zu erzeugen und den Antrag an die CA zu übermitteln:

  1. Per ACME wie nachfolgend beschrieben.

    Falls Ihr Server Zertifikate per ACME automatisch abrufen kann, nutzen Sie bitte unbedingt diesen Weg, da die regelmäßig notwendige Aktualisierung des Zertifikats dann vollautomatisch stattfinden kann.

    Und selbst wenn Ihre Server-Software kein ACME unterstützt, können und sollten Sie sich mit ACME die regelmäßig notwendige Aktualisierung des Zertifikats deutlich vereinfachen.

  2. Mit dem IT-Portal (Anmeldung mit persönlicher digitaler ID erforderlich).

    Falls Ihr Server keine Zertifikate per ACME automatisch abrufen kann und falls auch keine andere Möglichkeit zur Teilautomatisierung mit ACME besteht, können Sie alternativ auf diesem Weg einzelne Serverzertifikate erhalten. (Dieser Weg bedarf sicherlich keiner detaillierten Anleitung.)

Wie Sie das ausgestellte Zertifikat am besten nutzen, wird unten am Beispiel des verbreiteten Webservers Apache gezeigt.

Server-Zertifikate via ACME verwalten

ACME steht für Automatic Certificate Management Environment und beschreibt eine Methode, mit der digitale IDs (Zertifikate) teil- oder vollautomatisch regelmäßig erneuert werden können.

Angesichts der immer kürzer werdenden maximalen Gültigkeitsdauern von Serverzertifikaten ist die Verwendung dieser Methode dringendst zu empfehlen.

  • ACME-IDs einrichten und verwalten

    Bei den von GÉANT TCS in unserem Auftrag ausgestellten Zertifikaten erfolgt die Validierung mit External Account Binding (EAB).

    Zur Nutzung von ACME mit EAB wird eine ACME-ID benötigt. Jede ACME-ID wird nach dem FQDN eines Servers benannt. Mit einer ACME-ID können Zertifikate für den namensgebenden FQDN und für beliebig viele weitere FQDNs verwaltet werden. Für welche weiteren FQDNs eine ACME-ID Zertifikate verwalten darf, kann im IT-Portal eingestellt und jederzeit auch geändert werden.

    Ein FQDN kann auch bei mehreren ACME-IDs eingetragen werden, aber nur eine ACME-ID kann den FQDN als Namen tragen. Wenn der namensgebende FQDN aus der zentralen Rechnerdatenbank abgemeldet wird, wird auch die ACME-ID ungültig.

    Wer verantwortlich für den Betrieb eines Servers ist, der kann ACME-IDs mit dem FQDN des Servers im IT-Portal einrichten und verwalten. Vorhandene ACME-IDs können von allen Verantwortlichen für den jeweiligen FQDN bearbeitet werden.

    Es empfiehlt sich, für Gruppen von FQDNs, die vom gleichen Personenkreis betreut werden, jeweils nur eine gemeinsame ACME-ID einzurichten.

    Die Verwaltung der ACME-IDs finden Sie im IT-Portal unter „Digitale ID (Zertifikat)“.

    Bitte beachten Sie die ausführlichen Hinweise im IT-Portal.

    Beim Einrichten einer ACME-ID erhalten Sie eine EAB-Key-ID, einen EAB-HMAC-Key und die URL des Zertifikatservers. Sie müssen dann Ihre ACME-fähige Software veranlassen, sich mit diesen Schlüsseldaten beim Zertifikatserver zu registrieren.

    Bei dieser Registrierung wird zwischen Ihrer ACME-fähigen Software und dem Zertifikatserver Schlüsselmaterial ausgetauscht, mit dem die Software dann die gewünschten Zertifikate beantragen und abholen kann.

    Die nachfolgende Anleitung beschreibt die notwendigen Schritte mit der Software CertBot. Diese Software kann gleichzeitig Zertifikate von verschiedenen Zertifizierungsstellen verwalten, beispielsweise von unserem Partner GÉANT TCS und von Let's Encrypt.

    Kurze Hinweise zu Alternativen finden Sie ganz unten.

  • Starten des CertBot-Daemons

    Die CertBot-Software muss installiert und regelmäßig automatisch aufgerufen werden, damit er bald auslaufende Zertifikate erneuern kann. Das hängt von Ihrer Betriebssystem-Variante ab und könnte etwa so aussehen:

    yum install certbot

    systemctl enable certbot-renew.timer
    systemctl start certbot-renew.timer

    Es ist nicht nötig, den CertBot-Dienst ausfallsicher zu gestalten. Im Regelfall werden Zertifikate 30 Tage vor Ablauf erneuert. Bei Ausfall des Dienstes haben Sie also vier Wochen Zeit, das Problem zu entdecken und zu beheben.

  • Registrierung einer im IT-Portal eingerichteten ACME-ID

    Um den lokalen CertBot-Dienst beim ACME-Dienst zu registrieren, muss einmalig folgender Befehl eingegeben werden. Dieser enthält die URL des Zertifikatservers, EAB-Key-ID und EAB-HMAC-Key für das External Account Binding und die E-Mail-Adresse, die bei Problemen informiert werden soll:

    certbot register --server 'server-url' --eab-kid 'key-id' --eab-hmac-key 'hmac-key' --email 'mailaddress' --agree-tos --no-eff-email

    Dabei bedeuten:

    • server-url = die vom IT-Portal ausgegebene URL des Zertifikatservers

    • key-id = die vom IT-Portal ausgegebene (kürzere) EAB-Key-ID

    • hmac-key = der vom IT-Portal ausgegebene (längere) EAB-HMAC-Key

    • mailaddress = die E-Mail-Adresse, an die der CertBot seine Informationen sendet

    Wenn eine ACME-ID auf mehreren Servern eingesetzt werden soll, kann das CertBot-Verzeichnis /etc/letsencrypt auf die weiteren Server kopiert werden.

  • Beantragen eines ersten Zertifikats für einen oder mehrere FQDNs

    Um dann tatsächlich ein Zertifikat per ACME zu beantragen, abzuholen, zu installieren, den zertifizierten Service neu zu starten und die regelmäßig automatische Wiederholung des ganzen Vorgangs auszulösen, dient im allgemeinen Fall folgender Befehl:

    certbot certonly --standalone --agree-tos --server 'server-url' --cert-name 'certname' --domain fqdn1,fqdn2,... --email='mailaddress' --deploy-hook '/pfad/zu/script arg ...'

    Dabei bedeuten:

    • server-url = die vom IT-Portal ausgegebene URL des Zertifikatservers

    • certname = der frei wählbare Dateiname (ohne Pfad) des Zertifikats (beispielsweise der Haupt-FQDN des Servers, für den das Zertifikat bestimmt ist)

    • fqdn1,fqdn2,... = die vollqualifizierten Rechnernamen (FQDNs), unter denen der Dienst auftritt; diese FQDNs müssen im IT-Portal für die ACME-ID angegeben worden sein; der zuerst angegebene FQDN wird auch in das Subject des Zertifikats aufgenommen, die anderen nur in die Subject Alternative Names

    • mailaddress = die E-Mail-Adresse, an die der CertBot seine Informationen für diesen Server sendet

    • /pfad/zu/script arg ... = der absolute Pfad, optional mit Argumenten, eines (ggf. selbst geschriebenen) Kommandos, welches nach jedem Abruf neuer Zertifikate aufgerufen wird und

      • im besten Fall die neuen Dateien aus dem Verzeichnis /etc/letsencrypt/live/certname/ an die richtige Stelle kopiert und dann den Server neu startet

      • oder sonst zumindest jemanden informiert, dass neue Zertifikate fertig sind.

      Dieses Skript kann in den Umgebungsvariablen RENEWED_LINEAGE und RENEWED_DOMAINS nachschauen, für welches Zertifikat und welche Domains es aufgerufen wurde. Man kann also dasselbe Skript für verschiedene Server verwenden.

      Ein für die Option --deploy-hook '/usr/local/bin/newcert mailaddress' passendes und für beliebig viele Server verwendbares Shellskript zum Senden einer E-Mail wäre:

      #!/bin/sh
      echo "Siehe $RENEWED_LINEAGE" |
      /usr/bin/mailx -s "Neues Zertifikat fuer $RENEWED_DOMAINS" "$1"

    Dieser Befehl kann in vielerlei Hinsicht modifiziert und an die eigenen Gegebenheiten angepasst werden. Beachten Sie dazu bitte die Beschreibung der bei Ihnen verfügbaren Version der CertBot-Software.

    Insbesondere gibt es Plugins für Apache und Nginx, welche die automatische Installation in lokale Webserver auch ohne Deploy-Hook-Skript erlauben.

  • Zertifikaterneuerung erzwingen

    Um alle vom CertBot-Dienst verwalteten Zertifikate sofort vorzeitig zu aktualisieren, dient folgender Befehl:

    certbot renew --noninteractive --no-random-sleep-on-renew --force-renewal

  • Nutzung mit privaten IP-Adressen

    Damit der Zertifizierungsserver erreicht werden kann, sollte vor dem Absetzen von certbot-Kommandos der Proxy-Server eingestellt werden:

    http_proxy=http://wwwproxy.uni-muenster.de:3128
    https_proxy=http://wwwproxy.uni-muenster.de:3128
    export http_proxy https_proxy

    Damit der Timer-gesteuerte automatische Zertifikatabruf klappt, sollten im der Systemkonfigurationsdatei /etc/sysconfig/certbot folgende Zeilen ergänzt werden:

    http_proxy=http://wwwproxy.uni-muenster.de:3128
    https_proxy=http://wwwproxy.uni-muenster.de:3128

  • Mehrere Zertifikate mit einem CertBot

    Um mit derselben ACME-ID mehrere Zertifikate zu verwalten, wählt man bei den obigen Befehlen jeweils einen anderen certname und die jeweils gewünschte FQDNs fqdn1,fqdn2,...

    Die ACME-ID muss im IT-Portal für alle FQDNs in allen Zertifikaten freigeschaltet sein, aber es ist natürlich nicht nötig, in jedes Zertifikat alle FQDNs aufzunehmen.

    Bei Systemen, die sich zwar über mehrere Server erstrecken (Cluster, Hochverfügbarkeit, usw), die aber alle vom selben Personenkreis administriert werden, kann man den Verzeichnisbaum /etc/letsencrypt nach der Registrierung auf die anderen Server verteilen. Dann kann sich jeder beteiligte Server unter der gleichen ACME-ID seine Zertifikate besorgen.

    Falls Sie auch Server unter fremden Domains betreiben: Derselbe CertBot kann sogar auch noch verwendet werden, um Zertifikate von anderen Zertifizierungsstellen wie Let's Encrypt zu beziehen.

    Sobald aber unterschiedliche Personenkreise administrativen Zugriff auf die verschiedenen Server haben, sollten unbedingt getrennte ACME-IDs und getrennte CertBots eingesetzt werden.

  • Zugriffsberechtigungen auf die Zertifikatdateien

    CertBot legt die Zertifikatdateien, insbesondere den privaten Schlüssel, mit Zugriffsrechten nur für den root-User ab (0700). Wenn Anwendungen, die nicht als root, sondern unter einer anderen Kennung laufen, direkt auf die Dateien in /etc/letsencrypt/live/ zugreifen sollen, müssen die entsprechenden Leserechte gesetzt werden. Dies darf nicht mit chown, chgrp oder chmod geschehen, denn das wird vom CertBot geändert oder moniert.

    setfacl -R -m u:username:rX /etc/letsencrypt/{live,archive}/certname
    setfacl -m u:username:rX /etc/letsencrypt/{live,archive}
    setfacl -m d:u:username:rX /etc/letsencrypt/{live,archive}/certname

    Dabei bedeuten:

    • username = die Nutzerkennung, unter der der Server läuft

    • certname = der frei wählbare Dateiname (ohne Pfad) des Zertifikats

    Sie sollten unbedingt prüfen, ob die Kennung die erzeugten privaten Schlüssel tatsächlich lesen kann, beispielsweise mit:

    getfacl /etc/letsencrypt/archive/certname/priv*

    Notfalls muss die ACL-Maske in obigen Befehlen angepasst werden.

  • Deploy-Hook nachträglich einrichten oder ändern

    Wird beim erstmaligen Abrufen eines Zertifikats (certbot certonly --standalone ...) die Option --deploy-hook mitgegeben, so wird dieses Kommando/Script nach jedem Zertifikat-Austausch aufgerufen. Das bietet sich als einfacher Weg an, um Services automatisiert nach dem Zertifikatwechsel neuzustarten.

    War das nicht gewollt oder wurde das vergessen, gibt es diverse Alternativen, um die Service-Restarts mit CertBot zu realisieren:

    • in /etc/letsencrypt/renewal/certname.conf unter [renewalparams] nachträglich die Zeile
      renew_hook = /pfad/zu/script arg ...
      eintragen

    • einfach den Zertifikatsabruf mit --deploy-hook wiederholen; das erzeugt dann diese Zeile, erneuert allerdings auch gleich das Zertifikat

    • certbot renew --deploy-hook ... aufrufen, das wirkt dann aber auf alle Zertifikate und führt bei allen Zertifikaten zu diesem Eintrag

    • unter /etc/letsencrypt/renewal-hooks/deploy ein entsprechendes Script ablegen, auch das wirkt auf alle Zertifikate

    Letzteres bietet sich vor allem an, wenn man mehr machen will, statt nur ein einfaches Kommando abzusetzen. Allerdings akzeptiert --deploy-hook auch Pfade zu selbst geschriebenen Skripten.

    Wer noch mehr Kontrolle wünscht oder noch komplexere Start/Stop-Scripte benutzen möchte, der kann auch mit --pre-hook und --post-hook oder mit Skripten in /etc/letsencrypt/renewal-hooks/pre bzw. /etc/letsencrypt/renewal-hooks/post arbeiten, letztere wirken auf alle Zertifikate.

  • CertBot-Alternative: acme.sh

    Auf dem Server richtet man dann eine dedizierten Kennung ein (Name beliebig), in dessen HOME-Verzeichnis anschließend acme.sh installiert und verwendet wird wie folgt:

    adduser acmeuser

    su - acmeuser

    git clone https://github.com/acmesh-official/acme.sh.git

    cd ./acme.sh

    ./acme.sh --install -m e-mail-adresse

    exit

    Zum Einlesen der geänderten rc-Dateien wird die Kennung erneut eingeloggt, der Default-CA-Server wird gesetzt, der EAB-Account registriert (Nebenprodukt ACCOUNT_THUMBPRINT) und ein Zertifikat angefordert:

    su - acmeuser

    acme.sh --set-default-ca --server 'server-url'

    acme.sh --register-account --server 'server-url' --eab-kid 'key-id' --eab-hmac-key 'hmac-key'

    acme.sh --issue -d fqdn1 --stateless

    Im Default werden die Zertifikatsdateien dann im Unterordner ~/.acme.sh/fqdn1/ abgelegt und müssen noch an die von der Anwendung benötigte Stelle kopiert werden. Als acmeuser' kann man mit crontab -l den ggf. schon von acme.sh eingerichteten Renewal-Eintrag sehen und anpassen bzw. um ein Deployment ergänzen.

Digitale IDs im Webserver Apache verwenden

  • Konfiguration der digitalen ID

    Der Webserver Apache benötigt jeweils als PEM-Datei:

    1. den unverschlüsselten privaten Schlüssel in /pfad/zu/key.pem

    2. das Serverzertifikat in /pfad/zu/cert.pem

    3. die Zwischen-CA-Zertifikate in /pfad/zu/chain.pem

    Es darf sich um drei getrennte Dateien handeln oder auch um eine einzige Datei, die die Schlüssel und Zertifikate in dieser Reihenfolge enthält. Namen und Pfade dürfen frei gewählt werden.

    Die oben beschriebene CertBot-Software stellt diese drei Dateien im Verzeichnis /etc/letsencrypt/live/certname/ unter den Namen privkey.pem, cert.pem und chain.pem bereit.

    Mit folgenden Konfigurationsanweisungen geben Sie an, welche Dateien verwendet werden sollen:

    SSLCertificateKeyFile   /pfad/zu/key.pem
    SSLCertificateFile      /pfad/zu/cert.pem
    SSLCertificateChainFile /pfad/zu/chain.pem

    Falls Sie direkt die von der CertBot-Software bereit gestellten Dateien verwenden möchten, beachten Sie bitte oben den Abschnitt „Zugriffsberechtigungen auf die Zertifikatdateien“.

  • Dringend empfohlene weitere Einstellungen

    Unsichere SSL/TLS-Protokolle deaktivieren:

    SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

    Unsichere Verschlüsselungsverfahren deaktivieren und beste Methoden bevorzugen[1][3]:

    SSLHonorCipherOrder on
    SSLCipherSuite "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256"

    oder, noch etwas strenger[2][3], entsprechend den Empfehlungen des DFN-PKI-Teams:

    SSLHonorCipherOrder on
    SSLCipherSuite "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256"

    Obige Zeile SSLCipherSuite "..." wirkt nur auf Verbindungen mit TLS 1.2 (und älter, falls nicht deaktiviert).
    Verschlüsselungsverfahren für Verbindungen mit TLS 1.3 könnten bei Bedarf mit einer zusätzlichen Zeile SSLCipherSuite TLSv1.3 "..." angepasst werden.

    OCSP-Stapling aktivieren (den Pfad bitte wie bei SSLSessionCache wählen):

    SSLUseStapling on
    SSLStaplingReturnResponderErrors off
    SSLStaplingCache shmcb:/..../..../sslstaplingcache(512000)

    Fußnoten

    [1] ↑ Wie ein mehrtägiger Praxistest im Jahr 2021 im Webserverpark der Universität gezeigt hat, beherrschen sämtliche Clients, die TLS 1.2 unterstützen, mindestens eines dieser Verschlüsselungsverfahren, es wird also niemand ausgesperrt.

    [2] ↑ Wie ein mehrtätiger Praxistest im Jahr 2021 im Webserverpark der Universität gezeigt hat, betrifft diese Verschärfung nur 0,7 % aller Zugriffe, alle von veralteten Systemen mit bekannten Sicherheitsproblemen.

    [3] ↑ Apache verwendet die Namen in der OpenSSL-Schreibweise. Die Originalnamen lauten:
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA256