Modul 7 · 7.3
Deutsch
https mit Let's Encrypt
Modul 7: Domain, Webserver und https · Lesezeit: 12 Minuten
Lernziel: Nach dieser Lektion können Sie mit certbot ein kostenloses Zertifikat von Let's Encrypt für nginx beantragen, http auf https umleiten, die automatische Verlängerung prüfen und die häufigsten Fehler bei einer Beantragung beheben.
Kernbegriffe: Zertifikat, Zertifizierungsstelle (CA), ACME, Let's Encrypt, Domainvalidierung, HTTP-01, DNS-01, TLS-ALPN-01, certbot, Verlängerung, certbot renew --dry-run, Laufzeit, ARI, Rate Limits, Staging, CAA, Umleitung auf https
Warum https, und was ein Zertifikat beweist
Ohne https läuft alles zwischen Browser und Server unverschlüsselt über das Netzwerk: Passwörter, Formulare, Cookies. Jeder auf dem Weg dazwischen (ein öffentliches WLAN, ein gehackter Router) kann mitlesen oder etwas verändern. Browser kennzeichnen http-Websites deshalb als "nicht sicher", und manche Funktionen arbeiten nur über https. Für einen Passwort-Tresor wie Vaultwarden (Lektion 9.4) ist https sogar Pflicht.
https verwendet TLS, und dafür braucht Ihr Server ein Zertifikat: einen Nachweis, unterschrieben von einer Zertifizierungsstelle (CA), der Browser vertrauen, dass dieser Schlüssel zu diesem Namen gehört. Ein gewöhnliches Zertifikat beweist nur, dass der Antragsteller den Domainnamen verwaltet (Domainvalidierung). Es sagt nichts darüber aus, wer Sie sind oder ob Sie vertrauenswürdig sind.
Let's Encrypt ist eine kostenlose CA, die ausschließlich domainvalidierte Zertifikate ausstellt, vollständig automatisch über das ACME-Protokoll. Ein Programm auf Ihrem Server (der ACME-Client) beantragt das Zertifikat, weist nach, dass er den Namen verwaltet, installiert es und verlängert es rechtzeitig. Diese Lektion verwendet certbot, den Client der EFF. Caddy (Lektion 7.4) hat einen ACME-Client eingebaut.
Wie weisen Sie nach, dass Sie den Namen verwalten?
Let's Encrypt kennt drei Arten von Challenges:
| Challenge | Wie | Port | Wildcard (*.example.com) |
|---|---|---|---|
| HTTP-01 | eine Datei unter http://<naam>/.well-known/acme-challenge/ ablegen | 80 | nein |
| DNS-01 | einen TXT-Record _acme-challenge.<naam> setzen | keiner | ja |
| TLS-ALPN-01 | während des TLS-Handshakes ein spezielles Zertifikat vorzeigen | 443 | nein |
Für einen gewöhnlichen VPS mit einer Website ist HTTP-01 am einfachsten. Dafür muss:
- der Name per A (und AAAA) auf Ihren Server zeigen (Lektion 7.1);
- Port 80 offen sein, und zwar für die ganze Welt, auch wenn Ihre Website ansonsten nur https verwendet. Let's Encrypt validiert nur über Port 80 und von mehreren Standorten im Internet aus; diese Adressen können Sie nicht in Ihrer Firewall freigeben;
- Ihr Server über IPv4 und IPv6 gleich antworten. Hat der Name einen AAAA-Record, versucht Let's Encrypt zuerst IPv6. Nur wenn über IPv6 überhaupt keine Verbindung zustande kommt, weicht es auf IPv4 aus.
DNS-01 benötigen Sie für ein Wildcard-Zertifikat oder wenn der Server von außen nicht erreichbar ist. Dann muss der ACME-Client Ihr DNS ändern können, meist über einen API-Schlüssel Ihres DNS-Anbieters. Dieser Schlüssel kann Ihr gesamtes DNS ändern: Bewahren Sie ihn genauso sorgfältig auf wie ein Passwort.
certbot installieren
Die Entwickler von certbot empfehlen den Snap, weil er immer die neueste Version enthält. Unter Debian und Ubuntu geht es auch ganz normal aus der Paketquelle:
anna@web1:~$ sudo apt install certbot python3-certbot-nginxDie Version aus der Distribution ist älter, erhält aber Sicherheitsupdates über apt (Lektion 4.1 und 4.2), und das passt zum Rest dieses Kurses. Wählen Sie eine der beiden Varianten, nicht beide: Zwei Installationen kommen sich beim Verlängern in die Quere.
Ein Zertifikat beantragen
Mit der Website aus Lektion 7.2, die bereits auf Port 80 läuft:
anna@web1:~$ sudo certbot --nginx -d example.com -d www.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address or hit Enter to skip.
(Enter 'c' to cancel):
...
Requesting a certificate for example.com and www.example.com
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
This certificate expires on 2027-02-07.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Successfully deployed certificate for example.com to /etc/nginx/sites-enabled/example.com
Successfully deployed certificate for www.example.com to /etc/nginx/sites-enabled/example.com
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com(Datum und Details sind ein Beispiel.) Das Plug-in --nginx erledigt drei Dinge: Es stellt vorübergehend die Challenge bereit, holt das Zertifikat ab und passt Ihren Server-Block mit einem listen 443 ssl-Block und einer Umleitung von http auf https an. Möchten Sie das lieber selbst erledigen, verwenden Sie certbot certonly --nginx und tragen die Zeilen selbst in Ihre Konfiguration ein.
Einige Punkte, auf die Sie achten sollten:
- Beantragen Sie alle Namen auf einmal, die zur Website gehören (
-dpro Name). Jeder Name muss auf den Server zeigen, sonst schlägt die gesamte Beantragung fehl. - Der private Schlüssel (
privkey.pem) liegt in/etc/letsencrypt/live/und ist nur für root lesbar. Kopieren Sie ihn nicht an andere Orte und legen Sie ihn niemals in einem Backup ab, das andere lesen können. - Die E-Mail-Adresse ist optional. Let's Encrypt verschickt seit Juni 2025 keine E-Mails mehr, wenn ein Zertifikat bald abläuft. Sie müssen also selbst überwachen, dass die Verlängerung klappt (Lektion 8.3).
http auf https umleiten
Nach certbot sieht Ihre Konfiguration ungefähr so aus (bereinigt; certbot fügt selbst Kommentare # managed by Certbot und manchmal if-Zeilen hinzu):
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
root /var/www/example.com;
...
}Der erste Block leitet alles über http auf denselben Namen und denselben Pfad über https um, mit einer dauerhaften Weiterleitung (301). Die Challenge-Datei für die Verlängerung funktioniert trotzdem: Let's Encrypt folgt dieser Weiterleitung. Der zweite Block ist die eigentliche Website. Möchten Sie zusätzlich www auf den Namen ohne Präfix umleiten (oder umgekehrt), tun Sie das in einem eigenen Block, damit Besucher einen festen Namen sehen.
Verlängern: automatisch, und kontrollieren
Ein Zertifikat von Let's Encrypt ist derzeit 90 Tage gültig. Das wird kürzer: Let's Encrypt hat angekündigt, dass das Standardprofil ab dem 10. Februar 2027 Zertifikate mit 64 Tagen und ab dem 16. Februar 2028 mit 45 Tagen Laufzeit ausstellt. Manuelles Verlängern ist also keine Option; es muss automatisch geschehen.
certbot richtet bei der Installation einen systemd-Timer (oder einen Cron-Eintrag) ein, der zweimal täglich prüft, ob ein Zertifikat verlängert werden muss. Kontrollieren Sie, dass dieser vorhanden ist, und testen Sie die Verlängerung mit einer Probeanfrage:
anna@web1:~$ systemctl list-timers 'certbot*'
NEXT LEFT LAST PASSED UNIT ACTIVATES
Mon 2026-11-09 22:41:00 CET 9h left - - certbot.timer certbot.service
anna@web1:~$ sudo certbot renew --dry-run
...
Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/example.com/fullchain.pem (success)Nach der Verlängerung muss nginx das neue Zertifikat auch laden. Mit dem nginx-Plug-in regelt certbot das selbst; verwenden Sie certonly, richten Sie einen Deploy-Hook ein, der nginx neu lädt, zum Beispiel ein ausführbares Skript in /etc/letsencrypt/renewal-hooks/deploy/ mit systemctl reload nginx.
Gute ACME-Clients nutzen ARI (ACME Renewal Information): Let's Encrypt gibt dann selbst an, wann ein Zertifikat verlängert werden muss, zum Beispiel früher, wenn mit einer Reihe von Zertifikaten etwas nicht stimmt. Halten Sie Ihren Client deshalb aktuell.
Wenn eine Beantragung fehlschlägt
| Meldung (gekürzt) | Ursache | Lösung |
|---|---|---|
Timeout during connect (likely firewall problem) | Port 80 geschlossen, oder der Name zeigt auf eine andere Adresse | Firewall (Lektion 5.2), A/AAAA (Lektion 7.1) |
Invalid response from http://.../.well-known/acme-challenge/...: 404 | ein anderer Server oder ein anderer Server-Block antwortet, oft über IPv6 | listen [::]:80, AAAA-Record prüfen |
CAA record for example.com prevents issuance | ein CAA-Record erlaubt nur eine andere Zertifizierungsstelle | CAA anpassen (Lektion 7.1) |
too many certificates already issued | ein Rate Limit | warten; mit Staging testen |
Let's Encrypt hat Rate Limits, um Missbrauch zu verhindern. Die wichtigsten: höchstens 50 neue Zertifikate pro registrierter Domain innerhalb von 7 Tagen, höchstens 5 Zertifikate für genau dieselbe Gruppe von Namen innerhalb von 7 Tagen und höchstens 5 fehlgeschlagene Validierungen pro Name und Stunde. Wer herumprobiert und immer wieder neu beantragt, stößt schnell an diese Grenzen. Testen Sie deshalb mit der Staging-Umgebung, die viel großzügigere Grenzen hat, aber Zertifikate ausstellt, denen Browser nicht vertrauen:
anna@web1:~$ sudo certbot certonly --nginx --staging -d test.example.comFunktioniert es dort, beantragen Sie das echte Zertifikat.
Unter AlmaLinux und Rocky Linux
certbot kommt dort aus EPEL (dnf install certbot python3-certbot-nginx) oder als Snap. Das Plug-in und die Befehle sind identisch. Denken Sie an firewalld (--add-service=http --add-service=https) und an SELinux, wenn Zertifikate an einem ungewöhnlichen Ort liegen.
In der Praxis
Bei einem Hosting-Paket kümmert sich das Panel um das Zertifikat (bei WebOké und bei anderen Hostinganbietern mit DirectAdmin, cPanel oder Plesk). Auf einem VPS erledigen Sie das selbst, mit certbot, Caddy oder dem ACME-Client, der zu Ihrer Software gehört. Das gilt bei jedem Anbieter.
Zusammenfassung
- Ein Zertifikat von Let's Encrypt beweist, dass Sie den Namen verwalten; certbot beantragt, installiert und verlängert es über ACME.
- HTTP-01 braucht einen für alle offenen Port 80 und dieselbe Antwort über IPv4 und IPv6; DNS-01 ist für Wildcards.
certbot --nginx -d ... -d ...regelt Zertifikat und Umleitung auf https; beantragen Sie alle Namen einer Website auf einmal.- Zertifikate sind derzeit 90 Tage gültig, und die Laufzeit wird kürzer; prüfen Sie den Timer und
certbot renew --dry-run, und überwachen Sie das Ablaufdatum selbst. - Testen Sie mit
--staging, um Rate Limits zu vermeiden; achten Sie auf CAA.
Quiz
Aufgabe
Aufgabe Z7.3: https mit einem gültigen Zertifikat. Beantragen Sie für Ihre Website ein Zertifikat (mit certbot oder Caddy), leiten Sie http auf https um und testen Sie die Verlängerung mit certbot renew --dry-run (bei Caddy: Prüfen Sie in den Logs, ob das Zertifikat abgerufen wurde). Geben Sie den Namen Ihrer Website ein. Das Programm baut eine TLS-Verbindung zu Port 443 auf und prüft, ob das Zertifikat gültig ist, von einer vertrauenswürdigen Zertifizierungsstelle unterschrieben wurde und Ihren Namen abdeckt, und ruft anschließend http://<naam>/ ab, um zu sehen, ob Sie auf https umleiten. Zusätzlich geben Sie an, wann Ihr Zertifikat abläuft und wie die Verlängerung bei Ihnen geregelt ist.
Weiterführende Informationen
- SSL-Zertifikat aktivieren, erneuern und Probleme beheben
- Kostenloser DNS-Kurs 5.2: CAA: Wer darf Zertifikate ausstellen?
- Let's Encrypt, Challenge Types: https://letsencrypt.org/docs/challenge-types/
- Let's Encrypt, Rate Limits: https://letsencrypt.org/docs/rate-limits/
- Let's Encrypt, Decreasing Certificate Lifetimes to 45 Days: https://letsencrypt.org/2025/12/02/from-90-to-45
- Certbot-Anleitung (nginx): https://certbot.eff.org/instructions?ws=nginx&os=snap
