Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Bu rehber gerçek Ubuntu 24.04 VPS kurulumlarımızda yaşadığımız Certbot / Let's Encrypt sürecini tek başına ele alıyor. Portainer SSL sırasında snap install certbot komutunda core24 TCP timeout yaşadık; daha sonra Snap Certbot 5.7.0 kuruldu, eski APT Certbot 2.9.0 paketleri temizlendi, certbot --nginx ile sertifika başarıyla deploy edildi ve certbot renew --dry-run simülasyonu başarıyla tamamlandı. Aynı model Open WebUI ve n8n domainlerinde de tekrarlandı.
Türkiye (Türkçe)
Almanya (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 → successBu rehber gerçek Ubuntu 24.04 VPS testlerimizde Portainer, Open WebUI ve n8n alan adlarına Let's Encrypt sertifikası kurarken kullandığımız Nginx + Certbot akışını ayrı olarak belgeler.
Temel modelde önce DNS ve Nginx HTTP vhost çalışır hale gelir, ardından Certbot Nginx plugin ile sertifikayı alır ve HTTPS yapılandırmasını deploy eder. Son aşamada sertifika detayları, HTTPS response ve renewal dry-run ayrı ayrı kontrol edilir.
DNS → Nginx :80 → Certbot --nginx → Let's Encrypt → Nginx :443 HTTPS
Certbot hatalarını azaltmanın en iyi yolu challenge aşamasına geçmeden önce temel web sunucusu zincirini doğrulamaktır. Gerçek Portainer akışımızda Cloudflare ve Google DNS sonuçları beklenen origin adresine gidiyor, nginx -t başarılı oluyor ve local Host-header reverse proxy testi HTTP 200 dönüyordu.
DNS yanlışsa veya Nginx vhost çalışmıyorsa Certbot'a geçmeden önce bu katmanı düzeltin. Sertifika aracı çalışan web sunucusu problemini sizin yerinize çözmez.
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/
İlk Snap Certbot denememizde core24 dependency'si Canonical CDN üzerinden indirilirken TCP read timeout oluştu ve snap install --classic certbot çıkış kodu 1 ile durdu. Bu hata Nginx syntax, DNS veya Let's Encrypt domain challenge hatası değildi.
Log, VPS ile snap CDN arasındaki outbound HTTPS bağlantısının indirme sırasında timeout olduğunu açıkça gösteriyordu. Bu ayrım önemlidir; domain ayarlarını değiştirerek çözülemeyecek bir ağ indirme problemini domain problemi gibi ele almamak gerekir.
snap install --classic certbot
Timeout sonrasında snap changes ile yarım veya başarısız işlemleri, snap list ile mevcut paketleri ve journalctl ile snapd loglarını kontrol edebilirsiniz. CDN hostname çözümlemesi ve outbound HTTPS erişimi de ayrı test edilmelidir.
Gerçek kurulumda ağ erişimi daha sonraki denemede düzeldi ve Snap Certbot 5.7.0 başarıyla kuruldu. Bu nedenle kısa süreli CDN/network timeoutlarında retry mantıklı olabilir; kalıcı problem varsa provider outbound filtering, DNS veya rota tarafını inceleyin.
snap changessnap listjournalctl -u snapd --no-pager -n 100getent hosts canonical-bos01.cdn.snapcraftcontent.comsnap install --classic certbot
Gerçek sunucuda Snap Certbot 5.7.0 kullanılmaya başlandığında APT üzerinden kurulu certbot 2.9.0, python3-certbot ve python3-certbot-nginx paketlerini kaldırdık. Böylece hangi certbot binary'sinin ve hangi renewal mekanizmasının aktif olduğu netleşti.
Bu adımın amacı rastgele paket silmek değil, tek bir kurulum yöntemine standardize olmaktır. Production sunucuda mevcut sertifika ve renewal konfigürasyonlarını kontrol etmeden paket kaldırmayın.
snap list certbotapt-cache policy certbot python3-certbot-nginxapt-get remove -y certbot python3-certbot-nginx python3-certbotcertbot --version
Gerçek kurulum scriptimizin ilk sürümünde bash heredoc üzerinden SSH'ye komut gönderirken aynı script içinde read ile Let's Encrypt e-posta adresi isteniyordu. Heredoc stdin'i zaten kullandığı için read beklenen interaktif girişi alamadı.
Daha güvenli yaklaşım, kullanıcıdan e-posta gibi interaktif değerleri heredoc başlamadan önce almak ve environment variable olarak script içine taşımaktır. Bu bir Certbot hatası değil Bash/stdin akış problemidir.
read -r -p 'Let\'s Encrypt e-posta adresi: ' LE_EMAILexport LE_EMAILssh root@SUNUCU 'bash -s' <<'BASH'
# script içinde "$LE_EMAIL" benzeri aktarım yöntemi planlanır
BASHNginx vhost çalışır hale geldikten sonra portainer.ekasunucu.com için certbot --nginx kullandık. Gerçek çıktı sertifikanın başarıyla alındığını ve Nginx sitesine deploy edildiğini doğruladı.
Certbot sertifika ve private key dosyalarını /etc/letsencrypt/live/DOMAIN/ altında yönetir. Bu symlink yollarını elle kopyalamak yerine Nginx konfigurasyonunda Certbot'un yönettiği yapıyı korumak yenileme sürecini kolaylaştırır.
certbot --nginx -d portainer.ekasunucu.comnginx -tcurl -I https://portainer.ekasunucu.com
Gerçek Portainer sertifikasında certbot certificates çıktısı ECDSA key türünü, domain identifier'ını, expiry tarihini ve fullchain/private-key yollarını gösterdi. Bu çıktı, hangi domainin hangi certificate name altında yönetildiğini hızlıca görmek için kullanışlıdır.
Aynı sunucuda birden fazla domain olduğunda certbot certificates ile tüm sertifikaları topluca kontrol etmek renewal troubleshooting sırasında büyük kolaylık sağlar.
certbot certificatesopenssl x509 -in /etc/letsencrypt/live/portainer.ekasunucu.com/fullchain.pem -noout -subject -issuer -dates
Portainer SSL kurulumu tamamlandıktan sonra aynı yaklaşım openwebui.ekasunucu.com ve n8n.ekasunucu.com için tekrarlandı. Gerçek loglarda her iki domain için de sertifika başarıyla alındı, Nginx site dosyasına deploy edildi ve expiry 2026-11-08 olarak kaydedildi.
Bu, yöntemin tek bir uygulamaya özel olmadığını gösterir. Önemli olan her domainin DNS kaydının doğru olması, Nginx vhost'unun hazır olması ve originin challenge/HTTPS trafiğini kabul edebilmesidir.
certbot --nginx -d openwebui.ekasunucu.comcertbot --nginx -d n8n.ekasunucu.com
Gerçek final kontrolde systemd timer listesinde snap.certbot.renew.timer görünüyordu. certbot.renew service'in sürekli active olması gerekmez; timer zamanı geldiğinde service tetiklenir.
Yalnız timer'ın varlığına güvenmeyin. Asıl güvence, renewal configlerin hatasız çalıştığını dry-run ile test etmektir.
systemctl list-timers --all | grep -i certbotsystemctl status snap.certbot.renew.timer --no-pager
Portainer sertifikasında certbot renew --dry-run gerçek renewal config dosyasını işledi ve simulated renewal başarılı tamamlandı. Bu test sertifikayı gerçekten yenilemeden authentication, renewal config ve deploy zincirini kontrol eder.
Gerçek çıktımızda /etc/letsencrypt/live/portainer.ekasunucu.com/fullchain.pem için success sonucu görüldü. SSL kurulumunu 'sertifika alındı' aşamasında bırakmayıp dry-run ile bitirmek üretim güvenilirliğini artırır.
certbot renew --dry-run
Certbot troubleshooting tek bir hata kategorisi değildir. DNS yanlışsa resolver katmanı; Nginx config bozuksa web server; core24 timeout varsa outbound Snap download; certificate request reddediliyorsa ACME validation; dry-run başarısızsa renewal config/validation zinciri incelenmelidir.
Aynı anda görülen farklı hataları tek sebebe bağlamak yerine her katmanı ayrı komutla test etmek daha hızlı ve güvenilir sonuç verir.
dig +short A DOMAINnginx -tsnap changescertbot certificatescertbot renew --dry-runtail -n 150 /var/log/letsencrypt/letsencrypt.logFinal durumda DNS doğru, Nginx config başarılı, HTTPS domain 200, certificate paths mevcut, renewal timer kurulu ve renew --dry-run başarılı olmalıdır. Ayrıca backend uygulama portlarının SSL kurmak uğruna public açılmadığını tekrar kontrol edin.
Bizim final Portainer akışımızda HTTPS 200, valid certificate, localhost-only 9443 ve simulated renewal success birlikte doğrulandı; aynı desen Open WebUI ve n8n üzerinde de tekrarlandı.
nginx -tcertbot certificatescurl -I https://portainer.ekasunucu.comsystemctl list-timers --all | grep -i certbotcertbot renew --dry-runss -lntp | grep -E ':80|:443|:9443'Gerçek testimizde snap install certbot sırasında core24 paketi Canonical CDN'den indirilirken outbound HTTPS TCP timeout oluştu.
Hayır. Bizim olayımız paket indirme/ağ katmanındaydı; Nginx veya ACME challenge hatası değildi.
DNS çözümlemesi, nginx -t ve HTTP vhost/reverse proxy erişimi doğrulanmalıdır.
Kurulum ve renewal karmaşasını azaltmak için tek yönteme standardize olmak daha temizdir. Mevcut sertifikaları yedeklemeden paket kaldırmayın.
Final Snap kurulumunda Certbot 5.7.0 kullanıldı.
Nginx vhost için sertifika ister ve başarılı olduğunda HTTPS yapılandırmasını deploy edebilir.
Gerçek örnekte /etc/letsencrypt/live/DOMAIN/fullchain.pem ve privkey.pem yolları kullanıldı.
Kurulu certificate name, identifiers, key type, expiry ve dosya yollarını listeler.
Gerçek Snap kurulumunda snap.certbot.renew.timer bulundu ve Certbot scheduled renewal mekanizması kurdu.
Canlı sertifikayı değiştirmeden renewal zincirini simüle eder.
Mevcut renewal config ve validation/deploy zincirinin test sırasında başarılı çalıştığını gösterir.
SSH heredoc stdin'i kullandığı için aynı akıştaki interaktif read beklenen kullanıcı girişini alamadı.
Evet. Gerçek testimizde her iki domain için de certbot --nginx ile sertifika başarıyla deploy edildi.
nginx -t, certbot certificates, HTTPS response, renewal timer, renew --dry-run ve private backend port bindleri kontrol edilmelidir.
Portainer, Open WebUI, n8n ve diğer self-hosted servisleri HTTPS ile yayınlamak için EKA Sunucu Linux VPS paketlerini inceleyebilirsiniz.
Güncellendi: 10.08.2026