Let's Encrypt ile HTTPS Sertifikası

İlk kez bir sunucuya SSL sertifikası kurmaya çalıştığımda tam üç saatimi harcamıştım. Sorun sertifikanın kendisi değildi; 80 numaralı portun kapalı olduğunu fark etmem üç saat sürmüştü. O günden sonra süreci kendime bir kontrol listesine dönüştürdüm ve şimdi ortalama beş dakikada bitiriyorum. Aşağıda o listeyi olduğu gibi paylaşıyorum.

Neden Let's Encrypt?

Let's Encrypt ücretsiz, otomatik ve 90 gün geçerli sertifikalar veriyor. 90 gün kulağa kısa geliyor ama zaten yenileme işini bir zamanlayıcıya bırakıyorsunuz, elle uğraşmıyorsunuz. Ticari sertifikalarla arasındaki tek anlamlı fark organizasyon doğrulaması (OV/EV) sunmaması. Blog, kişisel site, API, panel gibi işler için bu farkın hiçbir pratik karşılığı yok — tarayıcı kilidi aynı görünüyor, şifreleme aynı.

Başlamadan önce elinizde olması gerekenler

• Sunucuya kök (root) veya sudo yetkisiyle erişim. SSH ile uzaktan sunucu bağlantısı konusuna hiç girmediyseniz önce oradan başlamanızı öneririm.
• Alan adının A kaydının sunucunuzun IP'sine bakıyor olması. dig veya nslookup ile doğrulayın; DNS'te değişiklik yaptıysanız yayılmasını bekleyin.
• 80 ve 443 portlarının dışarıya açık olması. Bulut sağlayıcılarda hem sunucu içi güvenlik duvarı hem de panel tarafındaki güvenlik grubu var; ikisini ayrı ayrı kontrol edin.
• Çalışan bir web sunucusu: Nginx veya Apache.

Adım adım kurulum

1. Certbot'u kurun

   Certbot, Let's Encrypt'in ACME protokolünü sizin yerinize konuşan istemci. Debian/Ubuntu'da paket deposundan kurmak yerine snap sürümünü tercih ediyorum, çünkü daha güncel oluyor:

   sudo snap install --classic certbot ardından sudo ln -s /snap/bin/certbot /usr/bin/certbot

   Snap kullanmak istemiyorsanız apt install certbot python3-certbot-nginx da iş görür.

2. Web sunucusu yapılandırmasını hazırlayın

   Certbot'un Nginx eklentisi, server_name satırında alan adınızı görmek zorunda. Yani sertifika almadan önce şu blok ayakta olmalı:

   server { listen 80; server_name example.com www.example.com; root /var/www/example; }

   Yapılandırmayı değiştirdiyseniz sudo nginx -t ile sözdizimini test edin, sonra yeniden yükleyin. Bu adımı atlayıp doğrudan certbot çalıştıranların çoğu "alan adı bulunamadı" hatası alıyor.

3. Önce prova yapın

   Let's Encrypt'in saatlik istek limitleri var ve aynı alan adı için üst üste başarısız denemeler yaptığınızda bir süre kilitlenebiliyorsunuz. Bu yüzden gerçek sertifikayı istemeden önce staging ortamında deniyorum:

   sudo certbot --nginx -d example.com -d www.example.com --dry-run

   Çıktıda "The dry run was successful" görüyorsanız yol açık.

4. Sertifikayı alın

   sudo certbot --nginx -d example.com -d www.example.com

   Certbot e-posta adresi soracak (yenileme uyarıları buraya gelir), şartları kabul etmenizi isteyecek ve HTTP'den HTTPS'e yönlendirme kurmak isteyip istemediğinizi soracak. Yönlendirmeyi kurun. Sertifika dosyaları /etc/letsencrypt/live/example.com/ altına düşer. Bu dizindeki dosyalar sembolik bağdır; kopyalayıp taşımayın, yapılandırmada doğrudan bu yolu gösterin.

5. Otomatik yenilemeyi doğrulayın

   Certbot kurulumda bir systemd timer veya cron girdisi bırakır. Kontrol için:

   systemctl list-timers | grep certbot ve sudo certbot renew --dry-run

   Yenileme sonrası web sunucusunun yeniden yüklenmesi gerekir. Nginx eklentisiyle kurduysanız bunu certbot kendisi yapar; elle yapılandırdıysanız --deploy-hook "systemctl reload nginx" ekleyin.

6. Sonucu test edin

   Tarayıcıda siteyi açıp kilit simgesine bakmak yeterli değil. Sertifika zincirinin doğru sunulduğunu, eski TLS sürümlerinin kapalı olduğunu ve HTTP'nin gerçekten 301 ile yönlendiğini kontrol edin. curl -I http://example.com komutu yönlendirmeyi bir satırda gösterir.

Webroot ve DNS doğrulaması: ne zaman hangisi?

Docker ile konteyner çalıştırıyorsanız veya birden fazla servisi tek IP üzerinden yayınlıyorsanız sertifikayı tek bir ters vekil (reverse proxy) katmanında toplamak en temizi. Her konteynere ayrı sertifika dağıtmaya çalışmak gereksiz karmaşa üretiyor.

Sık yapılan hatalar

• 80 portunu kapatmak. "Artık HTTPS var, HTTP'ye ne gerek var" diye düşünüp 80'i kapatanların yenilemeleri sessizce başarısız oluyor. HTTP-01 doğrulaması bu portu kullanır.
• Cloudflare gibi bir vekilin arkasında doğrulama yapmak.
  © 2026 Ağ ve Bulut