SSL-Zertifikate: Let's Encrypt Auto-Renewal und Multi-Domain-Verwaltung

Die Alarm-E-Mails weckten das ganze Team. Die Website war nicht erreichbar, der Support wurde überflutet. Im Browser: rote Warnseite – „Das Sicherheitszertifikat dieser Website ist abgelaufen“. Schlimm.

Auf den Server, SSL-Zertifikat war gestern Nacht abgelaufen. Manuelle Verlängerung bis fünf Uhr morgens, zwei Stunden Schlaf, dann wieder ins Büro.

Danach die Frage: Kann man Zertifikatsablauf wirklich verhindern? Let’s Encrypt zeigt: kostenlose SSL-Zertifikate mit Auto-Renewal sind längst ausgereift. Viele Entwickler – ich damals auch – verwalten Zertifikate noch manuell.

Dieser Artikel beantwortet eine klare Frage: SSL-Zertifikate laufen nie ab, Multi-Domain-Verwaltung bleibt übersichtlich. Ob persönlicher Blog oder Unternehmensservice – nach dem Lesen können Sie direkt loslegen.

Was ist Let’s Encrypt? Zuerst die Grundlagen

Viele nutzen Let’s Encrypt, ohne den Mechanismus zu verstehen. Mit Grundlagen finden Sie Fehler schneller.

Rolle der Certificate Authority (CA)

Let’s Encrypt ist eine Certificate Authority, kurz CA. Ihr Anspruch: kostenlos, automatisiert, offen. Seit 2016 hat sie HTTPS massiv verbreitet – über 200 Millionen aktive Zertifikate, 100 % Browser-Vertrauen weltweit.

Traditionelle CAs (DigiCert, GeoTrust) sind teuer, bürokratisch, manuelle Prüfung. Let’s Encrypt ist vollautomatisch: Antrag, Validierung, Ausstellung. 90 Tage Gültigkeit wirken kurz – mit Auto-Renewal ist das sicherer. Kürzere Laufzeit, geringeres Risiko bei Kompromittierung.

ACME-Protokoll: Kern der Automatisierung

Let’s Encrypt nutzt ACME (Automated Certificate Management Environment), RFC 8555. Das Protokoll definiert automatische Domain-Validierung und Zertifikatsausstellung.

Drei Validierungsmethoden:

1. HTTP-01: Am häufigsten. Die CA ruft /.well-known/acme-challenge/ auf und prüft das Token – Beweis der Domain-Kontrolle.
2. DNS-01: Pflicht für Wildcards. Die CA prüft einen DNS-TXT-Record. Kein Webserver nötig, aber DNS-API-Zugriff.
3. TLS-ALPN-01: Seltener, für Spezialfälle.

HTTP-01 ist am einfachsten, wenn Port 80 erreichbar ist. DNS-01 flexibler für interne Dienste oder Wildcards.

Certbot: offiziell empfohlener Client

Certbot ist der offizielle Let’s-Encrypt-Client. Er übernimmt Antrag, Webserver-Konfiguration und Auto-Renewal.

Kernfunktionen von Certbot:

• Mehrere Validierungsmethoden
• Automatische Nginx-/Apache-Konfiguration (Plugins)
• systemd timer oder Cron Job
• Dry-Run zum Testen der Verlängerung

Mit diesen Grundlagen wissen Sie bei Problemen, wo Sie suchen müssen.

Einzeldomain-SSL: von null an

Der einfachste Fall: eine Domain, ein Server. Danach ist Multi-Domain der nächste Schritt.

Certbot installieren

Die Installation unterscheidet sich je nach System. Ubuntu/Debian: Snap – offiziell empfohlen, aktuelle Versionen.

Ubuntu/Debian (Snap):

# Snap installieren (falls noch nicht vorhanden)
sudo apt update
sudo apt install snapd

# Certbot installieren
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

CentOS/RHEL:

sudo yum install certbot
# oder
sudo dnf install certbot

Nach der Installation testen:

certbot --version
# Ausgabe z. B.: certbot 2.11.0

Zertifikat beantragen: drei Wege

Certbot bietet drei Modi – je nach Anforderung.

Weg 1: Nginx-Plugin (empfohlen für Einsteiger)

Am wenigsten Aufwand. Certbot passt Nginx an, beantragt das Zertifikat, richtet HTTPS und Redirect ein:

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

Certbot fragt u. a.:

• E-Mail (für Notfallbenachrichtigungen)
• Zustimmung zu den Nutzungsbedingungen
• E-Mail teilen (Nein wählen)
• HTTP auf HTTPS umleiten (Ja – sicherer)

Danach ist Nginx konfiguriert. Zertifikatspfade werden angezeigt:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/example.com/privkey.pem

Weg 2: Apache-Plugin

Analog zu Nginx, Plugin gewechselt:

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

Weg 3: Nur Zertifikat (manuelle Konfiguration)

Wenn Certbot die Konfiguration nicht ändern soll, oder Sie Caddy/Node.js nutzen – certonly:

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

-w setzt das Webroot-Verzeichnis. Certbot legt dort Validierungsdateien ab. Webserver konfigurieren Sie selbst.

Zertifikat prüfen

Nach der Beantragung Funktion verifizieren.

Zertifikatsdateien prüfen

sudo ls -la /etc/letsencrypt/live/example.com/

Vier Dateien:

• cert.pem: Zertifikat
• chain.pem: Intermediate Chain
• fullchain.pem: vollständige Kette (für Nginx)
• privkey.pem: Private Key (für Nginx)

SSL Labs Test

https://www.ssllabs.com/ssltest/ – Domain eingeben. Bewertung A+ bis F. Ziel: mindestens A.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Häufige Probleme:

• B oder C: TLS zu alt, schwache Ciphers – Optimierung folgt unten.
• F: unvollständige Kette – fullchain.pem statt cert.pem in Nginx.

Browser-Test

https://example.com öffnen – Schloss-Symbol. Aussteller: „Let’s Encrypt“.

Auto-Renewal: nie wieder Ablauf sorgen

Let’s-Encrypt-Zertifikate gelten 90 Tage. Mit Auto-Renewal ist das ein Vorteil – schneller Wechsel, geringeres Risiko.

Certbots Auto-Renewal-Mechanismus

Bei der Installation richtet Certbot die Verlängerung ein – je nach System unterschiedlich:

Systemd Timer (modernes Linux):

Certbot legt certbot.timer und certbot.service an. Der Timer läuft zweimal täglich und prüft Ablauf innerhalb von 30 Tagen. Dann startet der Service die Verlängerung.

Timer-Status prüfen:

sudo systemctl list-timers | grep certbot

Beispielausgabe:

NEXT                         LEFT          LAST                         PASSED       UNIT           ACTIVATES
Thu 2026-04-02 12:00:00 UTC  1h left       Thu 2026-04-02 00:00:00 UTC  11h ago      certbot.timer  certbot.service

Nächster und letzter Lauf sind sichtbar.

Cron Job (klassisch):

Ohne systemd (älteres CentOS) setzt Certbot einen Cron Job:

sudo crontab -l
# oder
cat /etc/cron.d/certbot

Typische Konfiguration:

0 0,12 * * * root certbot renew --quiet

Täglich um 0 und 12 Uhr.

Auto-Renewal wirklich testen

Timer oder Cron allein reicht nicht – Verlängerung muss funktionieren.

Dry-Run-Test

Simuliert Verlängerung ohne echte Ausstellung:

sudo certbot renew --dry-run

Beispielausgabe:

Processing /etc/letsencrypt/renewal/example.com.conf
Cert not due for renewal, but simulating renewal for dry run
...
The dry run was successful.

„successful“ bedeutet: Konfiguration stimmt.

Renewal-Konfiguration prüfen

Pro Zertifikat eine Renewal-Datei:

cat /etc/letsencrypt/renewal/example.com.conf

Enthält Antragsparameter und Validierungsmethode – wird bei Verlängerung gelesen.

Auto-Reload nach Verlängerung

Nach Verlängerung nutzt der Webserver noch das alte Zertifikat – Reload nötig.

Deploy Hook (empfohlen)

Nur bei erfolgreicher Verlängerung:

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

Oder in der Renewal-Datei:

# /etc/letsencrypt/renewal/example.com.conf bearbeiten
# am Ende ergänzen:
deploy_hook = systemctl reload nginx

Post Hook (immer)

Unabhängig vom Erfolg:

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

Deploy Hook nur bei Erfolg – meist die bessere Wahl.

Verlängerung schlägt fehl?

Auto-Renewal ist nicht fehlerfrei. Häufige Ursachen:

DNS-Problem

DNS geändert, CA sieht noch alte IP. Auf TTL warten oder manuell:

sudo certbot renew --force-renewal

Firewall oder Port

HTTP-01 braucht Port 80:

sudo ufw status
sudo iptables -L -n

Port 80 öffnen:

sudo ufw allow 80/tcp

Berechtigungen

Falsche Dateirechte prüfen:

sudo ls -la /etc/letsencrypt/live/
sudo ls -la /etc/letsencrypt/archive/

Webserver-User (z. B. www-data) muss lesen können.

Renewal-Logs

sudo tail -f /var/log/letsencrypt/letsencrypt.log

Enthält die Fehlerursache.

Multi-Domain-SSL: zentral oder getrennt

Bei mehreren Domains zählt die Strategie. Sonst: unterschiedliche Ablaufdaten, verstreute Dateien, Fehler in der Konfiguration.

Ein Zertifikat, mehrere Domains (SAN)

Empfohlen: ein Zertifikat mit mehreren Domains:

sudo certbot --nginx \
  -d example.com \
  -d www.example.com \
  -d api.example.com \
  -d admin.example.com

Vorteile:

• Einheitliche Verlängerung
• Ein Zertifikatsverzeichnis
• Einfache Webserver-Konfiguration

SAN (Subject Alternative Names): Feld im Zertifikat mit allen Domains. Der Browser prüft, ob die aufgerufene Domain in der SAN-Liste steht.

Enthaltene Domains anzeigen:

sudo certbot certificates

Beispielausgabe:

Found the following certs:
  Certificate Name: example.com
    Domains: example.com www.example.com api.example.com admin.example.com
    Expiry Date: 2026-07-01 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem

Wildcard-Zertifikat

Wildcard *.example.com deckt Subdomains erster Ebene ab: blog.example.com, api.example.com usw.

DNS-01 ist Pflicht: HTTP-01 unterstützt keine Wildcards. Certbot braucht DNS-API für TXT-Records.

DNS-Plugin konfigurieren

Je nach Anbieter unterschiedlich. Cloudflare ist verbreitet:

# Cloudflare-Plugin installieren
sudo snap install certbot-dns-cloudflare

# Credentials-Datei anlegen
sudo nano /root/.secrets/certbot/cloudflare.ini

Inhalt:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

dns_cloudflare_api_token = your_cloudflare_api_token

API Token in der Cloudflare-Konsole, Berechtigung „DNS:Edit“.

Wildcard beantragen

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  -d "*.example.com" \
  -d example.com

Wichtig: *.example.com und example.com zusammen – Wildcard deckt die Apex-Domain nicht ab.

Einschränkungen

Nur Subdomains erster Ebene: *.example.com matcht sub.example.com, nicht sub.sub.example.com.

Für Subdomains zweiter Ebene separat beantragen:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  -d "*.example.com" \
  -d "*.api.example.com" \
  -d example.com

Deckt api.example.com und v1.api.example.com ab.

Strategie für mehrere Zertifikate

Wann ein SAN-Zertifikat, wann mehrere?

Gruppierung nach Service (empfohlen)

Web-Gruppe: Hauptseite, Blog, Docs

sudo certbot --nginx -d example.com -d www.example.com -d blog.example.com -d docs.example.com

API-Gruppe: Endpunkte, Admin

sudo certbot --nginx -d api.example.com -d admin.example.com -d v1.api.example.com

Interne Dienste: Monitoring, Logs, Tools

sudo certbot certonly --dns-cloudflare -d "*.internal.example.com"

Vorteile:

• Begrenzte Auswirkung bei Verlängerung
• Getrennte Berechtigungen
• Fehlerisolation

Nach Domain-Ebene

Wildcard plus Einzeldomains:

# Wildcard für alle Subdomains
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

# Besondere Subdomain separat
sudo certbot --nginx -d secure.example.com

Zertifikatspfad-Struktur

Verzeichnisaufbau verstehen – dann bleibt Multi-Zertifikat-Verwaltung übersichtlich.

Live-Verzeichnis: /etc/letsencrypt/live/[Zertifikatsname]/

Symlinks auf die aktuelle Version. Nach Verlängerung zeigen sie auf neue Dateien.

sudo ls -la /etc/letsencrypt/live/example.com/
lrwxrwxrwx 1 root root  42 Apr  2 12:00 cert.pem -> ../../archive/example.com/cert2.pem
lrwxrwxrwx 1 root root  43 Apr  2 12:00 chain.pem -> ../../archive/example.com/chain2.pem
lrwxrwxrwx 1 root root  44 Apr  2 12:00 fullchain.pem -> ../../archive/example.com/fullchain2.pem
lrwxrwxrwx 1 root root  40 Apr  2 12:00 privkey.pem -> ../../archive/example.com/privkey2.pem

Archiv: /etc/letsencrypt/archive/[Zertifikatsname]/

Historie aller Verlängerungen: cert1.pem, cert2.pem usw.

Renewal-Konfiguration: /etc/letsencrypt/renewal/[Zertifikatsname].conf

Antragsparameter für die Verlängerung:

cat /etc/letsencrypt/renewal/example.com.conf

Enthält u. a.:

• Validierungsmethode (webroot, nginx, dns-cloudflare)
• Domain-Liste
• Deploy Hooks

Erweiterte Konfiguration: Sicherheit und Performance

Nach der Basis lohnt Feintuning – Sicherheit und Geschwindigkeit zusammen.

HTTP/2 und OCSP Stapling

HTTP/2 beschleunigt; OCSP Stapling reduziert Validierungslatenz.

HTTP/2 in Nginx

server {
    listen 443 ssl http2;  # http2 ergänzen
    server_name example.com;

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

    # ... weitere Konfiguration
}

Nginx testen und neu laden:

sudo nginx -t
sudo systemctl reload nginx

OCSP Stapling

OCSP (Online Certificate Status Protocol) prüft den Zertifikatsstatus. Stapling: Server holt das Ergebnis vorab, Client fragt die CA nicht extra an.

server {
    # ... SSL-Konfiguration

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
}

SSL Labs zeigt dann „OCSP Stapling: Yes“.

Sicherheitshärtung: alte TLS-Versionen deaktivieren

TLS 1.0 und 1.1 sind unsicher. Seit 2020 von mainstream-Browsern abgeschaltet.

server {
    # nur TLS 1.2 und 1.3
    ssl_protocols TLSv1.2 TLSv1.3;

    # empfohlene Cipher Suites
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    ssl_prefer_server_ciphers on;

    # Session Cache (Performance)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
}

SSL Labs sollte A oder A+ zeigen.

HSTS-Header

HSTS (HTTP Strict Transport Security) zwingt den Browser zu HTTPS. Auch bei http:// leitet er um.

server {
    # ... SSL-Konfiguration

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

Parameter:

• max-age=31536000: ein Jahr (Sekunden)
• includeSubDomains: alle Subdomains
• preload: Eintrag in Browser-Preload-Liste möglich

Hinweis: Mit HSTS kann temporäres HTTP (Tests) scheitern. Vorsichtig einsetzen.

Monitoring und Alarme

Auto-Renewal kann fehlschlagen. Eine Woche vor Ablauf warnen lassen – Zeit für manuelle Korrektur.

Einfaches Monitoring-Skript

Restlaufzeit prüfen:

#!/bin/bash
# /usr/local/bin/check-ssl-expiry.sh

DOMAIN="example.com"
EXPIRY_DAYS=$(openssl s_client -connect $DOMAIN:443 -servername $DOMAIN 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)

EXPIRY_DATE=$(date -d "$EXPIRY_DAYS" +%s)
CURRENT_DATE=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_DATE - $CURRENT_DATE) / 86400 ))

if [ $DAYS_LEFT -lt 7 ]; then
    echo "WARNING: SSL certificate for $DOMAIN expires in $DAYS_LEFT days"
    # E-Mail-Alarm (Mailserver erforderlich)
    mail -s "SSL Certificate Expiry Warning" [email protected] <<< "SSL certificate for $DOMAIN expires in $DAYS_LEFT days"
fi

Cron täglich:

0 6 * * * /usr/local/bin/check-ssl-expiry.sh

Certbot-Benachrichtigung

Bei fehlgeschlagener Verlängerung mailt Certbot an die Antrags-E-Mail. Adresse korrekt halten und Postfach prüfen.

Häufige Probleme und Lösungen

Typische Stolpersteine beim Setup.

Zertifikatsantrag fehlgeschlagen

Ursache 1: DNS zeigt nicht auf den Server

HTTP-01 braucht erreichbare Domain. Ohne DNS-Auflösung scheitert die Validierung.

DNS prüfen:

dig example.com +short
# oder
nslookup example.com

IP muss dem Server entsprechen.

Lösung: Auf TTL warten, dann erneut versuchen.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Ursache 2: Port 80 belegt oder Firewall

HTTP-01 nutzt Port 80:

sudo netstat -tulpn | grep :80
sudo lsof -i :80

Blockierenden Dienst stoppen:

sudo systemctl stop <dienstname>

Firewall:

sudo ufw status
# oder
sudo iptables -L -n

Ports öffnen:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Ursache 3: Webroot-Berechtigungen

Bei certonly --webroot legt Certbot Dateien unter .well-known ab:

ls -la /var/www/html/.well-known/

Schreibzugriff für Certbot (meist root) sicherstellen:

sudo mkdir -p /var/www/html/.well-known/acme-challenge
sudo chown -R www-data:www-data /var/www/html/.well-known

Verlängerung fehlgeschlagen

Ruhe bewahren – Logs lesen, gezielt beheben.

Certbot-Logs

sudo tail -100 /var/log/letsencrypt/letsencrypt.log

Typische Meldungen:

• Connection refused: Port-Problem
• DNS problem: NXDOMAIN: DNS-Problem
• Rate limit exceeded: Antragslimit überschritten

Manuelle Erzwingung

sudo certbot renew --force-renewal

--force-renewal ignoriert das Ablaufdatum.

Renewal-Konfiguration prüfen

Beschädigte .conf verhindert Verlängerung:

cat /etc/letsencrypt/renewal/example.com.conf

Bei Defekt: Zertifikat löschen und neu beantragen:

sudo certbot delete --cert-name example.com
sudo certbot --nginx -d example.com -d www.example.com

Konflikte bei mehreren Zertifikaten

Falscher Zertifikatspfad in der Webserver-Konfiguration.

Falscher Nginx-Pfad

sudo nginx -T | grep ssl_certificate

Jeder server-Block muss den richtigen Pfad nutzen.

Typische Fehler:

• cert.pem statt fullchain.pem
• Verzeichnisname passt nicht zur Domain

Zertifikatsname vs. Domain

Certbot benennt nach der ersten -d-Domain:

sudo certbot --nginx -d api.example.com -d example.com

Name: api.example.com, Pfad: /etc/letsencrypt/live/api.example.com/.

Nginx mit /etc/letsencrypt/live/example.com/ findet nichts.

Namen prüfen:

sudo certbot certificates

Name und Pfad müssen übereinstimmen.

Wildcard-Einschränkungen

Praktisch, aber Grenzen beachten.

Nur Subdomains erster Ebene

*.example.com matcht sub.example.com, nicht sub.sub.example.com.

Zusätzliches Zertifikat:

# Wildcard (erste Ebene)
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

# zweite Ebene
sudo certbot certonly --dns-cloudflare -d "*.api.example.com"

Apex-Domain nicht im Wildcard

*.example.com deckt example.com nicht ab – -d example.com separat.

Falsch:

# Apex funktioniert nicht
sudo certbot certonly --dns-cloudflare -d "*.example.com"

Richtig:

sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

Fazit: vom manuellen Prozess zur Automatisierung

SSL-Verwaltung ist der Schritt von manuell zu automatisiert. Traditionelle CAs waren aufwendig; Let’s Encrypt macht es zuverlässig und einfach.

Kernpunkte:

1. Grundlagen: ACME definiert Validierung und Ausstellung. HTTP-01 und DNS-01 für unterschiedliche Szenarien.
2. Auto-Renewal: Certbot richtet systemd timer oder Cron ein. Auslösung 30 Tage vor Ablauf, zweimal tägliche Prüfung.
3. Multi-Domain: SAN für zentrale Verwaltung, Wildcard für viele Subdomains. Gruppierung nach Service empfohlen.
4. Sicherheit: HTTP/2, OCSP Stapling, alte TLS deaktivieren, HSTS – SSL Labs A+ möglich.
5. Monitoring: Auto-Renewal kann scheitern – Restlaufzeit aktiv überwachen.

Weiterführend:

Bei vielen Servern und Domains:

• Automatisierungsplattformen: Cert Manager (Kubernetes), Traefik (Auto-SSL)
• Monitoring-Dienste: SSL Monitor, Uptime Robot
• CI/CD: Zertifikatsstatus beim Deploy prüfen

Einmal automatisiert, brauchen Sie sich nicht mehr zu sorgen. Sicherheit für Nutzer und Suchmaschinen – und keine Alarm-Mails um drei Uhr nachts.