Let’s Encrypt Sertifika Otomasyonu: Certbot, DNS-01 ve Yenileme

Sertifikanın gece yarısı dolması, otomasyonu yarım kurulmuş bir sunucunun tipik arızasıdır: Certbot yenilemiştir ama Nginx reload edilmemiştir, ya da bir CDN kuralı doğrulama isteğini kaynağa hiç ulaştırmamıştır. Let’s Encrypt sertifikayı ücretsiz verir; asıl iş alma, yenileme ve servise yükleme adımlarını kimsenin hatırlamasına gerek kalmadan çalışan bir düzene bağlamaktır. Aşağıda doğrulama yöntemi seçimi, Certbot ve acme.sh ile yenileme, deploy hook, CDN arkasındaki tuzaklar ve yenileme hatalarının izlenmesi ele alınıyor.

ACME doğrulama yöntemleri

Let’s Encrypt, sertifika başvurusunu RFC 8555 ile tanımlanan ACME protokolüyle alır. Sertifika vermeden önce başvuranın alan adını kontrol ettiğini kanıtlamasını ister; buna “challenge” denir. Let’s Encrypt’in desteklediği üç yöntem vardır:

• HTTP-01: İstemci, http://alanadi/.well-known/acme-challenge/<token> adresine belirli bir içerik koyar; Let’s Encrypt bu adresi 80 numaralı port üzerinden birden fazla ağ konumundan sorgular.
• DNS-01: İstemci, _acme-challenge.alanadi adına belirli bir değere sahip TXT kaydı oluşturur.
• TLS-ALPN-01: Doğrulama 443 numaralı port üzerinde özel bir TLS el sıkışmasıyla yapılır. Certbot’un yerleşik eklentileri bu yöntemi desteklemez; daha çok ACME’yi kendi içinde barındıran sunucu ve proxy yazılımlarında kullanılır.

Let’s Encrypt sertifikaları uzun süredir 90 gün geçerlidir ve hem Let’s Encrypt’in duyurduğu planlar hem de CA/Browser Forum kararları sertifika ömrünün kademeli olarak kısalacağını gösteriyor. Ömür kısaldıkça elle yenileme sürdürülemez hale gelir. Takvime not düşmek yöntem değildir. Güncel takvimi Let’s Encrypt duyurularından takip edin ve otomasyonu ömürden bağımsız çalışacak şekilde kurun.

HTTP-01 ve DNS-01 karşılaştırması

Ölçüt	HTTP-01	DNS-01
Wildcard (*.example.com)	Desteklenmez	Desteklenir
Port 80 erişimi	Gerekli	Gerekmez
İnternete kapalı iç sunucu	Kullanılamaz	Kullanılabilir
Gereken yetki	Web köküne yazma	DNS bölgesine yazma (API)
Birden çok sunucu / yük dengeleyici	İstek başka düğüme düşebilir	Sunucu sayısından bağımsız
Güvenlik riski	Düşük	API anahtarı ele geçerse bölge değiştirilebilir

Pratik karar: tek sunuculu, internete açık bir kurumsal web sitesi için HTTP-01 en basit yoldur. Wildcard gerekiyorsa, sunucu internete kapalıysa, birden fazla düğüm aynı alan adını sunuyorsa ya da önde bir CDN varsa DNS-01 tercih edilir. DNS-01’de API belirtecini yalnızca ilgili bölgede DNS düzenleme yetkisiyle sınırlayın; DNS sağlayıcınız ayrıntılı yetki vermiyorsa _acme-challenge kaydını CNAME ile yalnızca bu iş için kullanılan ayrı bir bölgeye devretmek riski daraltır. DNS belirteci, alan adının anahtarıdır. Let’s Encrypt’in yöntem ayrıntıları Challenge Types belgesinde yer alır.

Certbot ile kurulum ve yenileme

Certbot, EFF’nin geliştirdiği ve dağıtım paketleri ile snap üzerinden kurulabilen ACME istemcisidir. Üç tipik kullanım:

# 1) Nginx eklentisi: doğrulama ve server bloğu düzenlemesini Certbot yapar
certbot --nginx -d example.com -d www.example.com

# 2) Webroot: yapılandırmaya dokunmadan, mevcut web kökü üzerinden HTTP-01
certbot certonly --webroot -w /var/www/example.com/public -d example.com -d www.example.com

# 3) DNS-01 ve wildcard (certbot-dns-cloudflare eklentisiyle)
certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

Cloudflare kimlik dosyası tek satırdır (dns_cloudflare_api_token = …) ve chmod 600 ile yalnız root’un okuyabileceği şekilde korunmalıdır; belirteç Cloudflare panelinde yalnızca ilgili bölge için DNS düzenleme yetkisiyle oluşturulmalıdır. Elle yönetilen sunucularda certonly daha öngörülebilirdir: sertifika yolu sabit kalır, server bloğunu siz yazarsınız ve Certbot yapılandırmanıza dokunmaz. Üretimde sürpriz istemezsiniz.

Yenilemeyi Certbot paketi kurar: dağıtım paketiyle kurulumlarda certbot.timer, snap kurulumlarında snap.certbot.renew.timer adlı systemd zamanlayıcısı günde iki kez certbot renew çalıştırır. renew yalnızca yenileme zamanı gelmiş sertifikaları işler. Kurulumdan hemen sonra şunları doğrulayın:

systemctl list-timers | grep -i certbot
certbot certificates            # sertifikalar, alan adları, bitiş tarihleri
certbot renew --dry-run         # staging ortamında tam yenileme provası

Her sertifikanın yenileme parametreleri (doğrulama yöntemi, webroot yolu, hook’lar) /etc/letsencrypt/renewal/<ad>.conf dosyasında saklanır; yenileme ilk alımdaki yöntemle yapılır. Deneme yaparken --test-cert (--staging) seçeneğiyle Let’s Encrypt’in test ortamını kullanın. Üretim ortamında art arda başarısız denemeler hız sınırına takılır ve o alan adı için gerçek sertifika almayı da bir süre engeller.

acme.sh alternatifi

Kabuk betiği olarak çalışan acme.sh, çok sayıda DNS sağlayıcısını destekler ve root gerektirmeden kurulabilir. Gözden kaçan ayrıntı: acme.sh’ın varsayılan sertifika otoritesi Let’s Encrypt değildir; Let’s Encrypt kullanmak için bunu açıkça belirtin.

acme.sh --set-default-ca --server letsencrypt
export CF_Token="..."   # Cloudflare API belirteci
acme.sh --issue --dns dns_cf -d example.com -d '*.example.com'
acme.sh --install-cert -d example.com \
  --key-file /etc/nginx/ssl/example.com.key \
  --fullchain-file /etc/nginx/ssl/example.com.fullchain.pem \
  --reloadcmd "systemctl reload nginx"

--install-cert ile tanımlanan hedef yollar ve yeniden yükleme komutu kaydedilir; acme.sh’ın kendi cron görevi yenilemede dosyaları bu yollara kopyalayıp komutu çalıştırır. Web sunucusunu acme.sh’ın iç dizinine doğrudan yönlendirmeyin.

Deploy hook ve servis yeniden yükleme

Yenileme başarılı olabilir; site yine eski sertifikayı sunar. Nginx, Apache, Postfix veya HAProxy sertifikayı belleğe yükler ve reload görene kadar eskisini kullanır. Certbot’ta bunun için deploy hook kullanılır. Deploy hook yalnızca bir sertifika gerçekten yenilendiğinde çalışır; her renew çağrısında çalışmaz.

#!/bin/sh
# /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh  (chmod 755)
set -e
nginx -t && systemctl reload nginx

# Sertifikayı başka servisler de kullanıyorsa:
case "$RENEWED_DOMAINS" in
  *mail.example.com*) systemctl reload postfix ;;
esac

Certbot, hook’a RENEWED_LINEAGE (sertifikanın live dizini) ve RENEWED_DOMAINS (boşlukla ayrılmış alan adları) ortam değişkenlerini geçirir. Tek bir sertifikaya özel hook gerekiyorsa ilk alımda --deploy-hook "systemctl reload nginx" parametresi verilebilir; bu değer o sertifikanın yenileme yapılandırmasına kaydedilir.

Sertifikanın başka bir makineye (yük dengeleyici, container, Windows sunucu) taşınması gerekiyorsa hook içinde kopyalama yapılır. Bu durumda hedef sistemdeki erişim yalnızca sertifika dosyalarını yazabilen kısıtlı bir kullanıcıyla sınırlanmalı ve kopyalama başarısız olduğunda hook sıfır olmayan bir çıkış kodu döndürmelidir ki hata loglarda görünsün. Sessiz hook, sessiz arızadır. Container tabanlı yayınlarda sertifikanın reverse proxy container’ına nasıl bağlanacağı Nginx reverse proxy yapılandırması rehberindeki yapıyla birlikte düşünülmelidir.

Proxy ve CDN arkasında doğrulama

HTTP-01 hatalarında suç nadiren Certbot’tadır; sorun çoğu zaman isteğin yolundaki bir katmandadır. Kontrol sırası:

• Yönlendirmeler: Let’s Encrypt HTTP-01’de yönlendirmeleri takip eder, ancak yalnızca 80 ve 443 portlarına ve http/https şemalarına. Başka bir porta veya alan adına giden yönlendirme kuralı doğrulamayı bozar.
• IPv6: Alan adının AAAA kaydı varsa Let’s Encrypt doğrulamayı öncelikle IPv6 üzerinden dener. AAAA kaydı eski bir sunucuyu gösteriyorsa ya da web sunucusu IPv6’da yanlış site ile yanıt veriyorsa doğrulama başarısız olabilir; AAAA kaydını ya düzeltin ya da kaldırın.
• CDN ve WAF: Bot koruması, ülke engeli, “saldırı altında” modları veya /.well-known/ yolunu önbelleğe alan kurallar doğrulama isteğini kaynağa ulaştırmaz. Bu yol için istisna tanımlayın ya da DNS-01’e geçin.
• Çok düğümlü yapı: Yük dengeleyici doğrulama isteğini sertifikayı istemeyen düğüme gönderebilir. Ortak bir webroot, /.well-known/acme-challenge/ yolunu tek düğüme yönlendiren bir kural veya DNS-01 kullanın.
• CAA kaydı: Alan adında CAA kaydı varsa letsencrypt.org için issue (wildcard için issuewild) izni bulunmalıdır.

Cloudflare özelinde, ziyaretçiye giden sertifikayı zaten Cloudflare sunduğundan kaynak sunucudaki sertifikanın görevi CDN–kaynak arasındaki bağlantıyı korumaktır. Burada Let’s Encrypt yerine Cloudflare’in kaynak sertifikası (Origin CA) da kullanılabilir; ancak bu sertifika yalnızca Cloudflare tarafından güvenilir sayılır ve proxy kapatıldığında tarayıcılar hata verir. Cloudflare katmanının önbellek tarafı için Cloudflare, WP Rocket ve Redis yazısına bakabilirsiniz.

Yenileme hatalarını izlemek

Otomasyon sessizce bozulur. Let’s Encrypt 2025’te süre dolum uyarı e-postalarını sonlandırdı; uyarıyı artık kendiniz üretmelisiniz. İzlemeyi iki katmanlı kurun:

1. İçeriden: Zamanlayıcının çalıştığını ve hata vermediğini izleyin. journalctl -u certbot.service (snap’te snap.certbot.renew.service) ve /var/log/letsencrypt/letsencrypt.log son yenileme denemelerini gösterir. systemd’de OnFailure= ile başarısız çalışmada bildirim gönderen bir birim tanımlanabilir.
2. Dışarıdan: Asıl önemli olan, sunulan sertifikanın bitiş tarihidir. Dosyadaki değil, ağ üzerinden sunulan sertifikayı kontrol edin; böylece reload unutulmuş veya CDN eski sertifikayı sunuyor gibi durumlar da yakalanır.

#!/bin/sh
# Örnek: sunulan sertifikada 14 günden az kaldıysa uyarı ver
HOST=www.example.com
if ! echo | openssl s_client -connect "$HOST:443" -servername "$HOST" 2>/dev/null \
     | openssl x509 -noout -checkend $((14*86400)); then
  echo "UYARI: $HOST sertifikası 14 gün içinde doluyor" | logger -t cert-check
fi

Bu kontrol bir izleme sistemine (uptime servisi, Zabbix, Prometheus blackbox exporter vb.) bağlanırsa tüm alan adları için tek ekrandan görünürlük sağlanır. Eşiği, otomatik yenilemenin birkaç kez denenmesine fırsat verecek kadar geniş seçin; uyarı geldiğinde sorunu çözmek için hâlâ zamanınız olur. Son gün gelen uyarı geç kalmıştır.

Yenileme hatasında ilk bakılacak yerler:

Hata belirtisi	Olası neden
Doğrulamada 404	Webroot yolu değişmiş veya server bloğu /.well-known/ yolunu başka yere yönlendiriyor
Doğrulamada zaman aşımı	Port 80 güvenlik duvarında kapalı veya AAAA kaydı hatalı
DNS-01’de kayıt bulunamadı	API belirteci süresi dolmuş, yetkisi daralmış veya yayılma süresi yetersiz
Yenilendi ama eski sertifika sunuluyor	Deploy hook yok veya başarısız
Hız sınırı hatası	Test sırasında üretim ortamının tekrar tekrar kullanılması

Çok sayıda alan adını tek sunucuda barındıran yapılarda sertifika yönetimi panel üzerinden de yürütülebilir; bu senaryo Virtualmin ile çok siteli sunucu yönetimi yazısında ele alınıyor. Alınan sertifikanın hangi protokol ve şifrelerle sunulacağı ise TLS yapılandırması rehberinin konusu. Sertifika, yedek ve izleme düzenini sunucu tarafında birlikte kurmak için Linux VPS ve hosting yönetimi hizmetimize bakabilirsiniz; Certbot seçeneklerinin tamamı Certbot belgelerinde yer alıyor.

Sık sorulan sorular

Wildcard sertifika için HTTP-01 kullanabilir miyim?

Hayır. Let’s Encrypt wildcard sertifikaları yalnızca DNS-01 doğrulamasıyla verir. Bunun için ACME istemcinizin DNS sağlayıcınızın API’si üzerinden TXT kaydı oluşturabilmesi ya da _acme-challenge kaydının otomasyona uygun bir bölgeye CNAME ile devredilmesi gerekir.

certbot renew komutunu her gün çalıştırmak sertifikayı her gün yeniler mi?

Hayır. renew yalnızca yenileme zamanı gelmiş sertifikaları işler, diğerlerini atlar. Günde iki kez çalışmasının nedeni budur: geçici bir hata olursa bir sonraki çalışmada yeniden denenir.

Sertifika yenilendi ama site hâlâ eski sertifikayı gösteriyor, neden?

Web sunucusu sertifikayı başlangıçta belleğe yükler; dosya değişse de yeniden yüklenmeden yeni sertifikayı sunmaz. Deploy hook ile yenileme sonrası systemctl reload nginx veya apache2 çalıştırın. Sertifika dosyasını kopyalayan başka servisler (posta sunucusu, container, yük dengeleyici) varsa onları da hook’a ekleyin.

Cloudflare proxy açıkken Let’s Encrypt sertifikası alınabilir mi?

Evet. HTTP-01 isteği Cloudflare üzerinden kaynağa ulaşıyorsa doğrulama çalışır; ancak WAF, bot koruması veya yönlendirme kuralları /.well-known/acme-challenge/ yolunu engelleyebilir. En az sorun çıkaran yöntem, yalnızca ilgili bölgede DNS düzenleme yetkisi olan bir Cloudflare API belirteciyle DNS-01 kullanmaktır.