{"id":125,"date":"2026-06-14T16:17:27","date_gmt":"2026-06-14T16:17:27","guid":{"rendered":"https:\/\/shattered.io\/de\/2026\/06\/14\/lets-encrypt-zertifikat-einrichten\/"},"modified":"2026-06-14T16:19:02","modified_gmt":"2026-06-14T16:19:02","slug":"lets-encrypt-zertifikat-einrichten","status":"publish","type":"post","link":"https:\/\/shattered.io\/de\/2026\/06\/14\/lets-encrypt-zertifikat-einrichten\/","title":{"rendered":"Let&#8217;s Encrypt: Zertifikat in 12 Schritten [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Ein g\u00fcltiges TLS-Zertifikat kostet 2026 keinen Cent mehr, und die Einrichtung dauert weniger als 15 Minuten. <strong>Let&#8217;s Encrypt<\/strong> hat das Web umgekrempelt: Wo Administratoren fr\u00fcher dreistellige Betr\u00e4ge pro Jahr und Domain zahlten, stellt die gemeinn\u00fctzige Internet Security Research Group (ISRG) Zertifikate kostenlos, automatisiert und in Sekunden aus. Diese Anleitung f\u00fchrt Sie in 12 klar nummerierten Schritten durch die komplette Einrichtung mit Certbot, von der Installation \u00fcber das erste Nginx- und Apache-Zertifikat bis zu Wildcard-Zertifikaten per DNS-01 und der vollautomatischen Erneuerung.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wir nutzen ausschlie\u00dflich Daten und Verfahren aus 2025 und 2026. Dazu geh\u00f6ren die neuen sechst\u00e4gigen Kurzl\u00e4ufer-Zertifikate, die Zertifikate f\u00fcr reine IP-Adressen und die Umstellung von OCSP auf Sperrlisten (CRL). Am Ende steht ein vollst\u00e4ndiges, lauff\u00e4higes Beispielprojekt: ein abgesicherter Nginx-Reverse-Proxy mit automatischer HTTPS-Erneuerung. Dazu kommen 6 typische Fehler, 8 Troubleshooting-F\u00e4lle und fortgeschrittene Tipps f\u00fcr den Produktivbetrieb.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"lets-encrypt-2026-was-sich-gerade-geaendert-hat\">Let&#8217;s Encrypt 2026: Was sich gerade ge\u00e4ndert hat<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Let&#8217;s Encrypt ist ein Projekt der gemeinn\u00fctzigen Internet Security Research Group (ISRG) und z\u00e4hlt zu den gr\u00f6\u00dften Zertifizierungsstellen der Welt. Das Vertrauensanker-Zertifikat hei\u00dft ISRG Root X1, darunter rotiert die CA aktuell acht Zwischenzertifikate. F\u00fcr Administratoren im DACH-Raum ist die Kernbotschaft simpel: Zertifikate sind kostenlos, automatisch erneuerbar und in allen g\u00e4ngigen Browsern und Betriebssystemen vorinstalliert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">2025 und 2026 brachten mehrere \u00c4nderungen, die Sie kennen sollten, bevor Sie loslegen. Die wichtigste betrifft die Lebensdauer: Neben dem klassischen 90-Tage-Zertifikat gibt es jetzt ein Profil f\u00fcr sechst\u00e4gige Kurzl\u00e4ufer-Zertifikate. Solche Kurzl\u00e4ufer reduzieren das Risiko bei kompromittierten Schl\u00fcsseln drastisch, setzen aber zwingend eine funktionierende Automatisierung voraus. Wer noch manuell erneuert, sollte die Finger davon lassen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ebenfalls neu: Let&#8217;s Encrypt stellt seit 2025 Zertifikate f\u00fcr reine IP-Adressen aus. Das ist n\u00fctzlich f\u00fcr interne Dienste, Mailgateways oder Hosts ohne Domainnamen. Auf der Betriebsseite hat die CA 2025 den OCSP-Dienst eingestellt und setzt nun auf Zertifikatssperrlisten (CRL). Auch die Ablauf-Erinnerungsmails wurden mitte 2025 abgeschaltet. Die klare Konsequenz: Verlassen Sie sich nie auf eine E-Mail, sondern auf eine robuste automatische Erneuerung. Genau die richten wir in dieser Anleitung ein.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Eigenschaft<\/th><th>Klassisch<\/th><th>Kurzl\u00e4ufer (2025\/26)<\/th><th>IP-Zertifikat (2025)<\/th><\/tr><\/thead><tbody><tr><td>G\u00fcltigkeit<\/td><td>90 Tage<\/td><td>6 Tage<\/td><td>6 Tage<\/td><\/tr><tr><td>Profilname<\/td><td>classic \/ tlsserver<\/td><td>shortlived<\/td><td>shortlived<\/td><\/tr><tr><td>Erneuerung empfohlen ab<\/td><td>Tag 60<\/td><td>alle 2 bis 3 Tage<\/td><td>alle 2 bis 3 Tage<\/td><\/tr><tr><td>Automatisierung<\/td><td>dringend empfohlen<\/td><td>zwingend<\/td><td>zwingend<\/td><\/tr><tr><td>Anwendungsfall<\/td><td>Standard-Websites<\/td><td>Hochsicherheit<\/td><td>Dienste ohne Domain<\/td><\/tr><tr><td>Validierung<\/td><td>HTTP-01 \/ DNS-01<\/td><td>HTTP-01 \/ DNS-01<\/td><td>HTTP-01 \/ TLS-ALPN-01<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\">Zertifikatsprofile von Let&#8217;s Encrypt im \u00dcberblick (Stand 2026).<\/figcaption><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"voraussetzungen-diese-versionen-brauchen-sie\">Voraussetzungen: Diese Versionen brauchen Sie<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bevor Sie das erste Zertifikat ausstellen, m\u00fcssen einige Grundlagen stimmen. Diese Anleitung geht von einem Linux-Server mit Root- oder sudo-Zugriff aus, weil das die h\u00e4ufigste Umgebung im DACH-Hosting ist. Die Befehle funktionieren analog auf macOS; f\u00fcr Windows-Server gibt es weiter unten einen eigenen Hinweis auf win-acme.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Betriebssystem:<\/strong> Ubuntu 24.04 LTS oder 22.04 LTS, Debian 12, oder eine vergleichbare Linux-Distribution. macOS 14+ funktioniert ebenfalls.<\/li><li><strong>Webserver:<\/strong> Nginx (ab Version 1.18) oder Apache (ab 2.4). Den Webserver-Typ brauchen Sie f\u00fcr die passenden Certbot-Plugins.<\/li><li><strong>Certbot:<\/strong> die aktuelle Version, installiert \u00fcber Snap. Snap liefert immer die neueste stabile Ausgabe inklusive automatischer Updates.<\/li><li><strong>Domain:<\/strong> eine registrierte Domain (zum Beispiel <code>beispiel.de<\/code>), deren A- oder AAAA-Record auf die \u00f6ffentliche IP des Servers zeigt.<\/li><li><strong>Offene Ports:<\/strong> Port 80 (TCP) f\u00fcr die HTTP-01-Validierung und Port 443 (TCP) f\u00fcr HTTPS. Beide m\u00fcssen aus dem Internet erreichbar sein.<\/li><li><strong>G\u00fcltige E-Mail:<\/strong> f\u00fcr Kontowarnungen, etwa bei dringenden Sicherheitsmeldungen der ISRG.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Pr\u00fcfen Sie zuerst, ob Ihre Domain korrekt aufgel\u00f6st wird. Ein falscher DNS-Eintrag ist die mit Abstand h\u00e4ufigste Fehlerquelle. Der folgende Befehl zeigt, auf welche IP Ihre Domain zeigt:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># DNS-Aufl\u00f6sung pr\u00fcfen\ndig +short beispiel.de A\ndig +short www.beispiel.de A\n\n# Erwartete Ausgabe: die \u00f6ffentliche IP Ihres Servers, z. B.\n# 203.0.113.42\n\n# Erreichbarkeit von Port 80 testen\ncurl -I http:\/\/beispiel.de<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Stimmt die ausgegebene IP nicht mit der Server-IP \u00fcberein, korrigieren Sie zuerst den DNS-Eintrag bei Ihrem Provider und warten Sie, bis die \u00c4nderung propagiert ist. Erst danach lohnt sich der n\u00e4chste Schritt. Wer das \u00fcberspringt, l\u00e4uft direkt in eine fehlgeschlagene Validierung.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"wie-das-acme-protokoll-und-certbot-zusammenarbeiten\">Wie das ACME-Protokoll und Certbot zusammenarbeiten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die Automatisierung hinter Let&#8217;s Encrypt basiert auf dem ACME-Protokoll (Automatic Certificate Management Environment), standardisiert in RFC 8555. Certbot ist der offizielle ACME-Client der Electronic Frontier Foundation (EFF). Vereinfacht l\u00e4uft der Ablauf so: Certbot erzeugt ein Schl\u00fcsselpaar, fordert bei Let&#8217;s Encrypt ein Zertifikat an und muss anschlie\u00dfend beweisen, dass Sie tats\u00e4chlich die Kontrolle \u00fcber die Domain haben. Diesen Beweis nennt man Challenge.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es gibt drei Challenge-Typen, und die Wahl entscheidet \u00fcber den weiteren Verlauf. HTTP-01 legt eine Datei unter einem bestimmten Pfad ab, die Let&#8217;s Encrypt \u00fcber Port 80 abruft. DNS-01 hinterlegt einen TXT-Record in Ihrer Zone und ist die einzige Methode f\u00fcr Wildcard-Zertifikate. TLS-ALPN-01 nutzt eine spezielle TLS-Erweiterung auf Port 443 und ist vor allem f\u00fcr Reverse-Proxys interessant. Die folgende Tabelle ordnet die Verfahren ein.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Challenge<\/th><th>Port<\/th><th>Wildcard m\u00f6glich<\/th><th>Ideal f\u00fcr<\/th><th>Nachteil<\/th><\/tr><\/thead><tbody><tr><td>HTTP-01<\/td><td>80<\/td><td>Nein<\/td><td>einzelne Websites<\/td><td>Port 80 muss offen sein<\/td><\/tr><tr><td>DNS-01<\/td><td>53 (DNS)<\/td><td>Ja<\/td><td>Wildcards, interne Hosts<\/td><td>API-Zugang zum DNS n\u00f6tig<\/td><\/tr><tr><td>TLS-ALPN-01<\/td><td>443<\/td><td>Nein<\/td><td>Reverse-Proxys<\/td><td>kein Webserver-Plugin<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\">Die drei ACME-Challenge-Typen nach RFC 8555 im Vergleich.<\/figcaption><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr die meisten Websites ist HTTP-01 die einfachste Wahl, weil Certbot mit den Nginx- und Apache-Plugins alles automatisch erledigt: Validierung, Eintrag in die Serverkonfiguration und Neustart. Wildcard-Zertifikate wie <code>*.beispiel.de<\/code> erfordern dagegen zwingend DNS-01. Behalten Sie au\u00dferdem die Limits im Blick: Let&#8217;s Encrypt erlaubt 50 Zertifikate pro registrierter Domain in 7 Tagen, und ein einzelnes Zertifikat darf bis zu 100 Identifier (DNS-Namen oder IP-Adressen) enthalten. Wer beim Testen zu oft wiederholt, sperrt sich selbst aus. Nutzen Sie daf\u00fcr die Staging-Umgebung, dazu sp\u00e4ter mehr.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-1-bis-3-certbot-ueber-snap-installieren\">Schritt 1 bis 3: Certbot \u00fcber Snap installieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 1: System aktualisieren und alte Pakete entfernen.<\/strong> Auf Ubuntu und Debian wird Certbot offiziell \u00fcber Snap installiert, nicht mehr \u00fcber apt. Entfernen Sie zuerst eventuell vorhandene apt-Pakete, damit es keine Versionskonflikte gibt.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 1: System aktualisieren\nsudo apt update &amp;&amp; sudo apt upgrade -y\n\n# Alte apt-Version von Certbot entfernen, falls vorhanden\nsudo apt remove certbot -y\n\n# snapd installieren (auf Ubuntu meist vorhanden)\nsudo apt install snapd -y\nsudo snap install core\nsudo snap refresh core<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 2: Certbot per Snap installieren.<\/strong> Der folgende Befehl holt die aktuelle stabile Version und h\u00e4lt sie \u00fcber die Snap-Automatik selbstst\u00e4ndig aktuell. Mit dem Symlink wird der Befehl <code>certbot<\/code> systemweit verf\u00fcgbar.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 2: Certbot installieren\nsudo snap install --classic certbot\n\n# Symlink anlegen, damit \"certbot\" im PATH liegt\nsudo ln -s \/snap\/bin\/certbot \/usr\/bin\/certbot\n\n# Version pr\u00fcfen\ncertbot --version\n# Beispielausgabe: certbot 3.x.x<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 3: Webserver-Plugin freigeben.<\/strong> Die Plugins f\u00fcr Nginx und Apache sind im Snap bereits enthalten. Falls Sie ein DNS-Plugin f\u00fcr Wildcard-Zertifikate brauchen, installieren Sie es separat und verbinden es mit Certbot. Beispiel f\u00fcr Cloudflare:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 3: DNS-Plugin (Beispiel Cloudflare) installieren\nsudo snap set certbot trust-plugin-with-root=ok\nsudo snap install certbot-dns-cloudflare\n\n# Verf\u00fcgbare Plugins anzeigen\ncertbot plugins<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Ausgabe von <code>certbot plugins<\/code> listet unter anderem <code>nginx<\/code>, <code>apache<\/code> und das eben installierte <code>dns-cloudflare<\/code> auf. Damit ist die Werkzeugkette komplett. In den n\u00e4chsten Schritten stellen wir das erste echte Zertifikat aus.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-4-bis-6-erstes-nginx-zertifikat-ausstellen\">Schritt 4 bis 6: Erstes Nginx-Zertifikat ausstellen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 4: Mit der Staging-Umgebung testen.<\/strong> Bevor Sie ein echtes Zertifikat anfordern, sollten Sie den Ablauf gegen das Staging-System testen. Staging hat gro\u00dfz\u00fcgige Limits und sch\u00fctzt Sie vor einer Sperre durch zu viele Fehlversuche. Das Zertifikat ist nicht \u00f6ffentlich vertrauensw\u00fcrdig, der Ablauf ist aber identisch.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 4: Testlauf gegen die Staging-Umgebung\nsudo certbot --nginx \\\n  --staging \\\n  -d beispiel.de -d www.beispiel.de \\\n  --agree-tos \\\n  -m admin@beispiel.de \\\n  --no-eff-email\n\n# Erfolg sieht so aus:\n# The dry run was successful.\n# Congratulations! Your certificate (staging) has been issued.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 5: Das echte Zertifikat anfordern.<\/strong> Lief der Staging-Test sauber durch, entfernen Sie das Flag <code>--staging<\/code> und fordern das produktive Zertifikat an. Certbot tr\u00e4gt es automatisch in die Nginx-Konfiguration ein, richtet die Weiterleitung von HTTP auf HTTPS ein und l\u00e4dt Nginx neu.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 5: Produktives Zertifikat ausstellen\nsudo certbot --nginx \\\n  -d beispiel.de -d www.beispiel.de \\\n  --agree-tos \\\n  -m admin@beispiel.de \\\n  --no-eff-email \\\n  --redirect\n\n# Ergebnis:\n# Successfully received certificate.\n# Certificate is saved at: \/etc\/letsencrypt\/live\/beispiel.de\/fullchain.pem\n# Key is saved at:         \/etc\/letsencrypt\/live\/beispiel.de\/privkey.pem\n# This certificate expires on 2026-09-12.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 6: Das Ergebnis pr\u00fcfen.<\/strong> Rufen Sie Ihre Domain im Browser per <code>https:\/\/<\/code> auf. Sie sollten ein g\u00fcltiges Schloss-Symbol sehen. Auf der Kommandozeile pr\u00fcfen Sie das Zertifikat so:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 6: Zertifikat und Kette pr\u00fcfen\necho | openssl s_client -connect beispiel.de:443 -servername beispiel.de 2&gt;\/dev\/null \\\n  | openssl x509 -noout -issuer -subject -dates\n\n# Beispielausgabe:\n# issuer=C=US, O=Let's Encrypt, CN=R11\n# subject=CN=beispiel.de\n# notBefore=Jun 14 09:00:00 2026 GMT\n# notAfter=Sep 12 09:00:00 2026 GMT<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Sehen Sie als Aussteller (issuer) Let&#8217;s Encrypt und eine Restlaufzeit von rund 90 Tagen, ist alles korrekt. F\u00fcr eine ausf\u00fchrliche externe Bewertung der TLS-Konfiguration nutzen Sie den kostenlosen <a href=\"https:\/\/www.ssllabs.com\/ssltest\/\" target=\"_blank\" rel=\"noopener\">SSL Labs Server Test<\/a>, der Ihnen eine Note von A+ bis F gibt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-7-bis-9-apache-zertifikat-einrichten\">Schritt 7 bis 9: Apache-Zertifikat einrichten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Apache funktioniert nach demselben Prinzip, nutzt aber das Apache-Plugin. Voraussetzung ist ein konfigurierter VirtualHost mit dem korrekten <code>ServerName<\/code>, denn Certbot liest diesen Wert aus, um die passende Konfigurationsdatei zu finden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 7: Apache und das Plugin vorbereiten.<\/strong> Stellen Sie sicher, dass die Module f\u00fcr SSL und Header aktiv sind. Das Apache-Plugin steuert Apache anschlie\u00dfend selbst.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 7: Apache-Module aktivieren\nsudo a2enmod ssl\nsudo a2enmod headers\nsudo systemctl restart apache2\n\n# Pr\u00fcfen, ob der VirtualHost den richtigen ServerName hat\nsudo apache2ctl -S<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 8: Zertifikat f\u00fcr Apache ausstellen.<\/strong> Der Aufruf ist nahezu identisch zu Nginx, nur das Plugin wechselt von <code>--nginx<\/code> auf <code>--apache<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 8: Zertifikat \u00fcber das Apache-Plugin\nsudo certbot --apache \\\n  -d beispiel.de -d www.beispiel.de \\\n  --agree-tos \\\n  -m admin@beispiel.de \\\n  --no-eff-email \\\n  --redirect<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 9: Nur Zertifikat holen, Konfiguration selbst pflegen.<\/strong> Wer die Webserver-Konfiguration manuell verwaltet, etwa in einer Versionsverwaltung, nutzt den Modus <code>certonly<\/code>. Certbot stellt dann nur das Zertifikat aus und fasst die Server-Dateien nicht an.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 9: Nur Zertifikat ausstellen (webroot-Methode)\nsudo certbot certonly --webroot \\\n  -w \/var\/www\/beispiel \\\n  -d beispiel.de -d www.beispiel.de \\\n  --agree-tos -m admin@beispiel.de --no-eff-email\n\n# Die Pfade danach manuell in die Konfiguration eintragen:\n# SSLCertificateFile    \/etc\/letsencrypt\/live\/beispiel.de\/fullchain.pem\n# SSLCertificateKeyFile \/etc\/letsencrypt\/live\/beispiel.de\/privkey.pem<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die <code>certonly<\/code>-Methode ist die robusteste Variante f\u00fcr komplexe Setups, weil sie Certbot von der Webserver-Konfiguration entkoppelt. Sie eignet sich auch f\u00fcr Dienste, die kein Webserver-Plugin haben, etwa Mailserver oder Datenbanken mit TLS.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-10-bis-12-wildcard-zertifikat-per-dns-01\">Schritt 10 bis 12: Wildcard-Zertifikat per DNS-01<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Wildcard-Zertifikat wie <code>*.beispiel.de<\/code> deckt alle Subdomains mit einem einzigen Zertifikat ab. Das spart Verwaltungsaufwand und schont das Limit von 50 Zertifikaten pro Woche. Der Haken: Wildcards erfordern zwingend die DNS-01-Validierung, also einen TXT-Record in Ihrer Zone. Vollautomatisch geht das nur mit einem DNS-Plugin und API-Zugang zu Ihrem DNS-Provider.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 10: API-Zugangsdaten hinterlegen.<\/strong> Erstellen Sie bei Ihrem DNS-Provider einen API-Token mit Schreibrechten f\u00fcr die Zone und speichern ihn in einer gesch\u00fctzten Datei. Beispiel f\u00fcr Cloudflare:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 10: Cloudflare-Token sicher ablegen\nsudo mkdir -p \/etc\/letsencrypt\/secrets\necho \"dns_cloudflare_api_token = IHR_API_TOKEN\" \\\n  | sudo tee \/etc\/letsencrypt\/secrets\/cloudflare.ini\n\n# Strenge Rechte setzen (nur root darf lesen)\nsudo chmod 600 \/etc\/letsencrypt\/secrets\/cloudflare.ini<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 11: Wildcard-Zertifikat anfordern.<\/strong> Geben Sie sowohl die Wildcard als auch die nackte Domain an, da <code>*.beispiel.de<\/code> die Domain <code>beispiel.de<\/code> selbst nicht einschlie\u00dft.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 11: Wildcard-Zertifikat per DNS-01\nsudo certbot certonly \\\n  --dns-cloudflare \\\n  --dns-cloudflare-credentials \/etc\/letsencrypt\/secrets\/cloudflare.ini \\\n  -d \"beispiel.de\" -d \"*.beispiel.de\" \\\n  --agree-tos -m admin@beispiel.de --no-eff-email\n\n# Certbot setzt den TXT-Record automatisch:\n# _acme-challenge.beispiel.de  TXT  \"abc123...\"\n# und entfernt ihn nach der Pr\u00fcfung wieder.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Schritt 12: DNS-Propagation ber\u00fccksichtigen.<\/strong> Manche Provider brauchen l\u00e4nger, bis der TXT-Record sichtbar ist. Mit <code>--dns-cloudflare-propagation-seconds<\/code> geben Sie Certbot mehr Zeit. Bei langsamen Zonen helfen 60 Sekunden.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schritt 12: L\u00e4ngere Wartezeit f\u00fcr die DNS-Propagation\nsudo certbot certonly \\\n  --dns-cloudflare \\\n  --dns-cloudflare-credentials \/etc\/letsencrypt\/secrets\/cloudflare.ini \\\n  --dns-cloudflare-propagation-seconds 60 \\\n  -d \"beispiel.de\" -d \"*.beispiel.de\" \\\n  --agree-tos -m admin@beispiel.de --no-eff-email<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ohne API-Plugin l\u00e4sst sich DNS-01 auch manuell durchf\u00fchren (<code>--manual --preferred-challenges dns<\/code>). Certbot zeigt dann den zu setzenden TXT-Record an und wartet, bis Sie ihn eingetragen haben. Das ist f\u00fcr einmalige Zertifikate in Ordnung, eignet sich aber nicht f\u00fcr die automatische Erneuerung, weil bei jedem Lauf manuelle Eingriffe n\u00f6tig w\u00e4ren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"automatische-erneuerung-mit-systemd-timer-einrichten\">Automatische Erneuerung mit systemd-Timer einrichten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Da Let&#8217;s Encrypt keine Ablauf-Erinnerungen mehr verschickt, ist die automatische Erneuerung kein Komfort, sondern Pflicht. Bei einer Snap-Installation richtet Certbot den Erneuerungsmechanismus selbst ein. Mit dem folgenden Befehl pr\u00fcfen Sie, ob der Timer aktiv ist:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Aktive Certbot-Timer anzeigen\nsystemctl list-timers | grep certbot\n\n# Beispielausgabe:\n# snap.certbot.renew.timer  ... snap.certbot.renew.service\n\n# Erneuerung testen, ohne wirklich zu erneuern (Trockenlauf)\nsudo certbot renew --dry-run<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der Befehl <code>certbot renew<\/code> erneuert nur Zertifikate, deren Restlaufzeit unter 30 Tage f\u00e4llt. Er ist absichtlich idempotent: Sie k\u00f6nnen ihn beliebig oft laufen lassen, ohne unn\u00f6tig neue Zertifikate anzufordern. Genau deshalb l\u00e4uft er zweimal t\u00e4glich, ohne das Wochenlimit zu sprengen. Verlief der Trockenlauf erfolgreich, ist Ihr Server f\u00fcr Jahre versorgt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Auf Systemen ohne systemd, etwa in manchen Containern, richten Sie die Erneuerung per Cron ein. Wichtig ist der zuf\u00e4llige Versatz (<code>sleep<\/code>), damit nicht alle Server der Welt gleichzeitig anfragen:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Cron-Job als root: \/etc\/cron.d\/certbot\n# Zweimal t\u00e4glich, mit zuf\u00e4lligem Versatz bis 8 Stunden\n0 *\/12 * * * root sleep $(( RANDOM \\% 28800 )) &amp;&amp; certbot renew --quiet \\\n  --deploy-hook \"systemctl reload nginx\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der <code>--deploy-hook<\/code> ist entscheidend: Er l\u00e4dt den Webserver nur dann neu, wenn tats\u00e4chlich ein neues Zertifikat ausgestellt wurde. Ohne diesen Schritt w\u00fcrde der Server weiter das alte Zertifikat aus dem Speicher servieren, obwohl auf der Platte l\u00e4ngst ein neues liegt. Das ist ein klassischer Fehler, der erst beim Ablauf auff\u00e4llt, also im schlechtesten Moment.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"vollstaendiges-beispielprojekt-nginx-reverse-proxy-mit-tls\">Vollst\u00e4ndiges Beispielprojekt: Nginx-Reverse-Proxy mit TLS<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Jetzt f\u00fcgen wir alles zu einem lauff\u00e4higen Projekt zusammen: ein Nginx-Reverse-Proxy, der eine im Hintergrund laufende Anwendung (etwa eine Node.js-App auf Port 3000) per HTTPS nach au\u00dfen anbietet, inklusive moderner TLS-Einstellungen und Sicherheits-Header. Legen Sie zuerst die Serverkonfiguration an.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/nginx\/sites-available\/beispiel.de\nserver {\n    listen 80;\n    server_name beispiel.de www.beispiel.de;\n    # Let's Encrypt HTTP-01 Challenge zulassen\n    location \/.well-known\/acme-challenge\/ { root \/var\/www\/html; }\n    # alles andere auf HTTPS umleiten\n    location \/ { return 301 https:\/\/$host$request_uri; }\n}\n\nserver {\n    listen 443 ssl http2;\n    server_name beispiel.de www.beispiel.de;\n\n    ssl_certificate     \/etc\/letsencrypt\/live\/beispiel.de\/fullchain.pem;\n    ssl_certificate_key \/etc\/letsencrypt\/live\/beispiel.de\/privkey.pem;\n\n    # Moderne TLS-Einstellungen\n    ssl_protocols TLSv1.2 TLSv1.3;\n    ssl_prefer_server_ciphers off;\n    ssl_session_timeout 1d;\n    ssl_session_cache shared:MozSSL:10m;\n\n    # Sicherheits-Header\n    add_header Strict-Transport-Security \"max-age=63072000\" always;\n    add_header X-Content-Type-Options nosniff always;\n\n    location \/ {\n        proxy_pass http:\/\/127.0.0.1:3000;\n        proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-Proto $scheme;\n    }\n}<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Aktivieren Sie die Konfiguration, pr\u00fcfen Sie die Syntax und laden Sie Nginx neu. Der Syntaxtest vor dem Reload verhindert, dass ein Tippfehler den gesamten Webserver lahmlegt.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Konfiguration aktivieren\nsudo ln -s \/etc\/nginx\/sites-available\/beispiel.de \\\n           \/etc\/nginx\/sites-enabled\/\n\n# Syntax pr\u00fcfen, dann neu laden\nsudo nginx -t\nsudo systemctl reload nginx\n\n# Zertifikat ausstellen (HTTP-01 nutzt den well-known-Pfad oben)\nsudo certbot --nginx -d beispiel.de -d www.beispiel.de \\\n  --agree-tos -m admin@beispiel.de --no-eff-email --redirect<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Damit haben Sie einen produktionsreifen Reverse-Proxy: HTTP-Anfragen werden auf HTTPS umgeleitet, die Verbindung nutzt TLS 1.2 und 1.3, HSTS erzwingt verschl\u00fcsselte Folgeaufrufe, und die automatische Erneuerung h\u00e4lt das Zertifikat dauerhaft g\u00fcltig. Diese Vorlage l\u00e4sst sich f\u00fcr beliebige Backend-Dienste anpassen, indem Sie den <code>proxy_pass<\/code>-Zielport \u00e4ndern. Wenn Sie tiefer verstehen wollen, was hinter dem Schloss-Symbol passiert, lesen Sie unseren Beitrag zu <a href=\"\/de\/https-und-tls\/\">HTTPS und TLS<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"6-haeufige-fehler-und-wie-sie-sie-vermeiden\">6 h\u00e4ufige Fehler und wie Sie sie vermeiden<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die meisten Probleme mit <strong>Let&#8217;s Encrypt<\/strong> entstehen nicht durch Certbot selbst, sondern durch das Umfeld: DNS, Firewall, Limits. Diese sechs Fehler sehen wir am h\u00e4ufigsten.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Port 80 geschlossen:<\/strong> HTTP-01 braucht Port 80, auch wenn die Seite nur \u00fcber HTTPS l\u00e4uft. Eine Cloud-Firewall oder ein Security-Group-Eintrag, der Port 80 blockt, l\u00e4sst die Validierung scheitern. \u00d6ffnen Sie 80 und 443 eingehend.<\/li><li><strong>DNS zeigt woanders hin:<\/strong> Wenn der A-Record auf einen CDN oder eine alte IP zeigt, validiert Let&#8217;s Encrypt den falschen Server. Pr\u00fcfen Sie immer zuerst mit <code>dig<\/code>.<\/li><li><strong>Limit \u00fcberschritten:<\/strong> Wer beim Testen das Flag <code>--staging<\/code> vergisst, brennt schnell die 50 Zertifikate pro Woche durch und wird gesperrt. Testen Sie ausschlie\u00dflich im Staging.<\/li><li><strong>Wildcard ohne DNS-01:<\/strong> Ein Wildcard-Zertifikat per HTTP-01 anzufordern, schl\u00e4gt zwangsl\u00e4ufig fehl. Wildcards gehen nur \u00fcber DNS-01.<\/li><li><strong>Reload vergessen:<\/strong> Nach manueller Erneuerung ohne <code>--deploy-hook<\/code> serviert der Webserver weiter das alte Zertifikat. Immer einen Reload-Hook setzen.<\/li><li><strong>Privater Schl\u00fcssel im Repo:<\/strong> Niemals <code>\/etc\/letsencrypt\/<\/code> oder <code>privkey.pem<\/code> in eine Versionsverwaltung einchecken. Der private Schl\u00fcssel geh\u00f6rt nur auf den Server.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Ein siebter, oft untersch\u00e4tzter Punkt: Zeitsynchronisation. Stimmt die Serveruhr nicht, lehnt Let&#8217;s Encrypt die Anfrage ab, weil Zeitstempel im ACME-Protokoll gepr\u00fcft werden. Aktivieren Sie NTP mit <code>sudo timedatectl set-ntp true<\/code>. Mehr Hintergrund zu Angriffsfl\u00e4chen falsch konfigurierter Server finden Sie in unserem Beitrag zu <a href=\"\/de\/datenlecks\/\">Datenlecks und ihren Ursachen<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"troubleshooting-8-typische-probleme-loesen\">Troubleshooting: 8 typische Probleme l\u00f6sen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn Certbot abbricht, liefert es meist eine aussagekr\u00e4ftige Fehlermeldung. Diese acht F\u00e4lle decken die gro\u00dfe Mehrheit aller Supportanfragen ab.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Fehlermeldung \/ Symptom<\/th><th>Ursache<\/th><th>L\u00f6sung<\/th><\/tr><\/thead><tbody><tr><td>Timeout during connect (port 80)<\/td><td>Firewall blockt Port 80<\/td><td>Port 80\/443 eingehend \u00f6ffnen<\/td><\/tr><tr><td>DNS problem: NXDOMAIN<\/td><td>A-Record fehlt oder falsch<\/td><td>DNS-Eintrag korrigieren, propagieren lassen<\/td><\/tr><tr><td>too many certificates already issued<\/td><td>Wochenlimit erreicht<\/td><td>bis zu 7 Tage warten, Staging nutzen<\/td><\/tr><tr><td>Challenge failed for domain<\/td><td>well-known-Pfad nicht erreichbar<\/td><td>webroot pr\u00fcfen, Reverse-Proxy anpassen<\/td><\/tr><tr><td>Incorrect TXT record<\/td><td>DNS-Propagation zu langsam<\/td><td>propagation-seconds erh\u00f6hen<\/td><\/tr><tr><td>certbot: command not found<\/td><td>Symlink fehlt<\/td><td>ln -s \/snap\/bin\/certbot \/usr\/bin\/certbot<\/td><\/tr><tr><td>nginx: configuration test failed<\/td><td>Syntaxfehler in Konfig<\/td><td>nginx -t, Fehler beheben<\/td><\/tr><tr><td>Cert expired trotz renew<\/td><td>Reload-Hook fehlt<\/td><td>&#8211;deploy-hook setzen<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\">Die acht h\u00e4ufigsten Certbot-Fehler und ihre L\u00f6sung.<\/figcaption><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr eine tiefere Analyse hilft das Logfile. Certbot protokolliert jeden Lauf detailliert, inklusive der genauen ACME-Antworten von Let&#8217;s Encrypt:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Detailliertes Log einsehen\nsudo tail -n 50 \/var\/log\/letsencrypt\/letsencrypt.log\n\n# Status aller verwalteten Zertifikate anzeigen\nsudo certbot certificates\n\n# Ausgabe zeigt Domains, Ablaufdatum und Pfade:\n# Certificate Name: beispiel.de\n#   Expiry Date: 2026-09-12 (VALID: 89 days)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tritt ein Fehler trotz korrektem DNS auf, pr\u00fcfen Sie mit einem externen Dienst, ob Port 80 wirklich von au\u00dfen erreichbar ist. Oft blockt eine vorgelagerte Cloud-Firewall, die in der lokalen <code>iptables<\/code>-Ansicht gar nicht auftaucht. Bei wiederholten Sperren wegen Limits ist Geduld der einzige Ausweg, denn die Z\u00e4hlung l\u00e4uft \u00fcber ein gleitendes 7-Tage-Fenster.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fortgeschrittene-tipps-fuer-den-produktivbetrieb\">Fortgeschrittene Tipps f\u00fcr den Produktivbetrieb<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"kurzlaeufer-zertifikate-und-das-acme-profil-waehlen\">Kurzl\u00e4ufer-Zertifikate und das ACME-Profil w\u00e4hlen<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Die 2025 eingef\u00fchrten sechst\u00e4gigen Kurzl\u00e4ufer-Zertifikate verk\u00fcrzen das Risikofenster bei einem kompromittierten Schl\u00fcssel von 90 auf 6 Tage. Voraussetzung ist eine bombenfeste Automatisierung, denn die Erneuerung muss alle zwei bis drei Tage laufen. Setzen Sie das gew\u00fcnschte Profil \u00fcber den Parameter <code>--preferred-profile<\/code> beim Ausstellen. F\u00fcr die meisten Standard-Websites bleibt das 90-Tage-Profil die pragmatischere Wahl. Kurzl\u00e4ufer lohnen sich dort, wo maximale Sicherheit z\u00e4hlt und die Pipeline bereits vollautomatisch l\u00e4uft.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ocsp-crl-und-must-staple-verstehen\">OCSP, CRL und Must-Staple verstehen<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">2025 hat Let&#8217;s Encrypt den OCSP-Dienst eingestellt und nutzt nun Sperrlisten (CRL) zur Widerrufspr\u00fcfung. Praktisch bedeutet das: Die fr\u00fcher \u00fcbliche OCSP-Stapling-Konfiguration in Nginx l\u00e4uft ins Leere und sollte entfernt werden, um unn\u00f6tige Verz\u00f6gerungen zu vermeiden. Die Widerrufspr\u00fcfung \u00fcbernehmen Browser jetzt \u00fcber ihre eigenen, regelm\u00e4\u00dfig aktualisierten Sperrlisten. F\u00fcr Betreiber \u00e4ndert sich am Tagesgesch\u00e4ft wenig, alte Stapling-Direktiven sollten Sie aber bereinigen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"mehrere-server-mit-einem-wildcard-versorgen\">Mehrere Server mit einem Wildcard versorgen<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In Cluster-Umgebungen lohnt es sich, ein Wildcard-Zertifikat zentral auszustellen und per sicherem Kanal an alle Knoten zu verteilen, etwa \u00fcber ein Secrets-Management-System. So sparen Sie Limits und vermeiden, dass jeder Knoten einzeln validiert. Der private Schl\u00fcssel muss dabei verschl\u00fcsselt \u00fcbertragen und mit strengen Dateirechten (chmod 600) abgelegt werden. Wer sich generell f\u00fcr sichere Schl\u00fcsselverwaltung interessiert, findet weitere Grundlagen in unserem Tutorial zur <a href=\"\/de\/gpg-verschluesselung-gnupg\/\">GPG-Verschl\u00fcsselung mit GnuPG<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein letzter Tipp f\u00fcr Hochverf\u00fcgbarkeit: \u00dcberwachen Sie die Restlaufzeit aktiv mit einem Monitoring-Check, der t\u00e4glich das Ablaufdatum pr\u00fcft und Alarm schl\u00e4gt, falls die Restlaufzeit unter 20 Tage f\u00e4llt. So fangen Sie eine kaputte Automatisierung ab, bevor das Zertifikat tats\u00e4chlich abl\u00e4uft. Verlassen Sie sich nicht allein auf den Timer, sondern verifizieren Sie das Ergebnis.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"certbot-alternativen-im-vergleich\">Certbot-Alternativen im Vergleich<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Certbot ist der offizielle und am besten dokumentierte ACME-Client, aber nicht der einzige. Je nach Umgebung kann eine Alternative besser passen. Caddy etwa bringt ACME-Automatik von Haus aus mit und stellt Zertifikate ohne jede Zusatzkonfiguration aus. acme.sh ist ein schlankes Shell-Skript ohne Python-Abh\u00e4ngigkeiten, ideal f\u00fcr minimalistische Systeme. Auf Windows-Servern ist win-acme die Standardl\u00f6sung.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Client<\/th><th>Sprache<\/th><th>St\u00e4rke<\/th><th>Plattform<\/th><th>Ideal f\u00fcr<\/th><\/tr><\/thead><tbody><tr><td>Certbot<\/td><td>Python<\/td><td>offiziell, Plugins<\/td><td>Linux, macOS<\/td><td>Standard-Setups<\/td><\/tr><tr><td>acme.sh<\/td><td>Shell<\/td><td>keine Abh\u00e4ngigkeiten<\/td><td>Linux, BSD<\/td><td>minimale Systeme<\/td><\/tr><tr><td>Caddy<\/td><td>Go<\/td><td>ACME eingebaut<\/td><td>plattform\u00fcbergreifend<\/td><td>neue Projekte<\/td><\/tr><tr><td>win-acme<\/td><td>.NET<\/td><td>IIS-Integration<\/td><td>Windows<\/td><td>Windows-Server<\/td><\/tr><tr><td>lego<\/td><td>Go<\/td><td>viele DNS-Provider<\/td><td>plattform\u00fcbergreifend<\/td><td>DNS-01-Automatik<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\">ACME-Clients f\u00fcr Let&#8217;s Encrypt im Vergleich (Stand 2026).<\/figcaption><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr klassische Linux-Server mit Nginx oder Apache bleibt Certbot die sicherste Wahl, weil die Webserver-Plugins die Konfiguration automatisch pflegen. Wer ein neues Projekt von Grund auf aufsetzt und ohnehin einen modernen Webserver sucht, sollte Caddy ernsthaft pr\u00fcfen, da HTTPS dort der Standard ohne Mehraufwand ist. Alle genannten Clients sprechen dasselbe ACME-Protokoll und nutzen dieselben Let&#8217;s-Encrypt-Server.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"lets-encrypt-im-docker-container-betreiben\">Let&#8217;s Encrypt im Docker-Container betreiben<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">In containerisierten Umgebungen l\u00e4uft die Zertifikatsverwaltung etwas anders, weil ein Container idealerweise zustandslos bleibt. Die bew\u00e4hrte L\u00f6sung: ein dediziertes Certbot-Volume, das die Zertifikate persistent speichert und von mehreren Containern gelesen werden kann. So \u00fcberlebt das Zertifikat einen Neustart oder ein Update des Webserver-Containers. Das folgende Beispiel zeigt einen typischen Docker-Compose-Aufbau mit Nginx und Certbot.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># docker-compose.yml (Auszug)\nservices:\n  nginx:\n    image: nginx:1.27\n    ports: [\"80:80\", \"443:443\"]\n    volumes:\n      - .\/nginx.conf:\/etc\/nginx\/conf.d\/default.conf:ro\n      - letsencrypt:\/etc\/letsencrypt:ro\n      - certbot-www:\/var\/www\/certbot:ro\n\n  certbot:\n    image: certbot\/certbot:latest\n    volumes:\n      - letsencrypt:\/etc\/letsencrypt\n      - certbot-www:\/var\/www\/certbot\n    # alle 12 Stunden Erneuerung versuchen\n    entrypoint: sh -c 'trap exit TERM; while :; do\n      certbot renew --webroot -w \/var\/www\/certbot --quiet;\n      sleep 12h; done'\n\nvolumes:\n  letsencrypt:\n  certbot-www:<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Das erste Zertifikat stellen Sie einmalig mit einem separaten <code>docker compose run<\/code>-Aufruf aus, danach \u00fcbernimmt der dauerhaft laufende Certbot-Container die Erneuerung. Wichtig ist, dass Nginx nach einer Erneuerung die neue Datei l\u00e4dt. In Containern erreichen Sie das am saubersten, indem der Nginx-Container regelm\u00e4\u00dfig die Konfiguration neu l\u00e4dt oder ein Hook den Reload ausl\u00f6st. Wer Kubernetes einsetzt, greift in der Regel zu cert-manager, das ACME-Zertifikate als native Ressourcen verwaltet und die Erneuerung vollst\u00e4ndig automatisiert. Das Prinzip bleibt identisch: ein ACME-Client, das HTTP-01- oder DNS-01-Verfahren und persistente Speicherung des privaten Schl\u00fcssels.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein h\u00e4ufiger Stolperstein in Containern ist Port 80. W\u00e4hrend der HTTP-01-Validierung muss der Pfad <code>\/.well-known\/acme-challenge\/<\/code> erreichbar sein, bevor das Zertifikat existiert. L\u00f6sen Sie das, indem Nginx zun\u00e4chst nur auf Port 80 lauscht und diesen Pfad ausliefert. Erst nach erfolgreicher Ausstellung aktivieren Sie den HTTPS-Block. Andernfalls entsteht ein Henne-Ei-Problem: Nginx startet nicht ohne Zertifikat, das Zertifikat kommt aber nicht ohne laufenden Nginx.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"lets-encrypt-gegen-kostenpflichtige-zertifikate\">Let&#8217;s Encrypt gegen kostenpflichtige Zertifikate<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Eine h\u00e4ufige Frage im DACH-Mittelstand lautet, ob ein kostenloses Zertifikat f\u00fcr gesch\u00e4ftskritische Seiten ausreicht oder ob es ein gekauftes sein sollte. Die technische Antwort ist eindeutig: F\u00fcr die Verschl\u00fcsselung selbst gibt es keinen Unterschied. Ein Let&#8217;s-Encrypt-Zertifikat nutzt dieselben Algorithmen und bietet dieselbe Transportsicherheit wie ein DV-Zertifikat f\u00fcr mehrere hundert Euro im Jahr. Browser behandeln beide gleichwertig, und das Schloss-Symbol sieht identisch aus.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Unterschiede gibt es bei der Validierungsstufe. Let&#8217;s Encrypt stellt ausschlie\u00dflich domainvalidierte (DV) Zertifikate aus. Wer Organisationsvalidierung (OV) oder Extended Validation (EV) ben\u00f6tigt, etwa aus regulatorischen Gr\u00fcnden im Finanzsektor, muss zu einer kommerziellen CA greifen. Auch eine vertragliche Haftungszusage oder ein deutschsprachiger Support rund um die Uhr sind bei kostenpflichtigen Anbietern \u00fcblich, bei Let&#8217;s Encrypt nicht. F\u00fcr den \u00fcberwiegenden Teil aller Websites, Webshops und APIs ist das aber irrelevant.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Kriterium<\/th><th>Let&#8217;s Encrypt<\/th><th>Kommerzielle CA (DV)<\/th><th>Kommerzielle CA (OV\/EV)<\/th><\/tr><\/thead><tbody><tr><td>Preis pro Jahr<\/td><td>0 \u20ac<\/td><td>ca. 5 bis 50 \u20ac<\/td><td>ca. 100 bis 400 \u20ac<\/td><\/tr><tr><td>Verschl\u00fcsselungsst\u00e4rke<\/td><td>identisch<\/td><td>identisch<\/td><td>identisch<\/td><\/tr><tr><td>Validierung<\/td><td>nur DV<\/td><td>DV<\/td><td>OV oder EV<\/td><\/tr><tr><td>Laufzeit<\/td><td>90 oder 6 Tage<\/td><td>bis 1 Jahr<\/td><td>bis 1 Jahr<\/td><\/tr><tr><td>Automatisierung<\/td><td>nativ (ACME)<\/td><td>oft manuell<\/td><td>meist manuell<\/td><\/tr><tr><td>Support \/ Haftung<\/td><td>Community<\/td><td>begrenzt<\/td><td>vertraglich<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\">Let&#8217;s Encrypt im Vergleich zu kommerziellen Zertifizierungsstellen.<\/figcaption><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Die kurze Laufzeit von Let&#8217;s Encrypt wird gelegentlich als Nachteil dargestellt, ist in der Praxis aber ein Sicherheitsgewinn: Kurzlebige Zertifikate begrenzen den Schaden, falls ein privater Schl\u00fcssel je in falsche H\u00e4nde ger\u00e4t. Genau deshalb bewegt sich die gesamte Branche in Richtung k\u00fcrzerer Laufzeiten. Wer die Automatisierung einmal sauber aufgesetzt hat, merkt von der Erneuerung ohnehin nichts mehr. Der vermeintliche Nachteil verschwindet hinter dem Timer.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"sicherheit-und-best-practices-nach-der-einrichtung\">Sicherheit und Best Practices nach der Einrichtung<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein g\u00fcltiges Zertifikat allein macht eine Website nicht sicher. Es verschl\u00fcsselt die Verbindung, sagt aber nichts \u00fcber die Konfiguration dahinter aus. Nach der Ausstellung sollten Sie die TLS-Einstellungen h\u00e4rten und regelm\u00e4\u00dfig pr\u00fcfen. Das Bundesamt f\u00fcr Sicherheit in der Informationstechnik (BSI) ver\u00f6ffentlicht dazu konkrete <a href=\"https:\/\/www.bsi.bund.de\/DE\/Themen\/Verbraucherinnen-und-Verbraucher\/Informationen-und-Empfehlungen\/Cyber-Sicherheitsempfehlungen\/cyber-sicherheitsempfehlungen_node.html\" target=\"_blank\" rel=\"noopener\">Cyber-Sicherheitsempfehlungen<\/a>.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Nur TLS 1.2 und 1.3:<\/strong> Deaktivieren Sie SSLv3, TLS 1.0 und 1.1. Diese Protokolle gelten als unsicher.<\/li><li><strong>HSTS aktivieren:<\/strong> Der Strict-Transport-Security-Header zwingt Browser auf HTTPS und sch\u00fctzt vor Downgrade-Angriffen.<\/li><li><strong>Starke Cipher-Suites:<\/strong> Orientieren Sie sich an den Mozilla-Empfehlungen f\u00fcr die Konfiguration moderner Verschl\u00fcsselung.<\/li><li><strong>Schl\u00fcsselrechte pr\u00fcfen:<\/strong> <code>privkey.pem<\/code> darf nur f\u00fcr root lesbar sein (chmod 600).<\/li><li><strong>Regelm\u00e4\u00dfig testen:<\/strong> Lassen Sie SSL Labs monatlich gegen Ihre Domain laufen und streben Sie mindestens Note A an.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Behalten Sie au\u00dferdem im Hinterkopf, dass ein TLS-Zertifikat nur einen Teil der Angriffsfl\u00e4che abdeckt. Schwache Passw\u00f6rter, fehlende Updates oder offene Admin-Oberfl\u00e4chen bleiben unabh\u00e4ngig davon ein Risiko. TLS sch\u00fctzt die Daten auf dem Transportweg, nicht den Server selbst. Eine ganzheitliche Sicht auf Server-H\u00e4rtung lohnt sich, denn Verschl\u00fcsselung ist die Basis, nicht das ganze Geb\u00e4ude.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"haeufige-fragen-zu-lets-encrypt-und-certbot\">H\u00e4ufige Fragen zu Let&#8217;s Encrypt und Certbot<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ist-lets-encrypt-wirklich-kostenlos\">Ist Let&#8217;s Encrypt wirklich kostenlos?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ja, vollst\u00e4ndig. Let&#8217;s Encrypt ist ein Projekt der gemeinn\u00fctzigen ISRG und finanziert sich \u00fcber Spenden und Sponsoren. Es fallen keine Geb\u00fchren an, weder f\u00fcr die Ausstellung noch f\u00fcr die Erneuerung. Die Zertifikate sind technisch und rechtlich gleichwertig mit kostenpflichtigen DV-Zertifikaten anderer Anbieter.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wie-lange-sind-die-zertifikate-gueltig\">Wie lange sind die Zertifikate g\u00fcltig?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Standardm\u00e4\u00dfig 90 Tage. Seit 2025 gibt es zus\u00e4tzlich ein Profil f\u00fcr sechst\u00e4gige Kurzl\u00e4ufer. Die kurze Laufzeit ist Absicht: Sie erzwingt Automatisierung und begrenzt den Schaden bei kompromittierten Schl\u00fcsseln. Mit <code>certbot renew<\/code> und einem aktiven Timer erneuern sich Zertifikate automatisch ab etwa 30 Tagen Restlaufzeit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"bekomme-ich-noch-e-mails-vor-dem-ablauf\">Bekomme ich noch E-Mails vor dem Ablauf?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Nein. Let&#8217;s Encrypt hat die Ablauf-Erinnerungsmails 2025 abgeschaltet. Verlassen Sie sich ausschlie\u00dflich auf die automatische Erneuerung plus ein eigenes Monitoring, das die Restlaufzeit \u00fcberwacht. Eine fehlende E-Mail darf nie der einzige Schutz vor einem abgelaufenen Zertifikat sein.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"brauche-ich-fuer-jede-subdomain-ein-eigenes-zertifikat\">Brauche ich f\u00fcr jede Subdomain ein eigenes Zertifikat?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Nein. Ein Zertifikat kann bis zu 100 Identifier enthalten, also viele Subdomains gleichzeitig abdecken. Alternativ stellen Sie ein Wildcard-Zertifikat f\u00fcr <code>*.beispiel.de<\/code> aus, das alle Subdomains einer Ebene umfasst. Wildcards erfordern allerdings zwingend die DNS-01-Validierung.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"funktioniert-lets-encrypt-auch-hinter-einem-cdn\">Funktioniert Let&#8217;s Encrypt auch hinter einem CDN?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Das h\u00e4ngt vom CDN ab. Bei einem aktiven Cloudflare-Proxy zeigt der A-Record auf Cloudflare, nicht auf Ihren Server, sodass HTTP-01 scheitern kann. Die L\u00f6sung ist DNS-01 \u00fcber das passende DNS-Plugin, weil diese Methode die TXT-Validierung in der Zone nutzt und vom CDN unabh\u00e4ngig ist.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"kann-ich-ein-zertifikat-fuer-eine-ip-adresse-bekommen\">Kann ich ein Zertifikat f\u00fcr eine IP-Adresse bekommen?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Seit 2025 ja. Let&#8217;s Encrypt stellt Zertifikate f\u00fcr reine IP-Adressen aus, die als Kurzl\u00e4ufer mit sechs Tagen Laufzeit kommen. Das ist n\u00fctzlich f\u00fcr interne Dienste oder Hosts ohne Domainnamen. Auch hier gilt: Ohne Automatisierung ist der Betrieb wegen der kurzen Laufzeit kaum praktikabel.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"was-passiert-wenn-die-erneuerung-fehlschlaegt\">Was passiert, wenn die Erneuerung fehlschl\u00e4gt?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Solange die Restlaufzeit \u00fcber null liegt, bleibt das alte Zertifikat g\u00fcltig, und der n\u00e4chste Timer-Lauf versucht es erneut. Da die Erneuerung schon ab 30 Tagen Restlaufzeit startet, bleibt ein gro\u00dfz\u00fcgiges Zeitfenster zum Eingreifen. Pr\u00fcfen Sie das Logfile unter <code>\/var\/log\/letsencrypt\/<\/code>, um die genaue Fehlerursache zu finden.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"related-coverage\">Related Coverage<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/de\/https-und-tls\/\">HTTPS und TLS: Wie das Schloss im Browser Sie sch\u00fctzt<\/a><\/li><li><a href=\"\/de\/gpg-verschluesselung-gnupg\/\">GPG Verschl\u00fcsselung: 12 Schritte mit GnuPG<\/a><\/li><li><a href=\"\/de\/ssh-key-erstellen-ed25519-2026\/\">SSH-Key erstellen: Ed25519 in 8 Schritten<\/a><\/li><li><a href=\"\/de\/ecdsa-nodejs-signaturen\/\">ECDSA in Node.js: Signaturen in 11 Schritten<\/a><\/li><li><a href=\"\/de\/datenlecks\/\">Datenlecks: Wie sie entstehen und wie Sie sich sch\u00fctzen<\/a><\/li><li><a href=\"\/de\/security-hub\/\">Online-Sicherheit verst\u00e4ndlich erkl\u00e4rt<\/a><\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Quellen und weiterf\u00fchrende Links: <a href=\"https:\/\/letsencrypt.org\/\" target=\"_blank\" rel=\"noopener\">letsencrypt.org<\/a>, <a href=\"https:\/\/certbot.eff.org\/\" target=\"_blank\" rel=\"noopener\">certbot.eff.org<\/a>, <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc8555\" target=\"_blank\" rel=\"noopener\">RFC 8555 (ACME)<\/a>, <a href=\"https:\/\/letsencrypt.org\/docs\/rate-limits\/\" target=\"_blank\" rel=\"noopener\">Let&#8217;s Encrypt Rate Limits<\/a>, <a href=\"https:\/\/letsencrypt.org\/2025\/01\/16\/6-day-and-ip-certs\/\" target=\"_blank\" rel=\"noopener\">Ank\u00fcndigung 6-Tage- und IP-Zertifikate<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ein g\u00fcltiges TLS-Zertifikat kostet 2026 keinen Cent mehr, und die Einrichtung dauert weniger als 15 Minuten. Let&#8217;s Encrypt hat das Web umgekrempelt: Wo Administratoren fr\u00fcher dreistellige Betr\u00e4ge pro Jahr und\u2026<\/p>\n","protected":false},"author":8,"featured_media":126,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-125","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts\/125","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/comments?post=125"}],"version-history":[{"count":1,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts\/125\/revisions"}],"predecessor-version":[{"id":127,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts\/125\/revisions\/127"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/media\/126"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/media?parent=125"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/categories?post=125"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/tags?post=125"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}