SSL-Zertifikate und HTTPS-Erneuerungen in Cloud-Hosting-Umgebungen automatisieren

Das manuelle Verwalten von SSL-Zertifikaten gehört für Teams, die produktive Anwendungen betreiben, zu den häufigsten Herausforderungen. Wenn Sie derzeit Let’s Encrypt zusammen mit Cronjobs auf virtuellen Servern einsetzen, kennen Sie vermutlich bereits den Aufwand durch Ablaufwarnungen, fehlgeschlagene Verlängerungen und die dauerhaft notwendige Pflege.

In diesem Tutorial erfahren Sie, wie sich SSL-Zertifikate und HTTPS-Erneuerungen in einer Cloud-Umgebung automatisieren lassen, indem vollständig verwaltetes SSL auf Load Balancern und Anwendungsplattformen genutzt wird, ohne certbot manuell auf Servern auszuführen.

Darüber hinaus lernen Sie, wie sich automatisches HTTPS auf einer Cloud-Plattform aktivieren lässt, wie die automatisierte Zertifikatsverwaltung bei Load Balancern und verwalteten Anwendungsplattformen funktioniert und wann es sinnvoll ist, verwaltetes SSL anstelle von Let’s Encrypt auf einzelnen virtuellen Maschinen zu verwenden. Am Ende wissen Sie, wie sich Fehler bei der Zertifikatserneuerung vermeiden und der betriebliche Aufwand verringern lassen.

Warum SSL-Zertifikate automatisieren?

Die manuelle Verlängerung von SSL-/TLS-Zertifikaten kann zu verschiedenen Problemen führen:

• Abgelaufene Serverzertifikate, die Browser-Warnungen auslösen und unter Umständen Ausfälle verursachen.
• Ein erhöhtes Risiko für Dienstunterbrechungen, wenn Erneuerungen übersehen werden.

Die automatische Erneuerung von SSL-Zertifikaten bringt mehrere Vorteile mit sich:

• Die automatische Verlängerung von SSL- und TLS-Zertifikaten, einschließlich X.509-Zertifikaten, sorgt dafür, dass Zertifikate bereits vor ihrem Ablauf aktualisiert werden.
• Es ist nicht erforderlich, certbot auszuführen oder Cronjobs zu pflegen, da verwaltete Zertifikatsprozesse auf Load Balancern und Plattform-as-a-Service-Angeboten die Bereitstellung und Erneuerung übernehmen.
• Die Zertifikatserneuerung auf Container-Plattformen und für verwaltete Anwendungszertifikate wird durch HTTPS-Automatisierung in der Cloud vereinfacht und ermöglicht eine Bereitstellung sowie automatische Verlängerung ohne zusätzliche Konfiguration.

Dieses Tutorial zeigt, wie sich SSL sowohl auf Load Balancern als auch auf Anwendungsplattformen mit geringem Aufwand automatisieren lässt.

Wichtige Erkenntnisse

• Verwaltete Load Balancer können Unterstützung für Let’s Encrypt und HTTP/3 bieten, SSL-Zertifikate automatisch kostenlos über Let’s Encrypt bereitstellen und erneuern und gleichzeitig durch HTTP/3 für bessere Performance bei den Nutzern sorgen. Dadurch entfällt die manuelle Konfiguration von Let’s Encrypt auf einzelnen virtuellen Servern.
• Verwaltete Anwendungsplattformen können SSL-Zertifikate automatisch bereitstellen und erneuern, sobald eine benutzerdefinierte Domain hinzugefügt wird, ganz ohne manuelle Einrichtung.
• Der Eigenbau-Ansatz mit Let’s Encrypt und Cronjobs funktioniert, bringt jedoch laufenden Wartungsaufwand mit sich. Verwaltete Dienste ermöglichen eine automatisierte HTTPS-Zertifikatsverwaltung ohne certbot.
• Weiterleitungen von HTTP auf HTTPS und HSTS-Header sind wichtige Maßnahmen zur Härtung der Sicherheit, unabhängig davon, welche SSL-Methode eingesetzt wird.
• Die Überwachung von Zertifikatsablaufdaten hilft dabei, Dienstunterbrechungen zu vermeiden, selbst wenn Erneuerungen automatisiert erfolgen.

Voraussetzungen

Bevor Sie beginnen, sollten die folgenden Voraussetzungen erfüllt sein:

• Ein Cloud-Konto mit einer virtuellen Maschine, auf der Ubuntu 24.04 oder neuer läuft
• Eine Domain mit Zugriff auf DNS, damit A-Records und die Validierung eingerichtet werden können
• Grundlegende Kenntnisse in der Nginx-Konfiguration und im Umgang mit der Linux-Kommandozeile
• SSH-Zugriff auf die virtuelle Maschine
• Ein API-Token des Cloud-Anbieters, sofern Aufgaben per Skript automatisiert werden sollen

So funktioniert verwaltetes SSL auf Cloud-Plattformen

Transport Layer Security, kurz TLS, verschlüsselt den Datenverkehr zwischen Clients und Servern. SSL-Zertifikate, genauer gesagt TLS- oder X.509-Zertifikate, bestätigen die Identität eines Servers und ermöglichen verschlüsselte Verbindungen. Let’s Encrypt stellt kostenlose Serverzertifikate aus, die 90 Tage gültig sind und daher vor Ablauf erneuert werden müssen.

Wie geht eine Cloud-Plattform mit Zertifikatserneuerungen um, wenn verwaltete Dienste genutzt werden?

Die Plattform stellt Zertifikate bereit, meist über Let’s Encrypt, prüft den Besitz der Domain und erneuert die Zertifikate automatisch vor Ablauf. Weder ein certbot-Prozess noch ein Cronjob sind dafür erforderlich.

• Bei Load Balancern beendet der Listener, häufig ein HTTPS-Listener, TLS direkt am Edge.
• Bei Anwendungsplattformen verwaltet der Dienst die SSL-Zertifikate für bereitgestellte Anwendungen, sobald eine benutzerdefinierte Domain hinzugefügt wird. Beide Varianten können Multi-Region-Bereitstellungen und, sofern verfügbar, globale Verteilung unterstützen.

Cloud-Anbieter stellen in der Regel drei Ansätze bereit:

• DIY auf virtuellen Maschinen: Sie verwalten Let’s-Encrypt-Zertifikate selbst mit certbot und Cronjobs.
• Verwaltetes SSL auf Load Balancern: Der Cloud-Anbieter übernimmt die Bereitstellung und Verlängerung der Zertifikate auf Ebene des Load Balancers.
• Verwaltetes SSL auf Anwendungsplattformen: SSL-Automatisierung auf Platform-as-a-Service-Ebene und Zertifikatserneuerung für Container-Plattformen erfolgen vollständig automatisch und ohne Konfiguration.

Die folgenden Abschnitte konzentrieren sich auf die Automatisierung von SSL auf Load Balancern und verwalteten Anwendungsplattformen mit vollständig verwalteter Erneuerung und ohne manuelle Nutzung von certbot.

SSL mit Let’s Encrypt auf einer virtuellen Maschine einrichten

Dieser Abschnitt beschreibt den klassischen Do-it-yourself-Ansatz mit Let’s Encrypt und certbot. Auch wenn diese Methode funktioniert, erfordert sie mehr Pflege als verwaltete Lösungen wie Load Balancer oder Anwendungsplattformen.

Certbot installieren

Aktualisieren Sie zunächst das System und installieren Sie certbot:

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

Das Paket python3-certbot-nginx enthält das Nginx-Plugin, das Nginx automatisch für SSL anpassen kann. Falls Nginx noch nicht installiert ist, sollte dies zuerst erfolgen.

Das erste Zertifikat anfordern

Bevor ein Zertifikat angefordert wird, sollte sichergestellt sein, dass die Domain auf die IP-Adresse der virtuellen Maschine verweist. Dazu wird im DNS ein A-Record angelegt, der die Domain auf die öffentliche IP des Servers zeigt.

Fordern Sie anschließend ein Zertifikat für Ihre Domain an:

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

Certbot führt dabei die folgenden Schritte aus:

• Überprüfung des Domain-Besitzes per HTTP-Challenge
• Erstellung des Zertifikats
• Anpassung der Nginx-Konfiguration für SSL
• Aktivierung der automatischen Erneuerung

Nach der erfolgreichen Ausstellung des Zertifikats richtet certbot in der Regel einen systemd-Timer ein, der zweimal täglich einen Erneuerungsversuch startet. Trotzdem sollten Sie prüfen, ob dieser Mechanismus korrekt funktioniert.

Automatische Erneuerung prüfen

Testen Sie den Verlängerungsprozess mit einem Dry Run:

sudo certbot renew --dry-run

Wenn dieser Befehl erfolgreich durchläuft, ist die automatische Erneuerung korrekt eingerichtet. Der systemd-Timer von certbot führt certbot renew zweimal täglich aus, erneuert jedoch nur Zertifikate, die sich innerhalb von 30 Tagen vor Ablauf befinden.

Den Status des Timers können Sie mit folgendem Befehl prüfen:

sudo systemctl status certbot.timer

Häufige Probleme bei der manuellen Zertifikatsverwaltung

Wenn Zertifikate manuell verwaltet werden, können mehrere Probleme auftreten:

• Port 80 ist blockiert: Let’s Encrypt benötigt Port 80 für die HTTP-Validierung. Die Firewall muss daher HTTP-Verkehr zulassen.
• Verzögerte DNS-Propagation: Wenn DNS-Änderungen noch nicht vollständig übernommen wurden, können Zertifikatsanfragen fehlschlagen. Die Propagation lässt sich mit Werkzeugen wie dig oder Online-DNS-Checkern prüfen.
• Mehrere Erneuerungspfade: Befinden sich mehrere Server hinter einem Load Balancer, kann jeder Server ein eigenes Zertifikat benötigen. Das macht die Verlängerung komplexer. In diesem Fall sind verwaltete Zertifikate auf dem Load Balancer meist die bessere Lösung.
• Zertifikatssynchronisierung: Nach einer Verlängerung muss Nginx neu geladen werden, und unter Umständen müssen Zertifikate zwischen mehreren Servern synchronisiert werden.

SSL auf Cloud-Load-Balancern automatisieren

Verwaltete Load Balancer vereinfachen die Automatisierung von SSL-Zertifikaten, indem sie TLS-Terminierung und Erneuerung automatisch übernehmen.

Diese Methode ist besonders geeignet, wenn mehrere Backend-Server betrieben werden oder SSL-Verarbeitung von den Anwendungssystemen ausgelagert werden soll. Load Balancer verteilen den Verkehr auf mehrere Server und steigern die Verfügbarkeit.

Verwaltetes SSL auf einem Load Balancer aktivieren

Öffnen Sie das Control Panel Ihres Cloud-Anbieters und erstellen Sie einen neuen Load Balancer.

1. Wechseln Sie in den Netzwerkbereich, wählen Sie Load Balancer und erstellen Sie einen neuen Eintrag.
2. Wählen Sie die Region, in der der Load Balancer betrieben werden soll. In der Regel empfiehlt es sich, dieselbe Region wie für die Backend-Server zu verwenden.
3. Wählen Sie den Pool der Backend-VMs aus, entweder direkt bei der Erstellung oder später.
4. Fügen Sie Weiterleitungsregeln hinzu, um festzulegen, wie der Datenverkehr vom Load Balancer zu den Backend-Servern weitergeleitet wird. Mindestens eine Regel ist erforderlich.

Eine typische Standardregel leitet HTTP-Verkehr auf Port 80 des Load Balancers an HTTP-Port 80 der Backend-Server weiter. Weitere Regeln können während der Einrichtung erstellt und später in den Einstellungen angepasst werden.

In der Regel stehen dabei folgende Optionen zur Auswahl:

• Eine Weiterleitungsregel mit Let’s-Encrypt-Zertifikat erstellen
• Ein eigenes Zertifikat samt privatem Schlüssel hochladen

Wenn die Domain über den DNS-Dienst des Anbieters verwaltet wird, kann meist die Let’s-Encrypt-Option gewählt werden, um ein vollständig verwaltetes SSL-Zertifikat zu erzeugen. Die Plattform erstellt und erneuert dieses Zertifikat anschließend automatisch.

Viele Plattformen bieten außerdem die Möglichkeit, DNS-Einträge für neu ausgestellte Let’s-Encrypt-Zertifikate automatisch anzulegen. Wer DNS lieber selbst verwalten möchte, kann diese Option bei der Einrichtung deaktivieren.

Diese Einstellung lässt sich häufig später beim Hinzufügen oder Aktualisieren von Weiterleitungsregeln anpassen. Die geänderte Auswahl gilt jedoch normalerweise nur für neue Regeln und ändert bestehende DNS-Einträge nicht.

HTTPS-Verkehr erzwingen

Wenn alle Besucher ausschließlich per HTTPS zugreifen sollen, um Sicherheit und Datenintegrität zu erhöhen, kann HTTP-Verkehr auf HTTPS umgeleitet werden. Unsichere Anfragen, die den Load Balancer erreichen, werden dann automatisch an den HTTPS-Endpunkt mit hinterlegtem Zertifikat weitergeleitet.

Aktivieren Sie dazu in den erweiterten Einstellungen eine Option wie Redirect HTTP to HTTPS.

Nach der Konfiguration führt die Plattform in der Regel automatisch die folgenden Schritte aus:

• Prüfung des Domain-Besitzes über DNS
• Bereitstellung des SSL-Zertifikats
• Einrichtung der automatischen Erneuerung
• Zuordnung des Zertifikats zum Load Balancer

Der Load Balancer entschlüsselt den SSL-Verkehr und leitet ihn anschließend unverschlüsselt über das private Netzwerk an die Backend-Server weiter. Dadurch sinkt die CPU-Last auf den Anwendungssystemen und die Zertifikatsverwaltung wird deutlich einfacher. Die Zertifikate verbleiben ausschließlich auf dem Load Balancer und müssen nicht auf jedes Backend-System kopiert werden.

Verwaltete SSL-Zertifikate auf dem Load Balancer werden automatisch vor ihrem Ablauf erneuert. Weder Cronjobs noch certbot-Konfigurationen sind dafür nötig.

Wenn jedoch durch Compliance-Vorgaben oder erhöhte Sicherheitsanforderungen eine vollständige Ende-zu-Ende-Verschlüsselung notwendig ist, sollte SSL-Passthrough statt TLS-Terminierung eingesetzt werden.

SSL-Passthrough bedeutet, dass Zertifikate weiterhin auf den Backend-Servern verwaltet werden müssen, bietet aber für sensible Workloads einen höheren Schutz.

SSL auf verwalteten Anwendungsplattformen automatisieren

Verwaltete Anwendungsplattformen bieten die einfachste Form der automatisierten HTTPS-Zertifikatsverwaltung. Wird eine benutzerdefinierte Domain hinzugefügt, stellt die Plattform SSL-Zertifikate ohne zusätzliche Konfiguration automatisch bereit und erneuert sie ebenfalls automatisch. Das umfasst Platform-as-a-Service-SSL-Automatisierung sowie die Zertifikatserneuerung für Container-Plattformen ganz ohne certbot oder andere manuelle Schritte.

HTTPS auf einer Anwendungsplattform aktivieren

Um automatisches HTTPS und die HTTPS-Automatisierung der Cloud-Plattform zu nutzen, muss zunächst die Anwendung bereitgestellt werden.

Nach dem Deployment öffnen Sie den Bereich für Networking oder Domains im Dashboard der Anwendung.

Im Folgenden finden Sie die typischen Schritte zur Einrichtung einer benutzerdefinierten Domain samt SSL auf einer verwalteten Anwendungsplattform:

1. Eine benutzerdefinierte Domain zur Anwendung hinzufügen

• Öffnen Sie das Control Panel des Cloud-Anbieters.
• Rufen Sie das Dashboard Ihrer Anwendung auf.
• Wählen Sie im Bereich Domains die Option zum Hinzufügen einer Domain.
• Geben Sie Ihre benutzerdefinierte Domain ein und bestätigen Sie die Änderung.

2. DNS-Einträge aktualisieren

Wechseln Sie zu Ihrem Domain-Registrar oder DNS-Anbieter und passen Sie die DNS-Einträge so an, dass die Domain auf die verwaltete Anwendungsplattform zeigt. Die Plattform stellt dafür in der Regel die notwendigen CNAME- oder A-Records bereit.

Die DNS-Propagation kann etwas Zeit in Anspruch nehmen, daher ist Geduld erforderlich.

Auch nachdem die Propagation abgeschlossen ist, kann es noch einige Minuten dauern, bis SSL aktiv wird. Falls HTTPS nicht sofort sichtbar ist, überprüfen Sie die DNS-Einstellungen, aktualisieren Sie das Plattform-Dashboard und warten Sie etwas länger auf die Übernahme der Änderungen.

3. Automatische Bereitstellung des SSL-Zertifikats

Sobald die DNS-Einträge korrekt gesetzt und vollständig propagiert sind, stellt die Anwendungsplattform automatisch ein SSL-Zertifikat für Ihre Domain bereit, meist über Let’s Encrypt.

Nach diesem Schritt sollte Ihre Anwendung unter https:// gefolgt von Ihrer benutzerdefinierten Domain erreichbar sein.

CSR-Dateien müssen nicht erstellt und Zertifikate nicht manuell installiert werden, da die Plattform den gesamten Vorgang übernimmt.

Sobald die benutzerdefinierte Domain korrekt eingerichtet ist, wird SSL/TLS automatisch bereitgestellt. Es ist also nicht erforderlich, Zertifikate selbst zu beantragen oder zu installieren.

Darüber hinaus leiten die meisten verwalteten Anwendungsplattformen eingehende HTTP-Anfragen automatisch auf HTTPS um, sodass Nutzer immer über sichere Verbindungen bedient werden.

SSL ist aktiv, wenn folgende Punkte erfüllt sind:

• Die Anwendung ist über https erreichbar, zum Beispiel unter https://www.myapp.com.
• In der Adressleiste des Browsers erscheint ein Schloss-Symbol.
• Der Browser kennzeichnet die Verbindung als sicher.

Die Anwendungsplattform übernimmt dabei meist automatisch die folgenden Aufgaben:

• Validierung des Domain-Besitzes
• Ausstellung eines SSL-Zertifikats über Let’s Encrypt
• Einrichtung der automatischen Erneuerung
• Konfiguration von Weiterleitungen von HTTP auf HTTPS
• Aktivierung von HSTS-Headern

Eine manuelle Zertifikatsverwaltung ist nicht notwendig. Die Plattform übernimmt den gesamten Lebenszyklus der Zertifikate.

Verwaltete Anwendungsplattformen überwachen Zertifikatslaufzeiten in der Regel selbst und erneuern Zertifikate automatisch, häufig etwa 30 Tage vor Ablauf. Es ist nicht notwendig, Cronjobs, systemd-Timer oder eigene Renewal-Skripte einzurichten.

Wie Cloud-Plattformen Zertifikatserneuerungen handhaben

Bei verwaltetem SSL auf Load Balancern und Anwendungsplattformen übernimmt der Cloud-Anbieter den gesamten Erneuerungszyklus:

Sowohl verwaltete SSL-Zertifikate auf Load Balancern als auch auf Anwendungsplattformen werden üblicherweise über Let’s Encrypt ausgestellt und automatisch erneuert. Darin liegt der wesentliche Unterschied zwischen verwaltetem SSL und Let’s Encrypt auf virtuellen Maschinen: Auf Servern kümmern Sie sich selbst um certbot, bei verwalteten Diensten übernimmt das die Cloud-Plattform.

Häufige SSL-Probleme beheben

Beim Vergleich von Load-Balancer-SSL und Anwendungsplattform-SSL gilt: Beide setzen auf verwaltete Zertifikate und automatische Erneuerung. Ein Load Balancer eignet sich für benutzerdefinierte Backend-Infrastrukturen, eine Anwendungsplattform für plattformverwaltete Anwendungen.

Sicherheits- und Performance-Best-Practices

Unabhängig davon, ob Sie Load-Balancer-SSL, SSL auf einer Anwendungsplattform oder DIY-Zertifikate nutzen, sollten die folgenden Sicherheits- und Performance-Empfehlungen umgesetzt werden.

HTTPS-Weiterleitungen erzwingen

Stellen Sie sicher, dass sämtlicher HTTP-Verkehr auf HTTPS umgeleitet wird. Auf Load Balancern geschieht das meist über Weiterleitungsregeln. Auf virtuellen Maschinen mit Nginx kann folgender Eintrag im Server-Block verwendet werden:

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

Dadurch werden alle HTTP-Anfragen dauerhaft per 301-Redirect auf HTTPS umgeleitet.

HSTS konfigurieren

HTTP Strict Transport Security, kurz HSTS, ist eine Browser-Richtlinie, die Clients dazu anweist, beim Zugriff auf eine Website immer HTTPS statt HTTP zu verwenden. Durch die Aktivierung von HSTS schützen Sie Nutzer besser vor Downgrade-Angriffen und dem Abgreifen von Cookies.

Um HSTS in Nginx auf einer virtuellen Maschine zu aktivieren, ergänzen Sie die folgende Direktive im HTTPS-Server-Block, also in dem Block, der auf Port 443 lauscht:

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

• max-age=31536000 weist Browser an, ein Jahr lang ausschließlich HTTPS zu verwenden.
• includeSubDomains erweitert diese Regel auf sämtliche Subdomains.
• preload signalisiert den Wunsch, in Browser-Preload-Listen aufgenommen zu werden, was HTTPS-only zusätzlich verstärkt.

Beispiel:

Platzieren Sie die add_header-Zeile innerhalb des HTTPS-Server-Blocks Ihrer Nginx-Konfigurationsdatei für die betreffende Domain und laden Sie anschließend Nginx neu, damit die Änderungen wirksam werden.

server {
    listen 443 ssl;
    server_name yourdomain.com www.yourdomain.com;

    # ...other SSL configuration...

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

    # ...other settings...
}

Damit werden Browser angewiesen, Ihre Website künftig bevorzugt immer per HTTPS aufzurufen, was die allgemeine Sicherheit verbessert.

Security Header

Zusätzlich empfiehlt es sich, Sicherheits-Header in die Serverkonfiguration aufzunehmen, um die Angriffsfläche gegenüber typischen Web-Angriffen zu verringern. In Nginx können beispielsweise die folgenden Header gesetzt werden:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Die einzelnen Header haben folgende Wirkung:

• X-Frame-Options “SAMEORIGIN”: Verhindert, dass Seiten von fremden Websites in Frames oder iFrames eingebettet werden, und reduziert so das Risiko von Clickjacking. Nur die eigene Website darf den Inhalt einbetten.
• X-Content-Type-Options “nosniff”: Weist Browser an, Dateitypen nicht selbst zu erraten, sondern ausschließlich dem angegebenen Content-Type zu folgen. Das schützt vor bestimmten Drive-by-Download-Angriffen.
• X-XSS-Protection “1; mode=block”: Aktiviert den browserseitigen Schutz vor Cross-Site-Scripting und weist den Browser an, die Seite zu blockieren, wenn ein Angriff erkannt wird, statt problematische Inhalte nur zu bereinigen.
• Referrer-Policy “strict-origin-when-cross-origin”: Steuert, wie viele Referrer-Informationen bei Anfragen mitgesendet werden. Bei same-origin-Anfragen wird der vollständige Referrer übermittelt, bei cross-origin-Anfragen nur der Ursprung, was den Datenschutz verbessert.

Fügen Sie diese Direktiven Ihrem Server hinzu, beispielsweise innerhalb des Nginx-Server-Blocks, damit Browser diese Schutzmaßnahmen für jede Antwort anwenden.

Mit nur wenigen Zeilen Konfiguration lässt sich die Sicherheitslage Ihrer Website dadurch deutlich verbessern.

Zertifikatsablauf überwachen

Auch wenn die automatische Verlängerung aktiv ist, sollten Ablaufdaten von Zertifikaten weiterhin überwacht werden, damit Probleme frühzeitig erkannt werden. Richten Sie Benachrichtigungen ein, die Sie informieren, wenn Zertifikate bald ablaufen.

Ablaufdaten von Zertifikaten prüfen

Bei Zertifikaten auf virtuellen Maschinen lässt sich das Ablaufdatum mit folgendem Befehl kontrollieren:

sudo certbot certificates

Ausgabe

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Found the following certs:
  Certificate Name: yourdomain.com
    Domains: yourdomain.com www.yourdomain.com
    Expiry Date: 2026-05-10 10:35:03+00:00 (VALID: 87 days)
    Certificate Path: /etc/letsencrypt/live/yourdomain.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/yourdomain.com/privkey.pem

Diese Ausgabe listet alle Zertifikate einschließlich ihrer Ablaufdaten und Speicherorte auf.

Warnmeldungen bei bald ablaufenden Zertifikaten einrichten

Erstellen Sie ein Monitoring-Skript, das die Restlaufzeit eines Zertifikats überprüft:

#!/bin/bash
DOMAIN="yourdomain.com"
EXPIRY_DATE=$(echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:443" 2>/dev/null | openssl x509 -noout -dates | grep notAfter | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s)
CURRENT_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $CURRENT_EPOCH) / 86400 ))

if [ "$DAYS_LEFT" -lt 30 ]; then
    echo "WARNING: Certificate for $DOMAIN expires in $DAYS_LEFT days"
    # Send alert via email, Slack, or monitoring service
fi

Planen Sie dieses Skript so ein, dass es täglich per Cron ausgeführt wird:

0 9 * * * /path/to/check-cert-expiry.sh

Monitoring-Dienste verwenden

Monitoring-Dienste können ebenfalls auf Probleme mit Zertifikaten hinweisen. Konfigurieren Sie eine SSL-Zertifikatsüberwachung so, dass Benachrichtigungen versendet werden, wenn Zertifikate kurz vor dem Ablauf stehen oder es Validierungsprobleme gibt. Infrastruktur-Monitoring-Plattformen können solche Funktionen oft automatisch bereitstellen.

Wann verwaltetes SSL statt benutzerdefinierter Zertifikate sinnvoll ist

Der folgende Entscheidungsrahmen hilft dabei, zwischen verwaltetem SSL auf Load Balancern oder Anwendungsplattformen und benutzerdefinierten beziehungsweise Let’s-Encrypt-Zertifikaten auf virtuellen Maschinen zu wählen.

DIY auf virtuellen Maschinen wählen, wenn

• nur ein einzelner Server oder eine kleine Umgebung betrieben wird
• vollständige Kontrolle über die Zertifikatskonfiguration erforderlich ist
• Kosten die wichtigste Rolle spielen und Load-Balancer-Gebühren vermieden werden sollen
• Sie sich damit wohlfühlen, die Automatisierung der Erneuerung selbst zu pflegen

Verwaltetes SSL auf einem Load Balancer wählen, wenn

• mehrere Backend-Server vorhanden sind
• die SSL-Verarbeitung von den Anwendungssystemen ausgelagert werden soll
• hohe Verfügbarkeit und Redundanz erforderlich sind
• eine verwaltete Erneuerung gewünscht ist, ohne an die Grenzen einer vollständig verwalteten Anwendungsplattform gebunden zu sein

Automatisches SSL auf einer Anwendungsplattform wählen, wenn

• containerisierte oder serverlose Anwendungen bereitgestellt werden
• eine SSL-Verwaltung ohne zusätzliche Konfiguration gewünscht ist
• eine vollständig verwaltete Plattform bevorzugt wird
• neue Anwendungen aufgebaut werden, anstatt bestehende Infrastruktur zu migrieren

Migrationspfad

Wenn derzeit DIY-Zertifikate auf virtuellen Maschinen genutzt werden, kann der Umstieg wie folgt aussehen:

• Zu einem Load Balancer: Erstellen Sie den Load Balancer, fügen Sie die virtuellen Maschinen als Backend-Knoten hinzu, konfigurieren Sie SSL-Terminierung und aktualisieren Sie DNS so, dass die Domain auf die IP-Adresse des Load Balancers zeigt.
• Zu einer Anwendungsplattform: Stellen Sie die Anwendung auf der verwalteten Plattform bereit, fügen Sie die benutzerdefinierte Domain hinzu und lassen Sie die Plattform SSL automatisch verwalten.

Beide Migrationswege beseitigen den Bedarf an manueller Zertifikatspflege und erhalten oder verbessern gleichzeitig die Sicherheitslage der Anwendungsumgebung.

FAQs

Wie automatisiert man SSL-Zertifikate auf einer Cloud-Plattform?

SSL-Zertifikate lassen sich auf zwei Hauptwegen automatisieren, ohne certbot manuell auszuführen:

• Nutzen Sie einen Load Balancer mit SSL-Terminierung und wählen Sie Let’s Encrypt. Der Cloud-Anbieter stellt das Zertifikat automatisch bereit und erneuert es ebenfalls automatisch.
• Nutzen Sie eine verwaltete Anwendungsplattform und fügen Sie eine benutzerdefinierte Domain hinzu. HTTPS und Erneuerung werden dann automatisch aktiviert.

Auf virtuellen Maschinen erfolgt die Automatisierung üblicherweise mit certbot und entweder einem systemd-Timer oder einem Cronjob.

Erneuert ein Cloud-Anbieter SSL-Zertifikate automatisch?

Ja. Bei verwaltetem SSL auf Load Balancern und Anwendungsplattformen erneuern Cloud-Anbieter SSL-Zertifikate in der Regel automatisch, bevor sie ablaufen. Weder Cronjobs noch certbot müssen dafür selbst eingerichtet werden. Bei DIY-Let’s-Encrypt auf virtuellen Maschinen muss der Erneuerungstimer oder Cronjob manuell konfiguriert werden.

Wie funktioniert SSL auf einer verwalteten Anwendungsplattform?

Wenn in den Anwendungseinstellungen eine benutzerdefinierte Domain hinzugefügt wird, prüft die Plattform den Besitz, stellt ein SSL-Zertifikat über Let’s Encrypt bereit und aktiviert HTTPS einschließlich Weiterleitungen von HTTP auf HTTPS. Die Erneuerung erfolgt automatisch. Eine Load-Balancer-Konfiguration oder ein Zertifikatsupload ist nicht nötig, da die SSL-Automatisierung integriert ist.

Kann man benutzerdefinierte SSL-Zertifikate auf einer Cloud-Plattform verwenden?

Ja. Auf Load Balancern erlauben viele Anbieter das Hochladen eines eigenen Zertifikats, zum Beispiel von einer kommerziellen Zertifizierungsstelle, anstelle von Let’s Encrypt. Auf verwalteten Anwendungsplattformen werden Zertifikate in der Regel automatisch bereitgestellt, sobald eine Domain hinzugefügt wird. Auf virtuellen Maschinen kann sowohl Let’s Encrypt als auch ein benutzerdefiniertes Zertifikat mit Nginx oder Apache verwendet werden.

Was passiert, wenn ein SSL-Zertifikat abläuft?

Browser zeigen Sicherheitswarnungen an und können den Zugriff auf die Website verhindern. Bei verwaltetem SSL auf Load Balancern und Anwendungsplattformen wird die Erneuerung automatisch vorgenommen, sodass ein Ablauf normalerweise vermieden wird. Bei DIY-certbot sollten Monitoring und Reparatur des Erneuerungsprozesses eingerichtet werden, beispielsweise durch certbot renew, oder ein Umstieg auf verwaltetes SSL erfolgen.

Nutzen verwaltete Zertifikate Let’s Encrypt?

Ja. Sowohl verwaltete SSL-Zertifikate auf Load Balancern als auch auf Anwendungsplattformen werden häufig über Let’s Encrypt ausgestellt. Der Cloud-Anbieter übernimmt Validierung, Ausstellung und Erneuerung, sodass keine direkte Interaktion mit Let’s Encrypt notwendig ist.

Wie lange dauert es, bis SSL auf einer Cloud-Plattform aktiv ist?

Bei Load Balancern und Anwendungsplattformen ist die Zertifikatsbereitstellung in der Regel innerhalb weniger Minuten abgeschlossen, sobald DNS auf die korrekte Ressource zeigt. Die vollständige Aktivierung kann jedoch je nach DNS-Propagation und Validierung bis zu 24 bis 48 Stunden dauern.

Fazit

Die Verwaltung von SSL-Zertifikaten muss kein dauerhafter operativer Belastungsfaktor sein. Während der DIY-Ansatz mit Let’s Encrypt und Cronjobs für kleinere Umgebungen geeignet sein kann, bieten verwaltete Cloud-Lösungen in der Regel mehr Zuverlässigkeit und weniger Wartungsaufwand.

Load Balancer mit verwalteten SSL-Zertifikaten beseitigen die Komplexität der Erneuerung in Multi-Server-Umgebungen, während verwaltete Anwendungsplattformen den einfachsten Weg mit SSL-Verwaltung ohne zusätzliche Konfiguration bieten. Beide Optionen übernehmen Bereitstellung, Validierung und Erneuerung der Zertifikate automatisch.

Entscheidend ist, den passenden Ansatz für die eigene Infrastruktur zu wählen. Anwendungen auf einem einzelnen Server können mit DIY-Zertifikaten weiterhin gut funktionieren. Sobald Umgebungen wachsen oder betriebliche Einfachheit wichtiger wird, gewinnen verwaltete Lösungen jedoch deutlich an Wert. Unabhängig von der gewählten Methode sollten HTTPS-Weiterleitungen und HSTS-Header als Sicherheitsmaßnahmen konsequent umgesetzt werden.

Auch bei automatisierten Erneuerungen sollten Zertifikatslaufzeiten weiterhin überwacht werden, damit Sonderfälle frühzeitig erkannt werden. Richten Sie Warnmeldungen ein und überprüfen Sie Ihre SSL-Konfiguration regelmäßig, damit Anwendungen sicher und zuverlässig erreichbar bleiben.