Hackerparagraph,IT-Security, Linux Bild © DALL-EHackerparagraph,IT-Security, Linux (Bild © DALL-E)

Certbot Installationsanleitung

Der Installationsprozess für Certbot hängt vom jeweiligen Betriebssystem und dem verwendeten Webserver ab.

Ubuntu- und Debian-Systeme

Auf Debian-basierten Systemen wird das Basis-Tool über das Paketverwaltungswerkzeug installiert:

apt update
apt install certbot

Um eine direkte Integration mit bestimmten Webservern zu ermöglichen, sind Plugins erforderlich.

Für Apache:

apt install python3-certbot-apache

Für Nginx:

apt install python3-certbot-nginx

CentOS- und AlmaLinux-Systeme

Bei RHEL-basierten Distributionen wird der dnf-Paketmanager verwendet, um sowohl den Agenten als auch das Nginx-Plugin zu installieren:

dnf install certbot python3-certbot-nginx

Bereitstellungsmethoden und Zertifikatsausstellung

Certbot bietet je nach Serverumgebung und gewünschtem Automatisierungsgrad verschiedene Betriebsmodi an.

Automatisierte Integration für Apache und Nginx

Die direkteste Methode ist die Verwendung der Webserver-Plugins. Diese Plugins überprüfen die Domain-Inhaberschaft, besorgen das Zertifikat und passen die Serverkonfiguration automatisch an, um HTTPS zu aktivieren.

Apache-Automatisierung:

certbot --apache -d example.com -d www.example.com

Nginx-Automatisierung:

certbot --nginx -d example.com -d www.example.com

Für Administratoren, die ihre Serverkonfigurationsdateien lieber manuell verwalten, kann das certonly-Flag verwendet werden. Damit wird das Zertifikat abgerufen, ohne die bestehende Konfiguration zu ändern:

Apache-Anleitung:

certbot certonly --apache -d www.example.com

Nginx-Anleitung:

certbot certonly --nginx -d www.example.com

Standalone- und Webroot-Modus

In Umgebungen, in denen derzeit kein Webserver läuft, wird der Standalone-Modus verwendet. Bei dieser Methode muss Port 80 offen und verfügbar sein, da Certbot einen temporären Webserver startet, um die Challenge zu bearbeiten:

certbot certonly --standalone -d example.com

Bei komplexen Setups oder Shared-Hosting-Umgebungen kommt der Webroot-Modus zum Einsatz. Bei dieser Methode wird eine Challenge-Datei in einem bestimmten Verzeichnis auf dem Server abgelegt:

certbot certonly --webroot -w /var/www/html -d example.com

Wenn du den Webroot-Modus mit Nginx nutzt, ist der folgende Konfigurationsblock erforderlich, damit die Zertifizierungsstelle auf die Challenge-Dateien zugreifen kann:

location /.well-known/acme-challenge/ {
    root /var/www/certbot;
}

Zertifikatsverwaltung und Dateistruktur

Administratoren können den Status und die Ablaufdaten aller verwalteten Zertifikate mit folgendem Befehl überprüfen:

certbot certificates

Nach erfolgreicher Ausstellung werden die Zertifikate unter /etc/letsencrypt/live/example.com/ gespeichert. Das Verzeichnis enthält vier wichtige Dateien:

  • 1. cert.pem: Das Serverzertifikat.
  • 2. chain.pem: Das Zwischenzertifikat.
  • 3. fullchain.pem: Eine Kombination aus Server- und Zwischenzertifikat.
  • 4. privkey.pem: Der zum Zertifikat gehörende private Schlüssel.

Manuelle Serverkonfiguration

Wenn die Zertifikate über die certonly-Methode bezogen wurden, müssen die Server-Blöcke manuell aktualisiert werden.

Beispiel für eine Nginx-Konfiguration:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Beispiel für die Apache-Konfiguration:

<virtualhost>
    ServerName example.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</virtualhost>

Mechanismen zur automatischen Verlängerung

Let’s Encrypt-Zertifikate haben eine Gültigkeitsdauer von 90 Tagen. Um Dienstunterbrechungen zu vermeiden, implementiert Certbot eine automatische Verlängerung.

Überprüfung und Test

Den Status des Verlängerungs-Timers kannst du über systemd überprüfen:

systemctl status certbot.timer

Um eine Verlängerung zu simulieren und sicherzustellen, dass keine Konfigurationsfehler vorliegen, wird der Befehl dry-run verwendet:

certbot renew --dry-run

Planung über Cron

In Systemen ohne systemd ist ein Cron-Job erforderlich, um den Erneuerungsprozess auszulösen. Durch Hinzufügen der folgenden Zeile zur crontab (crontab -e) wird sichergestellt, dass der Prozess täglich um 3:00 Uhr morgens ausgeführt wird:

0 3 * * * certbot renew --quiet

Implementierung von Erneuerungs-Hooks

Da Webserver Zertifikate in den Arbeitsspeicher laden, ist nach einer Zertifikatsaktualisierung ein Neuladen erforderlich. Dies lässt sich über Hooks verwalten.

  • Konfigurationsdatei: Füge in /etc/letsencrypt/renewal/example.com.confunter [renewalparams]post_hook = systemctl reload nginx hinzu.
  • Befehlszeilen-Hook: certbot renew --post-hook "systemctl reload nginx"
  • Deploy-Hook: Um einen Befehl nur dann auszuführen, wenn ein Zertifikat tatsächlich erneuert wird: certbot renew --deploy-hook "systemctl reload nginx"

Erweiterte Implementierung: Wildcard-Zertifikate

Wildcard-Zertifikate (z. B. *.example.com) erfordern eine DNS-01-Challenge anstelle einer HTTP-01-Challenge, da die Zertifizierungsstelle die Kontrolle über die gesamte DNS-Zone überprüfen muss.

Manuelle DNS-Challenge

certbot certonly --manual --preferred-challenges dns -d "*.example.com" -d example.com

Hierfür muss der Administrator manuell einen TXT-Eintrag in den DNS-Einstellungen des Domain-Anbieters erstellen.

Automatisiertes DNS über Cloudflare

Zur Automatisierung werden DNS-Plugins verwendet. Für Cloudflare wird das Plugin wie folgt installiert:

apt install python3-certbot-dns-cloudflare

Es muss eine Anmeldedatei unter /etc/letsencrypt/cloudflare.ini erstellt werden, die Folgendes enthält:

dns_cloudflare_api_token = DEIN_TOKEN_HIER
chmod 600 /etc/letsencrypt/cloudflare.ini

Das Zertifikat wird dann mit folgendem Befehl angefordert:

 certbot certonly \
 --dns-cloudflare \
 --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
 -d "*.example.com" -d example.com

Fehlerbehebung und bewährte Vorgehensweisen

Behebung häufiger Fehler

Challenge fehlgeschlagen

Dies deutet in der Regel darauf hin, dass die DNS-Einträge nicht auf den richtigen Server verweisen, Port 80 durch eine Firewall blockiert ist oder die Webserver-Konfiguration den Zugriff auf das Verzeichnis .well-known verhindert. Eine Diagnose kannst du mit folgenden Befehlen durchführen:

dig example.com +short
curl -I http://www.example.com/.well-known/acme-challenge/test

Rate-Limit überschritten

Let’s Encrypt begrenzt die Anzahl der pro Domain ausgestellten Zertifikate. Zu Testzwecken sollte die Staging-Umgebung verwendet werden:

certbot --nginx --staging -d www.example.com

Nicht autorisiert

Dies ist in der Regel auf Verzögerungen bei der DNS-Propagierung oder falsches Server-Routing zurückzuführen.

Sicherheitsoptimierung

Um eine sichere HTTPS-Implementierung zu gewährleisten, werden folgende Konfigurationen empfohlen:

1. Umleitung von HTTP zu HTTPS:

server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

2. HSTS-Implementierung

Um Browser zur Verwendung von HTTPS zu zwingen, füge den folgenden Header hinzu:

 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

3. Zertifikatsüberwachung

Die externe Überwachung des Zertifikatsablaufs kann über OpenSSL erfolgen:

 echo | openssl s_client -servername www.example.com -connect www.example.com:443 2&gt;/dev/null | openssl x509 -noout -dates

Vergleich der Certbot-Befehle

Neues Zertifikat (Nginx)

certbot --nginx -d www.domain.com

Nur Zertifikat (Nginx)

certbot certonly --nginx -d www.domain.com

Zertifikate auflisten

certbot certificates

Verlängerung testen

certbot renew --dry-run

Verlängerung durchführen

certbot renew

Zertifikat löschen

certbot delete --cert-name www.domain.com