Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Diese Anleitung behandelt den realen Certbot-/Let's-Encrypt-Ablauf unseres Ubuntu-24.04-VPS. Beim ersten Portainer-SSL-Versuch gab es einen core24-TCP-Timeout während snap install certbot. Später wurde Snap Certbot 5.7.0 erfolgreich installiert, ältere APT-Certbot-2.9.0-Pakete entfernt, certbot --nginx deployte das Zertifikat und certbot renew --dry-run war erfolgreich. Dasselbe Muster wurde für Open WebUI und n8n verwendet.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
DNS + Nginx HTTP
↓
Snap Certbot
↓ core24 timeout → retry / fix
Certbot 5.7.0
↓
certbot --nginx
↓
Let's Encrypt HTTPS
↓
certbot renew --dry-run → successDiese Anleitung dokumentiert den Nginx- und Certbot-Ablauf, den wir auf einem realen Ubuntu-24.04-VPS für Portainer, Open WebUI und n8n verwendet haben.
Zuerst funktionieren DNS und HTTP-vHost, danach holt und deployt Certbot das Zertifikat über das Nginx-Plugin. Abschließend werden Zertifikatsdetails, HTTPS und Renewal-Dry-Run geprüft.
DNS → Nginx :80 → Certbot --nginx → Let's Encrypt → Nginx :443 HTTPS
Vor der ACME-Validierung sollte die Webserverkette funktionieren. Im realen Portainer-Ablauf lieferten Cloudflare- und Google-DNS die erwartete Auflösung, nginx -t war erfolgreich und der lokale Host-Header-Test ergab HTTP 200.
Bei falschem DNS oder kaputtem vHost zuerst diese Ebene reparieren.
dig +short A portainer.ekasunucu.com @1.1.1.1dig +short A portainer.ekasunucu.com @8.8.8.8nginx -tcurl -sS -o /dev/null -w '%{http_code}\n' -H 'Host: portainer.ekasunucu.com' http://127.0.0.1/
Der erste Snap-Certbot-Versuch scheiterte beim Download der core24-Abhängigkeit vom Canonical-CDN. Der TCP-Read lief in einen Timeout und snap install --classic certbot endete mit Code 1.
Das war kein Nginx-, DNS- oder Let's-Encrypt-Domainproblem, sondern ein ausgehendes Download-/Netzwerkproblem.
snap install --classic certbot
snap changes zeigt fehlgeschlagene Vorgänge, snap list installierte Snaps und journalctl die snapd-Logs. Namensauflösung und ausgehendes HTTPS separat testen.
Im realen Setup funktionierte ein späterer Versuch und Snap Certbot 5.7.0 war verfügbar. Bei dauerhaften Fehlern DNS, Routing oder Provider-Filtering untersuchen.
snap changessnap listjournalctl -u snapd --no-pager -n 100getent hosts canonical-bos01.cdn.snapcraftcontent.comsnap install --classic certbot
Nach Standardisierung auf Snap Certbot 5.7.0 wurden die älteren APT-Pakete certbot 2.9.0, python3-certbot und python3-certbot-nginx entfernt. Dadurch waren aktives Binary und Renewal-Mechanismus eindeutig.
Nicht blind Pakete löschen; vorhandene Zertifikate und Renewal-Konfiguration vorher prüfen.
snap list certbotapt-cache policy certbot python3-certbot-nginxapt-get remove -y certbot python3-certbot-nginx python3-certbotcertbot --version
Eine frühe Scriptversion sendete Kommandos per Bash-Heredoc über SSH und wollte gleichzeitig die Let's-Encrypt-E-Mail über stdin lesen. Da das Heredoc stdin bereits verwendete, erhielt read nicht die gewünschte interaktive Eingabe.
Interaktive Werte vor dem Heredoc einsammeln und bewusst an das Remote-Script übergeben. Das ist ein Bash-/stdin-Problem, kein Certbot-Fehler.
read -r -p 'Let\'s Encrypt E-Mail: ' LE_EMAILexport LE_EMAILNach funktionierendem Nginx-vHost wurde certbot --nginx für portainer.ekasunucu.com ausgeführt. Die reale Ausgabe bestätigte erfolgreiche Ausstellung und Deployment.
Certbot verwaltet Live-Zertifikat und Private-Key-Symlinks unter /etc/letsencrypt/live/DOMAIN/.
certbot --nginx -d portainer.ekasunucu.comnginx -tcurl -I https://portainer.ekasunucu.com
Beim realen Portainer-Zertifikat zeigte certbot certificates ECDSA-Keytyp, Domainidentifier, Ablaufdatum sowie fullchain- und Private-Key-Pfad.
Bei mehreren Domains ist dieser Befehl ein praktisches Zertifikatsinventar.
certbot certificatesopenssl x509 -in /etc/letsencrypt/live/portainer.ekasunucu.com/fullchain.pem -noout -subject -issuer -dates
Nach Portainer wurde dasselbe Muster für openwebui.ekasunucu.com und n8n.ekasunucu.com verwendet. Die realen Logs zeigen erfolgreiche Zertifikatsausstellung und Deployment mit Ablaufdatum 2026-11-08.
Die Methode ist nicht an eine Anwendung gebunden; entscheidend sind korrektes DNS, funktionierender Nginx-vHost und erreichbare Validierungs-/HTTPS-Pfade.
certbot --nginx -d openwebui.ekasunucu.comcertbot --nginx -d n8n.ekasunucu.com
Die reale Finalprüfung zeigte snap.certbot.renew.timer. Der Renewal-Service muss nicht dauerhaft active sein; der Timer startet ihn bei Bedarf.
Timer-Existenz allein genügt nicht. Die reale Renewal-Konfiguration mit Dry-Run testen.
systemctl list-timers --all | grep -i certbotsystemctl status snap.certbot.renew.timer --no-pager
Die Portainer-Renewal-Konfiguration wurde im realen Test von certbot renew --dry-run verarbeitet und die Simulation war erfolgreich. So werden Authentifizierung, Renewal-Konfiguration und Deploy-Pfad ohne Ersetzen des Live-Zertifikats getestet.
Die Ausgabe meldete success für /etc/letsencrypt/live/portainer.ekasunucu.com/fullchain.pem.
certbot renew --dry-run
Certbot-Fehlersuche umfasst mehrere Schichten. Falsches DNS ist Resolverproblem, fehlerhaftes nginx -t Webserverproblem, core24-Timeout Snap-Downloadproblem, abgelehnte Ausstellung ACME-Validierung und fehlgeschlagener Dry-Run Renewal-/Konfigurationsproblem.
Jede Schicht separat testen, statt mehrere gleichzeitige Fehler einer Ursache zuzuordnen.
dig +short A DOMAINnginx -tsnap changescertbot certificatescertbot renew --dry-runtail -n 150 /var/log/letsencrypt/letsencrypt.logFinal sollten DNS korrekt, Nginx-Konfiguration gültig, HTTPS erfolgreich, Zertifikatspfade vorhanden, Renewal-Mechanismus eingerichtet und Dry-Run erfolgreich sein. Private Backendports dürfen für TLS nicht unnötig öffentlich geöffnet werden.
Unser Portainer-Endzustand kombinierte HTTPS 200, gültiges Zertifikat, localhost-only 9443 und erfolgreichen simulierten Renewal; dasselbe Muster wurde für Open WebUI und n8n wiederholt.
nginx -tcertbot certificatescurl -I https://portainer.ekasunucu.comsystemctl list-timers --all | grep -i certbotcertbot renew --dry-runss -lntp | grep -E ':80|:443|:9443'Im realen Test lief der Download der core24-Snap-Abhängigkeit vom Canonical-CDN über outbound HTTPS in einen Timeout.
Nein. Es war ein Paketdownload-/Netzwerkproblem, kein Nginx- oder ACME-Challenge-Fehler.
DNS-Auflösung, nginx -t und HTTP-vHost/Reverse-Proxy-Pfad.
Eine einheitliche Installationsmethode reduziert Unklarheiten bei Binary, Plugin und Renewal. Vor Änderungen Zertifikate sichern.
Die finale Snap-Installation nutzte Certbot 5.7.0.
Es fordert ein Zertifikat für den Nginx-vHost an und kann HTTPS nach erfolgreicher Ausstellung deployen.
Im Beispiel /etc/letsencrypt/live/DOMAIN/fullchain.pem und privkey.pem.
Certificate Name, Identifiers, Keytyp, Ablauf und verwaltete Dateipfade.
Im realen Snap-Setup war snap.certbot.renew.timer vorhanden und Certbot meldete eine geplante Renewal-Aufgabe.
Es simuliert die Verlängerung, ohne das Live-Zertifikat zu ersetzen.
Dass aktuelle Renewal-Konfiguration und Validierungs-/Deploy-Pfad während der Simulation funktionierten.
Das Heredoc belegte stdin bereits; der interaktive read erhielt deshalb nicht die erwartete Eingabe.
Ja. Beide realen Domains erhielten erfolgreiche certbot --nginx Deployments.
nginx -t, certbot certificates, HTTPS-Antwort, Renewal-Timer, Dry-Run und private Backend-Port-Bindings.
Portainer, Open WebUI, n8n und weitere Self-Hosted-Dienste per HTTPS auf EKA-Sunucu-Linux-VPS veröffentlichen.
Aktualisiert: 10.08.2026