Serverzertifikate

Beantragen eines Serverzertifikats

Mit einem TLS-Zertifikat bestätigt eine vertrauenswürdige Zertifizierungsstelle (CA) die Identität Ihres Dienstes. Im Gegensatz zu selbstsignierten Zertifikaten ermöglicht dies den Nutzern, die Authentizität der aufgerufenen Domain zweifelsfrei zu überprüfen. Dadurch wird sichergestellt, dass die Kommunikation verschlüsselt abläuft und Angriffsvektoren wie Man-in-the-Middle-Angriffe effektiv verhindert werden. Da das Zertifikat von einer öffentlich vertrauten Stelle stammt, werden dem Besucher im Browser zudem keine Sicherheitswarnungen mehr angezeigt.

Im Rahmen der UNIWUE-CA können SSL-Server-Zertifikate nur für Server der Universität Würzburg erstellt werden. Der DNS-Name des Dienstes muss auf *.uni-wuerzburg.de enden.

Ein zentraler Aspekt bei der Nutzung von TLS-Zertifikaten ist deren Gültigkeitsdauer. Aus Sicherheitsgründen treiben das CA/Browser Forum und die großen Browserhersteller eine drastische Verkürzung der maximalen Zertifikatslaufzeiten voran. Während öffentliche TLS-Zertifikate bis vor kurzem noch eine maximale Gültigkeit von 398 Tagen (rund 13 Monaten) aufwiesen, wird dieser Zeitraum in einem stufenweisen Prozess erheblich reduziert:

Seit März 2026: Maximal 200 Tage

Ab März 2027: Maximal 100 Tage

Ab März 2029: Maximal 47 Tage

Ziel dieser Verkürzung ist es, die Sicherheit im Internet zu erhöhen: Kompromittierte Schlüssel werden schneller unbrauchbar und neue kryptografische Standards lassen sich zügiger durchsetzen.

Diese Entwicklung bedeutet jedoch, dass eine manuelle Beantragung und Einbindung von Zertifikaten künftig schlichtweg nicht mehr praktikabel ist. Als Serverbetreiber haben Sie daher die Möglichkeit, die Ausstellung und Verlängerung von TLS-Zertifikaten über das ACME-Protokoll (Automated Certificate Management Environment) vollständig zu automatisieren. Dabei prüft die CA, ob der Anfragende die Kontrolle über die Hostnamen hat, die in das Zertifikat aufgenommen werden sollen. Um dies zweifelsfrei nachzuweisen wird im Rahmen des ACME-Prozesses die sogenannte HTTP-01 Challenge verwendet. Hierbei platziert der lokale ACME-Client für jeden Hostnamen einen temporären Token auf dem Webserver, welcher einen von der Zertifizierungsstelle vorgegebenen, zufälligen Wert enthält und anschließend von der Zertifizierungsstelle über eine unverschlüsselte HTTP-Verbindung (Port 80) abgerufen und verifiziert wird. Sobald die HTTP-01 Challenge erfolgreich durchlaufen wurde, stellt die Zertifizierungsstelle das Zertifikat aus, woraufhin der ACME-Client dieses automatisch auf dem Server hinterlegen und einbinden kann.

Es gibt verschiedene Szenarien, in denen es nicht möglich ist, einen ACME-Client und die HTTP-01 Challenge zu benutzen: 

• Interne Server die nicht per HTTP (Port 80) aus dem Internet erreichbar sind und bei denen es nicht möglich ist der CA Zugriff auf Port 80 zu erlauben
• Systeme mit Wildcard DNS Einträgen und Wildcard-Zertifikaten
• Server/kommerzielle Appliances, die kein ACME unterstützen oder nur bestimmte Anbieter unterstützen
• Cluster-Setups, bei denen nicht garantiert werden kann, dass die ACME-Challenge von dem Server bearbeitet wird, auf dem der ACME-Client läuft

Sollte dies bei Ihrem Use-Case der Fall sein, melden Sie sich bitte per Mail unter ca@uni-wuerzburg.de bei uns.

Schritte zum Serverzertifikat:

2. Beantragen des Zertifikats mit ACME

Zum Beantragen eines Zertifikats per ACME benötigen Sie einen ACME-Client. Dieser muss auf dem Server installiert sein, der das Zertifikat letztendlich nutzen soll.

Der bekannteste und am weitesten verbreitete ACME-Client ist Certbot, entwickelt von der Electronic Frontier Foundation (EFF). Detaillierte, maßgeschneiderte Installationsanleitungen für jede Kombination aus Betriebssystem und Webserver (Apache, Nginx etc.) finden Sie in den "certbot instructions" der EFF.

Bevor die Zertifikatsanforderung ausgeführt werden kann, müssen drei Voraussetzungen zwingend erfüllt sein:

1. Alle im Zertifikat enthaltenen Hostnamen müssen per DNS auf die öffentliche IP-Adresse dieses Servers zeigen.
2. Eine Firewallfreigabe für Port 80 (HTTP) muss bereits eingerichtet worden sein, da die Zertifizierungsstelle (CA) hierüber die HTTP-01 Challenge validiert.
3. Sie haben im Portal der CA (HARICA) den Key Identifier (KID) sowie den HMAC Key generiert und die ACME-Directory-URL liegt Ihnen vor.

Wenn auf dem Server bereits ein Webserver läuft (z.B. Apache oder Nginx) und Port 80 in Verwendung ist, empfiehlt sich die Nutzung des Webroot-Plugins. Certbot legt dabei die Challenge-Datei in das bestehende Verzeichnis der Website, ohne dass der Webserver gestoppt werden muss.

Wichtig bei automatischer HTTPS-Umleitung: Leitet Ihr Webserver bereits sämtlichen HTTP-Verkehr auf Port 80 pauschal auf HTTPS (Port 443) um, sollte der Pfad /.well-known/acme-challenge/ davon ausgenommen werden. Die Zertifizierungsstelle folgt zwar Redirects von HTTP auf HTTPS, allerdings kann die Validierung fehlschlagen, wenn das bestehende Zertifikat z.B. bereits abgelaufen ist. Am zuverlässigsten ist es daher, die Challenge-Anfragen direkt auf Port 80 zu beantworten.

Führen Sie folgenden Befehl aus und ersetzen Sie die Platzhalter durch Ihre spezifischen Daten:

sudo certbot certonly \
  --webroot -w /var/www/html \
  -d ihrserver.uni-wuerzburg.de -d www.ihrserver.uni-wuerzburg.de \
  --server " https://acme-v02.harica.gr/acme/IHR_ALIAS/directory" \
  --eab-kid "IHR_EAB_KEY_IDENTIFIER" \
  --eab-hmac-key "IHR_EAB_HMAC_KEY" \
  --agree-tos \
  -m vorname.nachname@uni-wuerzburg.de

Erläuterung der Parameter:

• certonly weist Certbot an, das Zertifikat nur herunterzuladen, aber noch nicht automatisch in die Webserver-Konfiguration einzutragen.
• --webroot -w /var/www/html ist Pfad zum Hauptverzeichnis (Document Root) Ihrer Website. Hier legt Certbot den temporären Token für die HTTP-01 Challenge ab. Die müssen Sie auf den entsprechenden Pfad Ihres Systems anpassen.
• -d definiert die Domains, für die das Zertifikat ausgestellt werden soll.
• --server die Ihrem Account zugeordnete ACME-URL.
• --eab-kid & --eab-hmac-key sind Ihre persönlichen Authentifizierungsdaten der CA.
• --agree-tos und -m dienen der Zustimmung zu den Nutzungsbedingungen der CA.

Sobald der Befehl erfolgreich abgeschlossen ist, befinden sich Ihr neues Zertifikat (`fullchain.pem`) und der private Schlüssel (`privkey.pem`) im Verzeichnis `/etc/letsencrypt/live/ihredomain.de/`. Binden Sie diese anschließend in Ihre Webserver-Konfiguration ein (z.B. als `SSLCertificateFile` und `SSLCertificateKeyFile` in Apache bzw. `ssl_certificate` und `ssl_certificate_key` in Nginx).

Hinweis: Der Pfadname `letsencrypt` ist historisch in Certbot verankert und wird auch bei der Nutzung anderer CAs wie HARICA verwendet.

Alternativ können Sie Certbot auch ohne bereits laufenden Webserver im Standalone-Modus nutzen. Dabei startet Certbot für die Dauer der Zertifikatsprüfung einen eigenen, temporären Webserver auf Ihrem System. Dieser übernimmt vollautomatisch die Beantwortung der HTTP-01 Challenge durch die Zertifizierungsstelle. Sobald das Zertifikat erfolgreich ausgestellt wurde, beendet sich dieser temporäre Server umgehend wieder. Der Aufruf ist nahezu identisch zum Webroot-Verfahren. Sie tauschen lediglich den Parameter "--webroot" gegen "--standalone" aus, wodurch logischerweise auch die Pfadangabe zum Verzeichnis ("-w /var/www/html") entfällt:

sudo certbot certonly \
  --standalone \
  -d server.uni-wuerzburg.de -d www.server.uni-wuerzburg.de \
  --server " https://acme-v02.harica.gr/acme/IHR_ALIAS/directory" \
  --eab-kid "IHR_EAB_KEY_IDENTIFIER" \
  --eab-hmac-key "IHR_EAB_HMAC_KEY" \
  --agree-tos \
  -m vorname.nachname@uni-wuerzburg.de

Im Normalfall müssen Sie die EAB-Daten nur bei der Erstanforderung angeben. Certbot speichert die Account-Verknüpfung und die URL der Zertifizierungsstelle in einer Konfigurationsdatei ab (zu finden unter "/etc/letsencrypt/renewal/ihrserver.uni-wuerzburg.de.conf").

3. Verlängerung eines bestehenden Zertifikats

Ihre Zertifikate können Sie ebenfalls über ACME automatisiert verlängern lassen. Die EAB-Daten müssen Sie nur bei der Erstanforderung angeben. Certbot speichert die Account-Verknüpfung, die verwendeten Parameter und die URL der Zertifizierungsstelle in der Renewal-Konfigurationsdatei unter "/etc/letsencrypt/renewal/ihrserver.uni-wuerzburg.de.conf".

Zum Testen der gespeicherten Konfiguration können Sie Certbot anweisen, die bei der CA hinterlegten Account-Informationen abzurufen. Dieser Befehl kontaktiert die CA und validiert den Account, berührt jedoch die Zertifikate nicht:

sudo certbot show_account --server "https://acme-v02.harica.gr/acme/IHR_ALIAS/directory"

Die offiziellen Installationspakete für Linux richten standardmäßig einen Systemd-Timer oder Cronjob ein, der zweimal täglich prüft, ob Zertifikate in Kürze ablaufen. Sollte ein Zertifikat in weniger als 30 Tagen ablaufen, beantragt Certbot automatisch und mit denselben Parametern wie bei der Erstausstellung (`--webroot` bzw. `--standalone`) ein neues Zertifikat.

Damit der Webserver das erneuerte Zertifikat auch tatsächlich lädt, empfiehlt es sich, einen Deploy-Hook einzurichten. Dieser wird nur ausgeführt, wenn ein Zertifikat tatsächlich erneuert wurde:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Für Apache ersetzen Sie den Befehl entsprechend durch "systemctl reload apache2". Den Deploy-Hook können Sie auch dauerhaft in der Renewal-Konfigurationsdatei hinterlegen.

Eine solche Zertifikatsverlängerung können Sie mit folgendem Befehl simulieren:

sudo certbot renew --dry-run --server "https://acme-v02.harica.gr/acme/IHR_ALIAS/directory"

Hinweis: Die Angabe von `--server` ist bei `--dry-run` zwingend erforderlich, da Certbot in diesem Modus nicht die gespeicherte ACME-URL aus der Renewal-Konfiguration verwendet, sondern standardmäßig die Let's-Encrypt-Staging-Umgebung kontaktiert. Bei einem regulären `certbot renew` (ohne `--dry-run`) greift Certbot hingegen auf die in der Renewal-Konfiguration gespeicherte Server-URL zurück.

Sie können auch manuell einen regulären Erneuerungslauf auslösen:

sudo certbot renew

Sind die Zertifikate noch ausreichend lange gültig, meldet das System lediglich „Certificate not yet due for renewal".

Möchten Sie den Austauschprozess vorab erzwingen, können Sie dies auf folgendem Weg erreichen:

sudo certbot renew --force-renewal

 

4. Widerrufen eines Zertifikats

Ein wichtiger Bestandteil des Lebenszyklus eines Zertifikats ist der vorzeitige Widerruf. Ein solcher Schritt ist zwingend erforderlich, wenn z.B. der private Schlüssel kompromittiert wurde, der Verdacht auf einen unbefugten Zugriff besteht oder der Dienst mitsamt der Domain dauerhaft eingestellt wird.

Der Widerruf signalisiert der Zertifizierungsstelle und infolgedessen den Browsern der Nutzer, dass dem Zertifikat nicht länger vertraut werden darf.

Um das Zertifikat über Certbot zu widerrufen, benötigen Sie den exakten Pfad zur Zertifikatsdatei und Ihre Server-URL:

sudo certbot revoke \
  --cert-path /etc/letsencrypt/live/ihrserver.uni-wuerzburg.de/cert.pem \
  --server "https://acme-v02.harica.gr/acme/IHR_ALIAS/directory" \
  --reason IHRE_BEGRUENDUNG

Hinweis: Hier wird bewusst "cert.pem" (das reine Server-Zertifikat) und nicht "fullchain.pem" (Server-Zertifikat inklusive CA-Kette) angegeben, da nur das eigentliche Endentitätszertifikat widerrufen wird.

Als Begründung sind folgende Werte gültig: "keycompromise" (Schlüssel kompromittiert), "cessationofoperation" (Betrieb eingestellt) oder "superseded" (Zertifikat wurde durch ein neues ersetzt). Lassen Sie den Parameter weg, wird standardmäßig "unspecified" (nicht spezifiziert) übermittelt.