Certbot İleri Düzey Kullanım ve İpuçları

Certbot'u ilk kez kullananların çoğu certbot --nginx komutunu çalıştırıp sertifikayı alır, işini bitmiş sayar. Oysa gerçek sunucu ortamlarında bu tek komut çoğu zaman yetmez. Web sunucusu çalışmıyorken sertifika yenilemek, bir alt alan adının tümünü kapsayan wildcard sertifika almak, yenileme sonrasında farklı servisleri yeniden yüklemek ya da otomasyonu üretime almadan önce test etmek gerektiğinde Certbot'un ileri düzey seçeneklerine ihtiyaç duyarsınız. Bu rehberde, kıdemli bir sistem yöneticisinin günlük pratiğinden damıtılmış, üretimde çalışan örneklerle ilerleyeceğiz.

Anlatacağımız her komut gerçek senaryolara dayanıyor. Standalone, webroot ve web sunucusu eklentileri arasındaki farkları netleştirecek, DNS-01 doğrulamasıyla wildcard sertifikayı adım adım alacak, --deploy-hook ile yenileme sonrası otomasyonu kuracak ve --dry-run ile tüm bu akışı hiçbir kotayı harcamadan güvenle test edeceğiz. Let's Encrypt ile ücretsiz SSL kurulumunun temellerini henüz görmediyseniz, önce Let's Encrypt ücretsiz SSL rehberimize göz atmanızı öneririm; burada işin bir adım ötesine geçiyoruz.

Certbot Kipleri Standalone Webroot ve Eklentiler#

Certbot'un doğrulama (challenge) ve kurulum davranışını belirleyen üç temel yaklaşım vardır. Hangisini seçeceğiniz, sunucuda çalışan web servisine ve o an 80/443 portlarını kimin dinlediğine bağlıdır. Aralarındaki farkı bir tabloda görmek karar vermeyi kolaylaştırır.

Standalone kipi, doğrulama süresince kendi mini HTTP sunucusunu ayağa kaldırır. Bu nedenle 80 portunun boş olması gerekir; aksi halde nginx veya apache zaten portu tuttuğu için Certbot bağlanamaz. Webroot kipi ise tam tersine mevcut web sunucusunu hiç durdurmaz; doğrulama dosyasını sitenizin kök dizinindeki gizli bir klasöre (.well-known/acme-challenge/) yazar ve Let's Encrypt bu dosyayı HTTP üzerinden okuyarak alan adını size ait olduğunu doğrular. Eklentiler (--nginx, --apache) ise webroot benzeri bir doğrulama yapıp ek olarak sanal sunucu bloklarınızı da otomatik düzenler.

Standalone Kipi Ne Zaman ve Nasıl Kullanılır#

Standalone kipini en çok, sunucuda henüz bir web sunucusu kurulu değilken ya da SSL kullanan servis Nginx/Apache değilken (örneğin bir mail sunucusu, RabbitMQ, özel bir uygulama) tercih edersiniz. Doğrulama için portu geçici olarak kendisi açacağından, çakışmayı önlemek gerekir.

# 80 portunu bir servis tutuyorsa önce durdurun
sudo systemctl stop nginx

# Standalone doğrulama ile sertifika al
sudo certbot certonly --standalone \
  -d panel.ornekfirma.com \
  --preferred-challenges http \
  --agree-tos -m [email protected] --no-eff-email

# İşlem bittikten sonra servisi geri başlatın
sudo systemctl start nginx

Buradaki certonly alt komutu önemli: yalnızca sertifikayı alır, hiçbir web sunucusu yapılandırmasına dokunmaz. Sertifikayı bir mail sunucusu ya da uygulama sunucusu için kullanacaksanız tam olarak bunu istersiniz. Yenileme sırasında da aynı port çakışması yaşanmaması için, standalone ile aldığınız sertifikalarda yenileme öncesi/sonrası servisi durdurup başlatan hook'lar tanımlamak iyi bir alışkanlıktır. Bunu birazdan --pre-hook ve --deploy-hook ile göstereceğiz. Standalone kipi hızlıdır ama kesinti yaratır; üretimdeki yoğun bir web sitesinde her yenilemede birkaç saniyelik kesinti istemiyorsanız webroot çok daha uygundur.

Webroot Kipi ile Kesintisiz Sertifika#

Webroot, çalışan bir web sitesinde sertifika almanın en zarif yoludur çünkü hiçbir servisi durdurmaz. Certbot doğrulama dosyasını verdiğiniz kök dizine yazar, Let's Encrypt onu HTTP ile çeker. Tek şart, o kök dizinin gerçekten alan adının HTTP kökü olması ve .well-known/acme-challenge/ yolunun dışarıya açık olmasıdır.

sudo certbot certonly --webroot \
  -w /var/www/ornekfirma \
  -d ornekfirma.com -d www.ornekfirma.com \
  --agree-tos -m [email protected] --no-eff-email

Nginx tarafında doğrulama isteğinin engellenmediğinden emin olmalısınız. Bazı katı yapılandırmalar gizli dosyaları (nokta ile başlayanları) engeller; bu durumda ACME yolunu açıkça beyaz listeye almanız gerekir.

server {
    listen 80;
    server_name ornekfirma.com www.ornekfirma.com;

    # ACME doğrulama isteklerini her zaman geçir
    location /.well-known/acme-challenge/ {
        root /var/www/ornekfirma;
        default_type "text/plain";
        allow all;
    }

    # Diğer tüm trafiği HTTPS'e yönlendir
    location / {
        return 301 https://$host$request_uri;
    }
}

Birden çok sanal sunucunuz varsa her alan adı için ayrı -w verebilirsiniz; Certbot -w /yol1 -d alan1.com -d www.alan1.com -w /yol2 -d alan2.com biçiminde her -w ifadesinden sonra gelen alan adlarını o köke eşler. Nginx'i sıfırdan kuruyorsanız ve sanal sunucu bloklarını nasıl düzenleyeceğinizden emin değilseniz, Nginx kurulum rehberimizdeki server bloğu örnekleri bu yapılandırmayı oturtmanıza yardımcı olur.

Nginx ve Apache Eklentileriyle Otomatik Yapılandırma#

Eklentiler, işin doğrulama kısmını yapmakla kalmaz; sanal sunucu bloklarınıza SSL yönergelerini de kendisi ekler. Yeni bir sunucuda hız kazanmak isteyenler için idealdir, ama Certbot'un yapılandırma dosyanıza dokunmasını istemiyorsanız --nginx yerine doğrulamayı eklentiyle yapıp kurulumu elle üstlenmek de mümkündür.

# Doğrulamayı ve kurulumu tümüyle Certbot yapsın
sudo certbot --nginx -d ornekfirma.com -d www.ornekfirma.com

# Sadece doğrulama eklentiyle yapılsın, kurulum bana kalsın
sudo certbot certonly --nginx -d ornekfirma.com -d www.ornekfirma.com

Apache tarafında yaklaşım aynıdır; yalnızca eklenti adı değişir.

sudo certbot --apache -d ornekfirma.com -d www.ornekfirma.com

Eklentileri kullanırken dikkat edilecek bir nokta, --redirect ve --hsts gibi bayrakların davranışıdır. --redirect HTTP trafiğini otomatik HTTPS'e yönlendirir, --hsts ise HSTS başlığını ekler. Üretimde HSTS'i açmadan önce tüm alt alan adlarınızın sağlam biçimde HTTPS sunduğundan emin olun; aksi halde tarayıcılar bir süre boyunca HTTP'ye düşmeyi reddeder ve erişim sorunu yaşanabilir. Certbot'un yaptığı değişiklikleri her zaman nginx -t ya da apachectl configtest ile doğrulayıp öyle yeniden yükleyin. Sunucu yönetimini kendiniz üstlenmek istemiyor, bu ince ayarları uzmana bırakmak istiyorsanız sunucu yönetimi hizmetimiz tam olarak bu yükü sizden alır.

DNS-01 ile Wildcard Sertifika Almak#

Wildcard sertifika (örneğin *.ornekfirma.com) tek belgede tüm alt alan adlarını kapsar ve yalnızca DNS-01 doğrulamasıyla alınabilir. HTTP-01 doğrulaması wildcard'ı desteklemez, çünkü Let's Encrypt tek bir alt alan adının HTTP kökünü doğrulayarak tüm alt alanlara yetki veremez. DNS-01'de ise alan adınızın DNS bölgesine geçici bir TXT kaydı ekleyerek bölgenin gerçekten sizin kontrolünüzde olduğunu kanıtlarsınız.

En temiz yol, DNS sağlayıcınızın API'siyle konuşan bir Certbot eklentisi kullanmaktır. Böylece TXT kaydı otomatik eklenir ve doğrulama sonrası silinir. Cloudflare örneği üzerinden gidelim.

# Cloudflare DNS eklentisini kur
sudo apt install python3-certbot-dns-cloudflare

# API bilgilerini gizli bir dosyaya yaz
sudo mkdir -p /root/.secrets
sudo nano /root/.secrets/cloudflare.ini

Kimlik dosyasının içeriği aşağıdaki gibidir; API token yöntemi, hesap genelinde geçerli global anahtardan daha güvenlidir.

# /root/.secrets/cloudflare.ini
dns_cloudflare_api_token = buraya_dns_duzenleme_yetkili_tokeni_yazin

Dosya izinlerini sıkılaştırıp sertifikayı isteyin.

sudo chmod 600 /root/.secrets/cloudflare.ini

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d ornekfirma.com -d '*.ornekfirma.com' \
  --agree-tos -m [email protected] --no-eff-email

Tek çıkan sertifika hem kök alanı hem tüm alt alanları kapsar. DNS sağlayıcınızın hazır bir eklentisi yoksa --manual --preferred-challenges dns ile TXT kaydını elle ekleyip devam edebilirsiniz, ancak bu yöntem elle müdahale gerektirdiği için otomatik yenilemeye uygun değildir. Yenilemenin kesintisiz olmasını istiyorsanız mutlaka API tabanlı bir DNS eklentisi kullanın. Alan adınızı ve DNS yönetimini tek çatı altında toplamak isterseniz alan adı hizmetimiz ile kayıt ve DNS'i aynı panelden yönetebilirsiniz.

deploy-hook ile Yenileme Sonrası Servis Yeniden Yükleme#

Sertifika yenilendiğinde diskteki dosya değişir, ama çalışan servis eski sertifikayı bellekte tutmaya devam eder. Bu yüzden yenileme sonrası ilgili servisi yeniden yüklemek şarttır. Certbot bunun için üç hook sunar: --pre-hook (yenilemeden önce), --post-hook (yenilemeden sonra, her koşulda) ve --deploy-hook (yalnızca sertifika gerçekten yenilendiyse).

Doğru araç neredeyse her zaman --deploy-hook'tur, çünkü sadece yeni bir sertifika yazıldığında tetiklenir ve gereksiz yere servis sarsmaz.

# İlk alımda deploy-hook'u sertifikaya bağla
sudo certbot certonly --webroot -w /var/www/ornekfirma \
  -d ornekfirma.com -d www.ornekfirma.com \
  --deploy-hook "systemctl reload nginx"

Bir kez bu şekilde tanımladığınızda, hook o sertifikanın yenileme yapılandırmasına (/etc/letsencrypt/renewal/ornekfirma.com.conf) kaydedilir ve otomatik yenilemede kendiliğinden çalışır. Birden fazla servisi aynı anda yeniden yüklemeniz gerekiyorsa (örneğin hem web hem mail sunucusu aynı sertifikayı kullanıyorsa), hook'u küçük bir betiğe çıkarmak daha temizdir.

# /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh
#!/bin/bash
set -e
systemctl reload nginx
systemctl reload postfix
systemctl reload dovecot

Bu dizindeki (/etc/letsencrypt/renewal-hooks/deploy/) çalıştırılabilir betikler her başarılı yenilemeden sonra tüm sertifikalar için otomatik tetiklenir; hook'u tek tek sertifikalara bağlamaya gerek kalmaz.

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

Standalone kipi kullanıyorsanız --pre-hook "systemctl stop nginx" ve --post-hook "systemctl start nginx" ikilisi, port çakışmasını yenileme sırasında da otomatik çözer. Bu üç hook türünü doğru yerde kullanmak, gece yarısı çalışan bir yenilemenin sabaha sağlam bir sertifikayla uyanmasını garantiler.

dry-run ile Güvenli Test ve Otomatik Yenileme#

Let's Encrypt'in üretim ortamında haftalık istek limitleri vardır (aynı alan adı seti için belirli sayıda sertifika). Otomasyonunuzu denerken bu limiti tüketmek istemezsiniz. İşte tam bu noktada --dry-run devreye girer: gerçek doğrulamayı ve hook'ları çalıştırır, ama sertifikayı staging (test) ortamından alır ve diske yazmaz. Böylece akışın tamamını hiçbir kotaya dokunmadan prova edersiniz.

# Tüm yenileme yapılandırmalarını gerçekmiş gibi test et
sudo certbot renew --dry-run

Bu komut, kayıtlı her sertifika için doğrulamayı ve deploy hook'ları çalıştırır; çıktıda Congratulations, all simulated renewals succeeded görüyorsanız otomasyonunuz sağlamdır. Yeni bir alan adı ya da yeni bir DNS eklentisi denerken de dry-run kullanabilirsiniz.

# Wildcard akışını canlıya çıkmadan prova et
sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d '*.ornekfirma.com' --dry-run

Otomatik yenileme çoğu modern dağıtımda hazır gelir. Certbot paketi bir systemd zamanlayıcısı (certbot.timer) kurar ve günde iki kez yenileme kontrolü yapar; sertifikanın süresi dolmasına 30 günden az kalmadıysa hiçbir şey yapmaz. Zamanlayıcının aktif olup olmadığını doğrulayın.

# Zamanlayıcı durumunu ve bir sonraki çalışma zamanını gör
systemctl list-timers certbot.timer
sudo systemctl status certbot.timer

Sisteminizde systemd zamanlayıcısı yoksa klasik bir cron satırı aynı işi görür; rastgele bir dakika seçmek Let's Encrypt sunucularına gelen ani yükü dağıtır.

# /etc/crontab — günde iki kez, rastgele gecikmeyle yenile
17 3,15 * * * root sleep $((RANDOM \% 1800)) && certbot renew --quiet

--quiet bayrağı yalnızca hata durumunda çıktı üretir, bu da cron e-postalarınızı sessiz tutar. Yenileme mantığını üretime almadan önce mutlaka bir kez certbot renew --dry-run çalıştırıp deploy hook'ların gerçekten servisleri yeniden yüklediğini gözlemleyin.

Birden Çok Alan Adı ve İleri İpuçları#

Tek sunucuda onlarca alan adı barındırıyorsanız her biri için ayrı sertifika almak yerine mantıklı gruplar oluşturabilirsiniz. Bir sertifikaya en fazla 100 alan adı sığar, ancak pratikte bunları hizmet ya da müşteri bazında ayırmak yönetimi kolaylaştırır çünkü tek bir alan adında sorun çıkması tüm grubu etkiler.

# İlişkili alan adlarını tek sertifikada topla
sudo certbot certonly --webroot -w /var/www/kurumsal \
  -d ornekfirma.com -d www.ornekfirma.com \
  -d api.ornekfirma.com -d cdn.ornekfirma.com

Sertifikaların durumunu ve son kullanma tarihlerini tek bakışta görmek için certificates alt komutunu kullanın.

# Tüm sertifikaları, kapsadıkları alanları ve bitiş tarihlerini listele
sudo certbot certificates

Bir alan adını artık kullanmıyorsanız, gereksiz yenileme denemelerini durdurmak için sertifikayı düzgünce kaldırın.

sudo certbot delete --cert-name eski-alan.com

Bir gruptaki alan adlarını değiştirmek istediğinizde (yeni alt alan ekleyip başkasını çıkarmak gibi) aynı --cert-name ile yeniden istekte bulunup güncel -d listesini vermeniz yeterlidir; Certbot mevcut sertifikayı yeni kapsamla değiştirir. Sertifika, anahtar ve zincir dosyalarının hepsi /etc/letsencrypt/live/<alan>/ altında sembolik bağlarla durur, gerçek dosyalar ise archive/ klasöründedir. Web sunucusu yapılandırmanızda daima live/ yolunu gösterin ki yenileme sonrası bağlar otomatik güncellensin ve elle müdahale gerekmesin. Yoğun trafikli birden çok siteyi tek makinede yönetiyorsanız, kaynaklarınızı büyütmek için VDS veya sanal sunucu çözümlerimiz esnek ölçeklendirme sunar.

Sıkça Sorulan Sorular#

Standalone ve webroot kipleri arasında hangisini seçmeliyim#

Çalışan bir web siteniz varsa neredeyse her zaman webroot kipini seçmelisiniz, çünkü hiçbir servisi durdurmadan doğrulama yapar ve yenileme kesintisiz gerçekleşir. Standalone kipini yalnızca sunucuda henüz bir web sunucusu kurulu değilken ya da SSL'i Nginx/Apache dışında bir servis (mail sunucusu, özel uygulama) kullanacakken tercih edin; bu durumda 80 portunun boş olduğundan emin olmanız ve gerekirse pre/post hook ile servisi durdurup başlatmanız gerekir.

Wildcard sertifika almak için neden HTTP doğrulaması yetmiyor#

Wildcard sertifika tüm alt alan adlarını kapsadığından, Let's Encrypt tek bir alt alanın HTTP kökünü görerek bölgenin tamamına yetki veremez ve bu yüzden yalnızca DNS-01 doğrulamasını kabul eder. DNS-01'de alan adınızın bölgesine geçici bir TXT kaydı eklersiniz; bu, bölgeyi gerçekten kontrol ettiğinizi kanıtlar. Otomatik yenilemenin sorunsuz çalışması için DNS sağlayıcınızın API'siyle konuşan bir Certbot eklentisi (örneğin Cloudflare ya da Route 53 eklentisi) kullanmanız gerekir.

deploy-hook ile post-hook arasındaki fark nedir#

İkisi de yenileme sonrasında çalışır, ama tetiklenme koşulları farklıdır. --post-hook yenileme denemesi sonuçlanınca her koşulda çalışırken, --deploy-hook yalnızca sertifika gerçekten yenilendiğinde tetiklenir. Servisi yeniden yükleyecek komut için --deploy-hook tercih edilmelidir; böylece sertifika değişmediği durumlarda Nginx ya da Postfix gereksiz yere sarsılmaz ve gece çalışan yenilemeler yalnızca gerçek bir değişiklik olduğunda servislere dokunur.

dry-run gerçek sertifikamı etkiler mi#

Hayır, --dry-run tamamen güvenlidir ve mevcut canlı sertifikanıza dokunmaz. Doğrulamayı ve hook'ları Let's Encrypt'in test (staging) ortamına karşı çalıştırır, sonucu diske yazmaz ve üretim istek limitlerinizden düşmez. Bu yüzden yeni bir otomasyon, yeni bir DNS eklentisi ya da hook betiği denerken önce mutlaka dry-run ile prova yapın; her şey yolundaysa bayrağı kaldırıp gerçek komutu çalıştırın.

Sertifikam yenilenmiyorsa nereden başlamalıyım#

Önce sudo certbot renew --dry-run komutunu çalıştırıp çıktıdaki hata mesajını okuyun, çünkü sorunun kaynağını genellikle doğrudan orada görürsünüz. En sık karşılaşılan nedenler, webroot kipinde .well-known/acme-challenge/ yolunun web sunucusu tarafından engellenmesi, 80 portunun bir güvenlik duvarınca kapatılması ya da DNS eklentisinin kimlik dosyasındaki izinlerin/token'ın hatalı olmasıdır. Ayrıca systemctl list-timers certbot.timer ile zamanlayıcının aktif olduğunu doğrulayın; zamanlayıcı çalışmıyorsa yenileme hiç tetiklenmez.

Aynı sunucuda çok sayıda alan adını nasıl yönetmeliyim#

Alan adlarını hizmet ya da müşteri bazında mantıklı gruplara ayırıp her grubu tek sertifikada toplamak en sürdürülebilir yöntemdir, çünkü tek bir alanda çıkan doğrulama sorunu tüm grubu etkilediğinden grupları küçük tutmak riski azaltır. sudo certbot certificates ile tüm sertifikaların kapsamını ve bitiş tarihini tek bakışta görebilir, kullanılmayan sertifikaları certbot delete --cert-name ile temizleyebilirsiniz. Deploy hook'ları /etc/letsencrypt/renewal-hooks/deploy/ klasörüne koyduğunuzda tüm sertifikalar için ortak biçimde çalışır ve her sertifikaya ayrı ayrı hook bağlamak zorunda kalmazsınız.

Kapanış#

Certbot'un standalone, webroot ve eklenti kipleri, DNS-01 ile wildcard, deploy hook ve dry-run özellikleri; SSL yönetimini elle uğraşılan bir yükten, kurulup unutulan sağlam bir otomasyona dönüştürür. Doğru kipi seçmek, yenileme sonrası servisleri yeniden yüklemek ve üretime çıkmadan önce dry-run ile prova yapmak, gece yarısı sessizce çalışan bir yenileme akışının sabaha geçerli sertifikayla uyanmasını garanti eder. Bu adımları bir kez düzgün kurduğunuzda, sertifika süresi dolmasıyla ilgili kâbusları geride bırakırsınız.

Bu otomasyonu kurmak ya da yönetmek için zaman ayırmak istemiyorsanız, Clou.TR sizin yerinize halleder. Yönetimli SSL desteğiyle gelen hosting paketlerimiz, sunucularınızın SSL'ini uçtan uca üstlenen sunucu yönetimi hizmetimiz ve tek tıkla kurulabilen SSL çözümlerimiz ile sertifika yükünü tamamen bize devredebilir, siz işinize odaklanabilirsiniz. WordPress sitelerinizin SSL ve bakımını da bize bırakmak isterseniz WordPress bakım hizmetimiz bu rehberdeki her adımı sizin adınıza yönetir.