Certbot: Let's Encrypt sertifikalarını doğru şekilde almak ve yenilemek

Certbot nedir ve gerçekte ne yapar

Certbot, Electronic Frontier Foundation'ın sürdürdüğü ücretsiz, açık kaynaklı bir ACME istemcisidir. ACME, Let's Encrypt'in (ve giderek artan sayıda başka CA'nın) insan müdahalesi olmadan sertifika vermek için kullandığı protokoldür. Certbot bu protokolü sizin yerinize konuşur: bir hesap anahtarı oluşturur, CA'dan sertifika ister, alan adının sizin kontrolünüzde olduğunu kanıtlar, sertifikayı ve anahtarı diske kaydeder ve izin verirseniz web sunucusu yapılandırmanızı düzenleyip her şeyi süresi dolmadan yeniler.

Kontrolün kanıtı bir challenge'dır ve certbot bunlardan ikisini destekler. HTTP-01: CA, 80 numaralı portta http://example.com/.well-known/acme-challenge/<token> adresinden rastgele bir token ister ve certbot o dosyanın sunulmasını sağlar. DNS-01: CA, _acme-challenge.example.com adresindeki bir TXT kaydına bakar ve certbot (ya da siz) onu yayımlar. HTTP-01 kolay olan varsayılandır; DNS-01 ise wildcard almanın tek yolu ve internetten erişilemeyen bir sunucu için sertifika almanın yoludur.

İşi kimin yaptığını iki tür eklenti belirler. Authenticator challenge'a cevap verir (--nginx, --apache, --webroot, --standalone, --manual ya da --dns-cloudflare gibi bir DNS eklentisi). Installer sertifikayı bir sunucu yapılandırmasına yerleştirir (nginx ya da apache). certbot --nginx ikisini de yapar; certbot certonly ... yalnızca sertifikayı alır ve yapılandırmayı size bırakır.

Her şey /etc/letsencrypt altına yazılır. Sunucuyu yönlendireceğiniz dosyalar /etc/letsencrypt/live/<cert-name>/ içindedir: fullchain.pem (sertifikanız artı ara sertifika) ve privkey.pem. Bunlar archive/ içine giden symlink'lerdir, bu yüzden yolları yenilemeler boyunca hiç değişmez. Sertifikanın ne olduğu ve neden ücretsiz olduğuyla ilgili arka plan için ücretsiz SSL sertifikaları rehberini okuyun; bu rehber araçla ilgili.

Certbot kurulumu: önce snap, sonra dağıtım paketleri

Certbot projesi Linux'ta snap paketini öneriyor. Güncel sürümü (2026'da 5.x) takip eder, kendi Python'unu içinde getirir ve yenileme için bir systemd timer kurar. /etc/letsencrypt üzerinde kavga eden iki certbot olmasın diye önce dağıtımın kopyasını kaldırın: sudo apt remove certbot, sudo dnf remove certbot ya da sudo yum remove certbot.

Dağıtım paketleri çalışır ve birçok sunucuda zaten kurulu olan da odur: Debian ve Ubuntu'da sudo apt install certbot python3-certbot-nginx (ya da python3-certbot-apache), RHEL, Rocky ve Alma'da EPEL'den aynı paket adları. Bedeli yaştır: bir LTS dağıtımı birkaç major sürüm geride bir certbot getirebilir ve Let's Encrypt sertifika ömürlerini kısaltırken bu önemlidir (yenileme bölümüne bakın). Tercih ederseniz certbot PyPI'da ve Docker imajları olarak da yayımlanıyor (certbot/certbot ve her DNS eklentisi için ayrı bir imaj).

Kurulumdan sonra certbot --version elinize ne geçtiğini söyler; sudo certbot certificates ise yönettiği her sertifikayı alan adları, son kullanma tarihi ve dosya yollarıyla listeler.

Linux'ta önerilen kurulum (snap)

# remove an OS-packaged certbot first, if present
sudo apt remove certbot

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

certbot --version
sudo certbot certificates

nginx ve Apache için sertifika almak

nginx ve Apache eklentileri en kısa yoldur. sudo certbot --nginx -d example.com -d www.example.com, server_name'i eşleşen server bloğunu bulur, HTTP-01'e onun üzerinden cevap verir, ssl_certificate ve ssl_certificate_key satırlarını o bloğa yazar ve nginx'i yeniden yükler. Yeni sürümler HTTP'den HTTPS'e yönlendirmeyi varsayılan olarak ekler; --no-redirect bunu kapatır. --apache aynı işi virtual host'larla yapar. İkisi de alan adıyla eşleşen bir server_name / ServerName ister; yoksa certbot hangi bloğu düzenleyeceğini bilemez. Sunucunun kendisine yeni misiniz? nginx nedir rehberiyle başlayın.

Webroot, certbot'un yapılandırmanıza dokunmamasını istediğinizde doğru seçimdir: challenge dosyasını, çalışan sunucunuzun zaten sunduğu bir dizine yazar. certonly, iki ssl_ satırını bir kez kendinizin eklemesi demektir; sonrasında yenilemeler yalnızca aynı yolların arkasındaki dosyaları değiştirir.

Standalone, 80 numaralı portta kendine ait küçük bir web sunucusu başlatır. Web sunucusu olmayan ya da nginx veya Apache dışında bir sunucu çalıştıran makineler içindir. Sertifika alırken ve her yenilemede 80 numaralı port boş olmalıdır, bu yüzden diğer sunucuyu bir hook ile durdurun: --pre-hook "systemctl stop haproxy" --post-hook "systemctl start haproxy".

Her -d aynı sertifikaya bir ad ekler ve ilki sertifikanın adı olur. Sonradan bir ad eklemek için komutu tam listeyle ve --cert-name example.com ile yeniden çalıştırın; certbot ikinci bir sertifika oluşturmak yerine eskisini değiştirir.

Sertifika almanın dört yaygın yolu (birini seçin)

# nginx: issue and install
sudo certbot --nginx -d example.com -d www.example.com

# Apache: issue and install
sudo certbot --apache -d example.com -d www.example.com

# webroot: issue only; your server keeps serving /.well-known/acme-challenge/
sudo certbot certonly --webroot -w /var/www/example -d example.com -d www.example.com

# standalone: certbot listens on :80 itself
sudo certbot certonly --standalone -d example.com

# then, in nginx, for the webroot/standalone case:
#   ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
#   ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

DNS-01 ile wildcard sertifikalar

Let's Encrypt *.example.com'u yalnızca DNS-01 üzerinden verir. Wildcard tek bir seviyeyi kapsar (shop.example.com, ama a.shop.example.com değil) ve yalın alan adını kapsamaz; bu yüzden ikisini birlikte isteyin: -d example.com -d '*.example.com'. Kabuk yıldızı genişletmesin diye tırnak içine alın.

Bir DNS eklentisiyle certbot TXT kayıtlarını DNS sağlayıcınızın API'si üzerinden oluşturur ve siler; yenilemeyi otomatik yapan da budur. Cloudflare, Route 53, Google Cloud DNS, DigitalOcean, Linode, OVH, RFC 2136 sunucuları ve diğerleri için resmî eklentiler, çok daha fazlası için üçüncü taraf eklentiler var. snap ile önce eklentilerin root olarak çalışmasına izin verirsiniz (sudo snap set certbot trust-plugin-with-root=ok), sonra eklentinin snap'ini kurarsınız. Kimlik bilgisi dosyasını 600 izniyle tutun ve API token'ına sağlayıcınızın sunduğu en dar yetkiyi verin (Cloudflare için yalnızca o zone'da *Zone: DNS: Edit*).

--manual ile certbot TXT değerini yazdırır ve siz onu elle eklerken bekler. example.com ile *.example.com'u birlikte istemek, aynı _acme-challenge.example.com adı altında iki TXT değeri ister; ikisini ayrı kayıtlar olarak yayımlayın. Enter'a basmadan önce dig +short TXT _acme-challenge.example.com ile kontrol edin. Tuzak şu: DNS işini yapan --manual-auth-hook ve --manual-cleanup-hook betiklerini vermediğiniz sürece manuel bir sertifika otomatik yenilenmez; uzun ömürlü her şey için bir eklenti kullanın.

DNS sağlayıcınızın API'si yoksa, _acme-challenge.example.com'u bir CNAME kaydı ile kontrolünüzdeki bir zone'a yönlendirebilirsiniz; CA, CNAME'i izler ve TXT kaydını orada okur.

Cloudflare DNS eklentisiyle wildcard ve apex (snap)

sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

# /root/.secrets/cloudflare.ini  (chmod 600)
#   dns_cloudflare_api_token = <token with Zone:DNS:Edit>

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

# by hand (no automatic renewal without hooks)
sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com -d '*.example.com'

Otomatik yenileme: timer'lar, hook'lar ve --dry-run

Certbot için cron işi yazmazsınız; paket bunu zaten yaptı. snap snap.certbot.renew.timer systemd timer'ını, Debian ve Ubuntu paketleri certbot.timer'ı kurar; bazı paketler ise /etc/cron.d/ içinde bir dosya kullanır. İş günde iki kez certbot renew çalıştırır; bu komut yalnızca zamanı gelen sertifikaları yeniler, aksi hâlde sessizce çıkar. systemctl list-timers | grep certbot ile görebilirsiniz.

Bir sertifikanın yenileme zamanı ne zaman gelir? Certbot 4.0'dan beri, ömrünün üçte birinden azı kaldığında (10 gün ya da daha kısa ömürlü sertifikalarda yarısı); certbot ayrıca CA'nın ACME Renewal Info (ARI) ipuçlarını da izler. Bu önemli, çünkü Let's Encrypt ömürleri kısaltıyor: varsayılan profil 10 Şubat 2027'de 90 günden 64 güne, Şubat 2028'de 45 güne iniyor. Sabit yazılmış "her 60 günde bir" cron satırıyla yenileyen bir kurulum bozulacak; her gün certbot renew çalıştıran bozulmayacak. Let's Encrypt 2025'te süre dolumu hatırlatma e-postalarını göndermeyi de bıraktı; yenileme sessizce başarısız olursa kimse sizi uyarmaz, sertifikanın son kullanma tarihini kendiniz izleyin.

Yenilemeden sonra sunucuyu yeniden yükleyin. nginx ve Apache installer'ları bunu sizin için yapar. Webroot, standalone ya da bir DNS eklentisiyle, yalnızca bir sertifika gerçekten yenilendiğinde çalışan bir deploy hook ekleyin. Onu sertifikayı alırken komuta koyun (--deploy-hook, /etc/letsencrypt/renewal/<name>.conf içine kaydedilir) ya da /etc/letsencrypt/renewal-hooks/deploy/ içine çalıştırılabilir bir betik bırakın.

Her zaman test edin: sudo certbot renew --dry-run. Tam yenilemeyi gerçek challenge'larla Let's Encrypt staging ortamına karşı çalıştırır; canlı sertifikalarınıza dokunmaz ve production rate limit'lerini harcamaz.

Timer'ı kontrol edin, yenilemeyi test edin, her yenilemeden sonra nginx'i yeniden yükleyin

systemctl list-timers | grep certbot

sudo certbot renew --dry-run

# reload nginx whenever any certificate is renewed
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

# when does each certificate expire?
sudo certbot certificates

Gerçekten takılabileceğiniz Let's Encrypt rate limit'leri

Let's Encrypt'in limitleri normal kullanım için cömert, bir hata ayıklama oturumunda ise can sıkıcıdır. Can yakanlar şunlar:

Aynı ad kümesi için 7 günde 5 sertifika. example.com + www.example.com'u bir hafta içinde beş kez almak, örneğin bir provisioning betiğini yeniden çalıştırarak ya da her container başlangıcında /etc/letsencrypt'i silerek, o kümeyi günlerce kilitler. Hata *too many certificates already issued for this exact set of identifiers* der ve bir yeniden deneme zamanı verir. Bu limitin istisnası yoktur. Ad kümesini değiştirmek (bir ad daha eklemek) yeni bir limit açar, ama gerçek çözüm /etc/letsencrypt'i kalıcı depolamada tutmaktır.

Hesap başına, hostname başına saatte 5 başarısız doğrulama. Yanlış bir DNS kaydı artı bir yeniden deneme döngüsü bunu dakikalar içinde tüketir.

Kayıtlı alan adı başına 7 günde 50 sertifika (example.com'un tüm alt alan adları birlikte sayılır) ve hesap başına 3 saatte 300 yeni sipariş. Çok sayıda alt alan adı olan barındırma platformları önce bunlara takılır.

Yenilemelere iyi davranılır: güncel certbot'un yaptığı gibi ARI kullanan bir yenileme tüm limitlerden muaftır; aynı ad kümesinin düz bir yenilemesi ise alan adı başına ve sipariş başına limitlerden muaftır.

Denemeler için kural: --test-cert (takma adı --staging) ekleyin ya da --dry-run kullanın. Staging'in limitleri çok daha yüksektir ve tarayıcıların güvenmediği sertifikalar verir; challenge'ı çalışır hâle getirirken istediğiniz de tam olarak budur.

Sık görülen certbot hataları ve çözümleri

80 numaralı portta timeout during connect / connection refused. Siteniz yalnızca HTTPS sunsa bile HTTP-01 her zaman 80 numaralı porttan başlar. 80 numaralı portu güvenlik duvarında ve bulut security group'unda açın; onu HTTPS'e yönlendirmek sorun değildir, çünkü CA yönlendirmeleri izler. 80 numaralı port açılamıyorsa DNS-01'e geçin.

/.well-known/acme-challenge/ üzerinde invalid response / 404. İstek bir sunucuya ulaştı, ama doğru sunucuya ya da doğru dizine değil. Tipik nedenler: A kaydı hâlâ eski bir host'u gösteriyor, bir load balancer isteği başka bir düğüme gönderiyor, bir location bloğu ya da rewrite yolu yakalıyor veya -w yanlış webroot'u gösteriyor. Kendiniz test edin: .well-known/acme-challenge/ altında bir dosya oluşturun ve dışarıdan düz HTTP ile curl edin.

Başka yeri gösteren bir AAAA kaydı. Adın bir IPv6 adresi varsa Let's Encrypt önce IPv6 üzerinden doğrular. Başka bir sunucudan cevap veren eskimiş bir AAAA kaydı, IPv4 sorunsuz olsa bile doğrulamayı başarısız kılar. AAAA kaydını düzeltin ya da silin; dig AAAA example.com onu gösterir.

DNS problem: NXDOMAIN / no valid A records. Ad henüz çözülmüyor. Yayılmayı bekleyin ve kaydı yalnızca kendi makinenizde değil, dışarıdaki bir resolver'da da kontrol edin.

CAA record prevents issuance. Alan adındaki (ya da bir üst alan adındaki) CAA kaydı sertifika vermesine izin verilen CA'ları listeliyor ve Let's Encrypt aralarında yok. example.com. CAA 0 issue "letsencrypt.org" ekleyin; wildcard için bir issuewild tanımladıysanız onu da. Arka plan için DNS nedir.

Incorrect TXT record / no TXT record found. DNS-01, kayıt yayılmadan kontrol edildi ya da iki wildcard değerinden yalnızca biri yayımlandı. Eklentinin --dns-<provider>-propagation-seconds değerini yükseltin ya da manuel modda daha uzun bekleyin.

Could not automatically find a matching server block. nginx eklentisi, istenen adla aynı olan bir server_name ister. Ekleyin, nginx -t çalıştırın ve yeniden deneyin.

Too many certificates already issued. Yukarıdaki yinelenen sertifika limiti. Elinizdeki sertifikayı kullanın (certbot certificates) ve bundan sonra --staging ile test edin.

Windows'ta certbot: Windows'a özgü bir ACME istemcisi kullanın

Certbot Windows desteğini sonlandırdı. Son Windows yükleyicisi Şubat 2024'te certbot 2.9.0 ile çıktı ve certbot sitesi artık Windows kullanıcılarını topluluğun listelediği alternatiflere yönlendiriyor. İndirme sitelerinde hâlâ bulunan eski yükleyiciler yıllarca geride ve Let's Encrypt'in devreye aldığı yenileme değişikliklerini almayacak; üzerlerine bir şey kurmayın.

Yerine ne kullanacağınız sunucuya bağlı:

IIS ya da herhangi bir Windows sunucu: Olağan seçim win-acme oldu: sertifikayı IIS'te bağlayan, Windows sertifika deposuna ya da PEM/PFX dosyalarına yazan ve yenileme için zamanlanmış bir görev oluşturan bir komut satırı aracı. Geliştiricisi artık geriye dönük uyumlu, doğrudan yerine geçen bir sürüm olarak tanımlanan simple-acme'yi geliştiriyor; yeni bir kurulumdan önce o projeye bakın.

PowerShell otomasyonu: Posh-ACME, wildcard için geniş bir DNS eklentisi setine sahip bir PowerShell modülüdür.

Grafik arayüz tercih ediyorsanız: Certify The Web, IIS için grafik bir istemcidir.

Gerçekten certbot istiyorsanız: sertifika almak için onu WSL 2 içinde çalıştırın, sonra dosyaları Windows'a aktarın. Bu, başka yere kopyaladığınız DNS-01 sertifikaları için pratiktir; otomatik bağlama gereken bir IIS sitesi için daha az.

Bunların hiçbiri bir tavsiye (endorsement) değildir: hepsi üçüncü taraf projelerdir, onlara güvenmeden önce güncel belgelerini okuyun.

Sertifikaları iptal etmek ve silmek

Özel anahtar sızmış olabilirse ya da alan adı artık sizin kontrolünüzde değilse revoke (iptal) edin. Certbot'un ya sertifika adına ya da sertifika dosyasına ve bir nedene ihtiyacı vardır: keycompromise, superseded, cessationofoperation, affiliationchanged ya da unspecified (varsayılan). İptalden sonra certbot yerel dosyaları silmeyi önerir; evet deyin, yoksa iptal edilmiş bir sertifikayı yenilemeye çalışmaya devam eder. Anahtar sızdıysa yerine geleni yeni bir anahtarla alın; certbot bunu varsayılan olarak yapar.

Bir sertifikayı yalnızca kullanmayı bıraktığınızda, örneğin bir siteyi taşıdıktan sonra, iptal etmeden silin: certbot delete --cert-name example.com onu /etc/letsencrypt'ten ve yenilemeden kaldırır. Önce sunucu yapılandırmasındaki ilgili ssl_ satırlarını kaldırın, yoksa nginx bir sonraki yeniden yüklemede başlamaz.

Let's Encrypt OCSP çalıştırmayı bıraktı; tarayıcılar iptalleri CRL'ler üzerinden öğreniyor, bu yüzden bir iptal her yerde anında görünmez. Özel anahtarları yalnızca root'un okuyabileceği şekilde tutmanın bir nedeni daha.

Ele geçirilmiş bir sertifikayı iptal edin ya da artık gerekmeyeni kaldırın

sudo certbot revoke --cert-name example.com --reason keycompromise

sudo certbot delete --cert-name example.com

CDN arkasında: sertifikayı kim tutar

Bir site bir CDN'in ya da başka bir reverse proxy'nin arkasına geçtiğinde ziyaretçiler artık origin'inizin sertifikasını görmez. Edge TLS'i kendi sertifikasıyla sonlandırır ve edge'den origin'inize giden bağlantı ayrı bir el sıkışmadır. Bu ikinci adımı güvence altına almak için origin'de certbot'u tutabilirsiniz, ama tarayıcının kontrol ettiği sertifika edge'inkidir.

CDN.com.tr'de edge sertifikasını Auto SSL yönetir: her sertifika, ayrı bir ücret alınmayan, alan adı doğrulamalı (DV) bir Let's Encrypt sertifikasıdır. Bir hostname'i CNAME ile edge'e yönlendirin; o ad HTTP üzerinden doğrulanan kendi sertifikasını alır. DNS'inizi CDN.com.tr'ye devredin; kök alan adı, kökü ve birinci seviyedeki her alt alan adını kapsayan, bir DNS kaydıyla doğrulanan bir wildcard alır. Sertifika, alan adı doğrulandığında ve DNS'i bizi gösterdiğinde istenir ve süresi dolmadan 30 gün önce otomatik olarak yenilenir; izlemeniz gereken bir certbot timer'ı yoktur.

Canlı bir siteyi mi taşıyorsunuz? Kesintisiz geçiş sihirbazı, wildcard'ı siz geçiş yapmadan önce mevcut DNS sağlayıcınızdaki bir TXT kaydıyla alır; bu bir certbot --manual DNS-01 çalıştırmasına çok benzer ve tıpkı onun gibi, DNS CDN.com.tr dışında kaldığı sürece otomatik yenilenmez. Başka bir CA'dan alınmış OV ya da EV sertifikanız varsa, onu yükleyip bir hostname'e bağlayabilirsiniz; otomatik olanla aynı TLS politikasını alır. Edge'in neyi müzakere ettiğini TLS rehberi anlatıyor; HTTPS güvenilir hâle geldiğinde bir sonraki adım HSTS.