Rehberler

Yazan Matt Connor 2026-10-10

Ubuntu 24.04 Nginx Certbot Kurulumu ve Yapılandırma

Q: Ubuntu 24.04 üzerinde nginx için Certbot'u apt ile mi yoksa snap ile mi kurmalıyım?

apt kullanın. sudo apt install certbot python3-certbot-nginx, Ubuntu 24.04 üzerinde bu kılavuzdaki tüm işlemler için yeterli olan Certbot 2.9.0 sürümünü sağlar, unattended-upgrades aracılığıyla güvenlik yamalarını alır ve snapd gerektirmez. snap paketini yalnızca en yeni sürüme hemen ihtiyaç duyuyorsanız veya yalnızca snap olarak dağıtılan bir DNS eklentisi kullanacaksanız tercih edin. Hangi yöntemi seçerseniz seçin, yalnızca birini kullanın: iki kurulum, aynı /etc/letsencrypt dizinini hedefleyen iki yenileme zamanlayıcısı anlamına gelir ve unutulan kurulum, sertifikanın süresi dolduğunda sorun yaratır.

Q: Certbot, nginx için wildcard sertifikası düzenleyebilir mi?

Yalnızca DNS-01 üzerinden düzenleyebilir. *.example.com gibi bir wildcard sertifikası için doğrulama dosyası çekilebilecek tek bir ana makine adı yoktur; bu nedenle --nginx, --webroot ve --standalone yöntemleri kullanılamaz. DNS sağlayıcınız için gerekli eklentiyi kurun, kapsamlı bir API anahtarını yalnızca root kullanıcısının erişebildiği bir kimlik bilgisi dosyasına yerleştirin ve kabuğun joker karakteri işlemesini engellemek için tırnak içinde certbot certonly --dns-cloudflare -d example.com -d '*.example.com' komutunu çalıştırın.

Ubuntu 24.04 sisteminizde sudo apt install certbot python3-certbot-nginx komutu ile Let's Encrypt kurulumunu yapın. Port 80 zaman aşımı hatalarını ve apt ile snap farklarını öğrenin.

Certbot Kurulumu: apt veya snap

Ubuntu 24.04 üzerinde sudo apt install certbot python3-certbot-nginx, gerçek ve genel olarak güvenilen Let's Encrypt sertifikaları düzenleyen çalışan bir Certbot sağlar. Certbot'un yukarı akış (upstream) belgeleri sizi snap kullanımına yönlendirir; aradaki fark küçüktür: snap yukarı akış sürümlerini takip ederken, arşiv paketi LTS ile birlikte gelen sürümü takip eder ve güvenlik yamalarını alır.

Birini seçin. İki Certbot kopyası, aynı /etc/letsencrypt ağacını hedefleyen iki yenileme zamanlayıcısı anlamına gelir ve unuttuğunuz zamanlayıcı sizi yarı yolda bırakır.

apt yolu:

sudo apt update
sudo apt install certbot python3-certbot-nginx

Bu komut /usr/bin/certbot paketini, nginx eklentisini, bir certbot.service + certbot.timer çiftini ve systemd altında hiçbir işlem yapmayan bir /etc/cron.d/certbot girdisini kurar.

snap yolu:

sudo apt remove certbot python3-certbot-nginx
sudo snap install core && sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Snap kendi zamanlayıcısı olan snap.certbot.renew.timer ile gelir. Snap'i kurmadan önce apt paketini kaldırın.

Her iki kurulum da sonrasında aynı şekilde davranır; yalnızca yenileme zamanlamaları farklıdır (aşağıdaki Yenileme bölümünde ele alınmıştır). Certbot 2.x varsayılan olarak ECDSA (P-256) anahtarlarını kullanır; --key-type rsa bayrağını yalnızca ECDSA desteklemeyen bir istemci için kullanın. Tüm durum bilgileri /etc/letsencrypt altında tutulur: archive/ gerçek anahtar ve sertifika dosyalarını barındırır, live/ güncel olanlara sembolik bağ (symlink) oluşturur, renewal/ sertifika başına bir yapılandırma dosyası içerir, accounts/ ise ACME hesap anahtarınızı tutar.

HTTP-01 sürecinin işleyişi ve 80 numaralı portun zorunluluğu

HTTP-01 sınaması bir geri çağırma (callback) işlemidir. Let's Encrypt'ten example.com için bir sertifika talep ettiğinizde; servis, genel DNS üzerinden alan adını çözer, bulduğu adresteki 80 numaralı port ile bağlantı kurar ve http://example.com/.well-known/acme-challenge/<token> dosyasını ister. Sunucunuz, Certbot'un diske yazdığı token içeriğini aynen yanıt olarak döner. Tüm mekanizma bundan ibarettir. Bu süreçten üç temel sonuç çıkar ve sertifika alımındaki başarısızlıkların çoğu bunlardan kaynaklanır.

80 numaralı port, sadece dizüstü bilgisayarınızdan değil, genel internetten erişilebilir olmalıdır. Bir ufw kuralı, bulut sağlayıcı güvenlik grubu veya sadece 443 numaralı portu açan bir VPS konsol güvenlik duvarı, sertifika alımını ve gelecekteki tüm yenileme işlemlerini engeller.
DNS kayıtları halihazırda bu sunucuyu işaret etmelidir. Doğrulama sunucusu kendi dış sorgusunu yapar; sizin /etc/hosts girdileriniz ve tarayıcı önbelleğinizin bu süreçte bir etkisi yoktur.
Eğer bir AAAA kaydı yayınlıyorsanız, öncelik IPv6'ya verilir. Let's Encrypt, yalnızca IPv6 bağlantısı zaman aşımına uğradığında IPv4 üzerinden tekrar dener. Reddedilen bir IPv6 bağlantısı tekrar denenmez; bağlantıyı kabul eden ancak başka bir içerik sunan eski bir AAAA kaydı ise doğrudan başarısızlığa yol açar.

Yönlendirmelere izin verilir: Doğrulama süreci, HTTP yönlendirmesini takip ederek HTTPS'e geçer ve karşı taraftaki sertifikanın eksik, süresi geçmiş veya kendinden imzalı olmasıyla ilgilenmez. Yapmayacağı tek şey, 80 numaralı port dışında bir yerden başlamaktır. Certbot'un TLS-ALPN-01 uygulaması yoktur, bu nedenle "sadece 443'ü kullan" bir çözüm yolu değildir.

Kimlik doğrulayıcı seçimi: --nginx, --webroot, --standalone

--nginx, nginx halihazırda çalışıyorsa ve alan adına hizmet veriyorsa varsayılan olarak en uygun seçenektir. Certbot yapılandırmanızı ayrıştırır, geçici bir doğrulama konumu ekler, nginx'i yeniden yükler, doğrulamayı yapar ve ardından TLS yönergelerini sunucu bloğunuza yazar. Kesinti yaşanmaz.

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

Yeni bir sunucu için betik ile kullanım:

sudo certbot --nginx \
  -d example.com -d www.example.com \
  --agree-tos -m ops@example.com --no-eff-email \
  --redirect --non-interactive

--webroot, Certbot'un nginx yapılandırmanıza müdahale etmesini istemediğiniz durumlarda uygundur; örneğin şablonlardan oluşturduğunuz, git üzerinde tuttuğunuz veya Ansible ile dağıttığınız yapılandırmalar için. Certbot yalnızca doğrulama dosyasını, halihazırda hizmet verdiğiniz bir dizine yazar.

sudo certbot certonly --webroot -w /var/www/example.com \
  -d example.com -d www.example.com \
  --deploy-hook "systemctl reload nginx"

--standalone, 80 numaralı portta hiçbir servis dinleme yapmadığında uygundur: bir posta sunucusu, yalnızca 443 portundan konuşan bir API veya nginx henüz mevcut değilken çalışan bir ilk kurulum betiği gibi. Certbot, birkaç saniyeliğine 80 numaralı portu kendisi bağlar. Eğer nginx çalışıyorsa bu işlem başarısız olur; bu nedenle çalıştırma sırasında nginx'i durdurun:

sudo certbot certonly --standalone -d mail.example.com \
  --pre-hook "systemctl stop nginx" \
  --post-hook "systemctl start nginx"

Bu kancalar (hooks), sertifikanın yenileme yapılandırmasına kaydedilir; böylece yenileme sırasında aynı durdurma/başlatma işlemleri otomatik olarak gerçekleştirilir.

Sertifika mevcut olmadan önce ve sonra çalışan bir sunucu bloğu

Tavuk-yumurta sorunu: nginx, ssl_certificate dosyasının bulunmadığı bir konuma işaret etmesi durumunda başlatılamaz, Certbot ise nginx kapalıyken doğrulama yapamaz. Siteyi önce 80 numaralı port üzerinden ayağa kaldırın.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo nginx -t && sudo systemctl reload nginx komutunu çalıştırın, curl -I http://example.com/ yanıtının sunucunun dışından geldiğini doğrulayın ve ardından sertifikayı oluşturun. Sonrasında:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Daha uzun olan ACME öneki, location / ifadesini zaten geçersiz kılar, bu nedenle return 301 hiçbir zaman bir doğrulama isteği görmez. ^~ değiştiricisi başka bir yerde işe yarar: bu önek eşleştiğinde nginx regex konumlarını tamamen atlar, böylece daha sonra eklenen location ~ /\. { deny all; } gibi bir kural doğrulamayı engelleyemez. Bu konumu 80 numaralı portta tutmak, sitenin geri kalanı yalnızca HTTPS'e geçtikten sonra bile yenileme işlemlerinin çalışmaya devam etmesini sağlar.

Yukarıdaki her iki blok da diskten dosya sunar; eğer nginx bunun yerine bir uygulamanın önünde yer alıyorsa, location / bir proxy_pass bloğuna dönüşür ve ters vekil sunucu bloğu, satır satır bölümü uygulamanın ihtiyaç duyduğu başlıkları kapsar; ACME konumu ve TLS direktifleri ise olduğu gibi kalır.

HTTP/2 sözdizimi nginx sürümünüze bağlıdır. Ubuntu 24.04, nginx 1.24 ile gelir; bu sürüm ayarın satır içi listen 443 ssl http2; olarak yapılmasını gerektirir ve ayrı bir http2 on; direktifi verilirse başlatılamaz. Debian 13 ise nginx 1.26 ile gelir; bu sürüm http2 on; kullanımını gerektirir ve satır içi formun artık kullanılmadığına dair uyarı verir. Öncelikle nginx -v komutunu kontrol edin.

nginx'i live/ konumuna yönlendirin, asla archive/ konumuna değil. live/ sembolik bağları her yenilemede yeniden işaretlenir; archive/ içine doğrudan bir yol vermek, sizi süresi dolacak bir sertifikaya sabitler.

Wildcard sertifikalar DNS-01 demektir, DNS-01 ise eklenti demektir

Wildcard sertifikalar (*.example.com) HTTP-01 üzerinden doğrulanamaz; dosya çekilebilecek tek bir ana makine adı yoktur. Tek seçenek DNS-01 yöntemidir: kontrolü, bir _acme-challenge.example.com TXT kaydı yayınlayarak kanıtlarsınız. Certbot'un bu işlemi otomatik yapabilmesi için DNS sağlayıcınızın API kimlik bilgilerine ihtiyacı vardır; sağlayıcı eklentileri bu amaçla var olmuştur. Wildcard sertifika rehberinin tamamı, TXT kaydı mekaniğini ve manuel moddaki yenileme tuzağını açıklar; aşağıda kısa Cloudflare sürümü yer almaktadır.

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

apt yolunda bunun yerine sudo apt install python3-certbot-dns-cloudflare kullanılır. Kimlik bilgileri, yalnızca root kullanıcısının erişebileceği bir dosyaya yazılmalıdır:

# /root/.secrets/cloudflare.ini
# then: sudo chmod 600 /root/.secrets/cloudflare.ini
dns_cloudflare_api_token = your_scoped_token_here

Token'ı yalnızca ilgili bölge (zone) üzerinde DNS düzenleme yetkisiyle sınırlandırın. Bu, DNS sisteminizin anahtarıdır; ona göre davranın.

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

Shell'in wildcard karakterini genişletmemesi için ifadeyi tırnak içine alın. DNS-01, HTTP-01'in çözemediği bir sorunu daha çözer: 80 numaralı portu dış dünyaya kapalı olan ana makineler, dahili servisler, yalnızca VPS üzerinde kendi kendine barındırılan bir WireGuard VPN üzerinden erişilebilen sistemler veya özel bir arayüzdeki yönetim panelleri için sertifika alınmasını sağlar.

Yenileme: 90 gün, zamanlayıcı ve deploy hook

Let's Encrypt sertifikaları 90 gün geçerlidir. apt paketi (Certbot 2.9.0), geçerlilik süresinin bitimine 30 günden az kaldığında yenileme yapar. snap, güncel Certbot sürümünü takip eder; 4.1 sürümünden itibaren ACME Renewal Info (ARI) aracılığıyla Let's Encrypt'ten önerilen bir yenileme zamanı talep eder ve daha erken yenileme yapabilir. Let's Encrypt sertifikası için bu, genellikle ömrünün üçte ikisinin dolduğu zamana denk gelir. Her iki durumda da, başarısız bir yenilemenin kesintiye yol açmadan düzeltilebileceği yaklaşık 30 günlük bir pencereniz olur. Gelecek yıldan itibaren yenilemelerin daha sık gerçekleşmesini bekleyin: Let's Encrypt varsayılan profili 10 Şubat 2027 tarihinde 64 günlük, 16 Şubat 2028 tarihinde ise 45 günlük sertifikalara geçecektir. Let's Encrypt artık son kullanma tarihi uyarı e-postaları göndermemektedir; kimse sizi bu konuda uyarmayacaktır, bu nedenle izleme sorumluluğu size aittir.

Kurulumunuzla birlikte gelen zamanlayıcıyı kontrol edin:

systemctl list-timers 'certbot*' 'snap.certbot*'
sudo certbot certificates

certbot renew, /etc/letsencrypt/renewal/ içindeki tüm yapılandırmaları tarar, henüz süresi dolmamış olanları atlar ve geri kalanını o yapılandırmada kayıtlı seçenekleri kullanarak yeniler. Bunlar, certbot reconfigure ile daha sonra değiştirmediyseniz, ilk çalıştırmadaki bayraklardır. İlk çalıştırmanın önemli olmasının nedeni budur: kaydedilen ayarlar o çalıştırmadan alınır.

Disk üzerindeki dosyayı yenilemek tek başına hiçbir şeyi değiştirmez; nginx, bir komutla yeniden yüklenene kadar eski sertifikayı bellekten sunmaya devam eder. Bir kez deploy hook tanımlayın:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
set -e
nginx -t && systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

renewal-hooks/deploy/ dizinindeki çalıştırılabilir her dosya, başarılı bir yenilemeden sonra çalışır. --deploy-hook bayrağı, tek bir sertifika için aynı işi yapar ve renew_hook = ... değerini ilgili yenileme yapılandırmasına kaydeder. certbot --nginx sizin yerinize yeniden yükleme işlemini gerçekleştirir; --webroot ve --standalone kurulumları bunu yapmaz. Eksik bir hook, certbot certificates başarıyla yeni bir sertifika raporlarken sitenin neden süresi dolmuş bir sertifika sunduğunun tam olarak nedenidir. Başlangıçta sertifikayı okuyan diğer tüm uygulamalar aynı hook'a ihtiyaç duyar; Docker, TLS ve yedeklemeli Nextcloud VPS kurulumu gibi konteynerize edilmiş bir uygulamanın da burada kendi yeniden başlatma veya yeniden yükleme adımının tanımlanması gerekir.

Yenileme işleminin gerçek ortamda test edilmesi

sudo certbot renew --dry-run

Bu komut, Let's Encrypt'in staging ortamına karşı tam doğrulama sürecini çalıştırır: aynı kod yolu, aynı güvenlik duvarı, aynı DNS kullanılır; üretim ortamındaki hız sınırlarına (rate limit) takılmazsınız (staging ortamının kendine ait, çok daha esnek sınırları vardır) ve diske herhangi bir sertifika kaydedilmez. Eğer test bugün başarılı olursa, sunucu altyapısında bir değişiklik olmadığı sürece 60 gün sonraki otomatik yenileme işlemi de başarılı olacaktır.

Kuru çalışma (dry run), reload kancanızın (hook) tetiklenip tetiklenmediğini kanıtlamaz; bu davranış Certbot sürümlerine göre değişiklik gösterir. Bu kısmı manuel olarak test edin: kanca betiğini doğrudan çalıştırın, systemctl reload nginx komutunun başarıyla sonuçlandığını doğrulayın ve sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf çıktısını kontrol edin.

Karşılaşacağınız gerçek hatalar

Could not bind to IPv4 or IPv6., nginx hâlihazırda 80 numaralı portu tutarken --standalone hatası. --nginx veya --webroot kullanın ya da çalıştırma sırasında nginx'i durdurun. Portu tutan süreci sudo ss -lntp | grep ':80' ile doğrulayın.

Timeout during connect (likely firewall problem), Let's Encrypt 80 numaralı porta erişemedi. Dışarıdan içeriye doğru kontrol edin: sudo ufw status (sudo ufw allow 'Nginx Full' ile açın), ardından VPS sağlayıcısının kendi güvenlik duvarı ve son olarak DNS. Sunucunuzun dışındaki bir yerden test edin: curl -sSv http://example.com/.well-known/acme-challenge/test. Güncelliğini yitirmiş bir AAAA kaydı da aynı mesajı üretir.

unauthorized :: Invalid response from http://example.com/.well-known/acme-challenge/xyz: 404, 80 numaralı porta erişilebiliyor ancak token sunulamıyor. İstek farklı bir server bloğuna düştü (hangisinin default_server üzerinde hak sahibi olduğunu kontrol edin) veya -w için belirtilen dizin, nginx'in servis ettiği dizin değil. /var/www/example.com/.well-known/acme-challenge/test konumuna bir dosya bırakın ve dışarıdan çekmeyi deneyin; eğer 404 hatası alıyorsanız, sorun hiçbir zaman sertifika ile ilgili değildi.

DNS problem: NXDOMAIN looking up A for example.com, isim herkese açık olarak çözümlenemiyor. Henüz yayılmamış yeni kayıtlar veya kayıt kuruluşunuzun servis etmediği bir bölgedeki (zone) kayıt buna neden olur.

too many certificates (5) already issued ..., bir hız sınırı (rate limit) hatasıdır ve hata ayıklama sırasında döngüye girenlerin karşılaştığı durumdur. Mesaj sınırı belirtir ve bir retry after süresi ile biter. Let's Encrypt, aynı isim kümesine sahip mükerrer sertifikaları haftada beş adet ile sınırlar ve bu sınır için bir geçersiz kılma (override) seçeneği sunmaz; bu nedenle sadece zaman geçmesi engeli kaldırır. Bunun dışında, kayıtlı alan adı başına haftada 50 yeni sertifikaya izin verilir; bu sınır bir geçersiz kılma talebiyle artırılabilir. Mevcut bir sertifika ile tamamen aynı isim kümesi için yapılan talep yenileme olarak sayılır ve bu sınırdan muaftır; ARI üzerinden koordine edilen yenilemeler ise tüm sınırlardan muaftır. --dry-run ile staging ortamında hata ayıklayın.

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory, nginx hiç düzenlenmemiş veya certbot delete ile kaldırılmış bir sertifika için yapılandırılmış. TLS server bloğunu yorum satırı haline getirin, nginx'i başlatın, sertifikayı düzenleyin ve bloğu geri yükleyin.

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed, bu dosya nginx eklenti paketiyle birlikte gelir. python3-certbot-nginx bulunmayan bir certonly sisteminde, ya eklentiyi ekleyin ya da include satırını kendi ssl_protocols ve ssl_ciphers ayarlarınızla değiştirin.

Ölçeklenebilir yönetim

Tek bir sertifika 100 adede kadar alan adı taşıyabilir ve tek bir certbot --nginx -d a.example.com -d b.example.com ... kullanmak cazip görünebilir; ancak güncelliğini yitirmiş tek bir DNS kaydı doğrulamanın başarısız olmasına ve o sertifikadaki diğer tüm alan adlarının devre dışı kalmasına neden olur. Site başına ayrı sertifikalar birbirinden bağımsız olarak başarısız olur; birkaçtan fazla site barındıran bir sunucuda istenen durum budur. Birkaç siteden fazlası için ACME destekli bir giriş kapısı kullanmak verimlidir: Docker Compose altında birden fazla uygulama çalıştıran bir Traefik reverse proxy, sertifikaları kendi kendine talep eder ve yeniler; böylece Certbot tamamen devre dışı kalır. Hangi proxy'nin bu giriş kapısında kullanılacağı kişisel bir tercihtir ve Nginx, Caddy ve Traefik karşılaştırması, büyük ölçüde proxy'nin sertifika ve uygulama bazlı yapılandırma işlerinin ne kadarını üstlenmesini istediğinize bağlıdır.

/etc/letsencrypt dizinini, sembolik bağlantılar korunacak şekilde, bütünüyle sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt ile yedekleyin. Bu ağaç, yeniden aynı şekilde oluşturamayacağınız ACME hesap anahtarınızı ve accounts/ içeriğini barındırır. Yeni bir VPS'e geçiş şu adımlara indirgenir: ağacı -a ile rsync edin, Certbot'u kurun, DNS yönlendirmesini güncelleyin ve geçişi tamamlamadan önce certbot renew --dry-run komutunu çalıştırın.

Sunucuyu yeniden oluşturduğunuzda veya yeni bir LTS sürümüne geçtiğinizde yenileme zamanlayıcısı sizinle birlikte taşınmaz. Herhangi bir taşıma, snapshot geri yükleme veya dağıtım yükseltme işleminden sonra systemctl list-timers 'certbot*' komutunu ve bir adet --dry-run işlemini çalıştırın. Bunu atlamak, 89 gün sonra, gece saat 03:00'te, herkesin otomatik olarak yenilendiğini varsaydığı bir sertifikanın süresinin dolması ve sitenin erişilemez hale gelmesiyle sonuçlanır.

Yukarıdaki HTTP-01 rotaları, kontrolünüz altında olan, genel IP adresine sahip ve 80 numaralı portu dünyaya açık bir makineyi, yani bir VPS'i varsayar; DNS-01 ise bunların hiçbirine ihtiyaç duymaz. Mekanizmalar her iki yöntem için de aynıdır.

Aynı sertifika adımları Nginx yerine Apache üzerinde de geçerlidir ve genel bir sertifikanın seçenek olmadığı durumlarda, Ubuntu üzerinde kendinden imzalı bir sertifika iç servisleri kapsar.

FAQ

Sitem yalnızca HTTPS üzerinden hizmet veriyorsa 80 numaralı portu açmam gerekir mi?

Evet, HTTP-01 doğrulaması için gereklidir. Let's Encrypt, doğrulama isteğini her zaman 80 numaralı port üzerinden başlatır ve Certbot'un TLS-ALPN-01 uygulaması bulunmaz. Bu nedenle, yalnızca 443 numaralı portu açan bir güvenlik duvarı, hem ilk sertifika alımını hem de sonraki tüm otomatik yenileme işlemlerini engeller. 80 numaralı porttan HTTPS'e yönlendirme yapmakta bir sakınca yoktur; doğrulama süreci bu yönlendirmeyi takip edebilir. 80 numaralı portu tamamen devre dışı bırakmanın tek yolu, bir sağlayıcı eklentisi veya Certbot'un --manual --preferred-challenges dns özelliği ile DNS-01 yöntemini kullanmaktır. Bu yöntemde TXT kaydını kendiniz eklersiniz; ancak bir --manual-auth-hook betiği sağlamadığınız sürece yenileme işlemi otomatik olmaktan çıkar.

Ubuntu 24.04 üzerinde nginx için Certbot'u apt ile mi yoksa snap ile mi kurmalıyım?

apt kullanın. sudo apt install certbot python3-certbot-nginx, Ubuntu 24.04 üzerinde bu kılavuzdaki tüm işlemler için yeterli olan Certbot 2.9.0 sürümünü sağlar, unattended-upgrades aracılığıyla güvenlik yamalarını alır ve snapd gerektirmez. snap paketini yalnızca en yeni sürüme hemen ihtiyaç duyuyorsanız veya yalnızca snap olarak dağıtılan bir DNS eklentisi kullanacaksanız tercih edin. Hangi yöntemi seçerseniz seçin, yalnızca birini kullanın: iki kurulum, aynı /etc/letsencrypt dizinini hedefleyen iki yenileme zamanlayıcısı anlamına gelir ve unutulan kurulum, sertifikanın süresi dolduğunda sorun yaratır.

Certbot, nginx için wildcard sertifikası düzenleyebilir mi?

Yalnızca DNS-01 üzerinden düzenleyebilir. *.example.com gibi bir wildcard sertifikası için doğrulama dosyası çekilebilecek tek bir ana makine adı yoktur; bu nedenle --nginx, --webroot ve --standalone yöntemleri kullanılamaz. DNS sağlayıcınız için gerekli eklentiyi kurun, kapsamlı bir API anahtarını yalnızca root kullanıcısının erişebildiği bir kimlik bilgisi dosyasına yerleştirin ve kabuğun joker karakteri işlemesini engellemek için tırnak içinde certbot certonly --dns-cloudflare -d example.com -d '*.example.com' komutunu çalıştırın.

Başarılı bir yenileme işleminden sonra nginx neden hala eski sertifikayı sunuyor?

nginx, sertifikayı bellekte tutar ve diskteki yeni dosyayı yeniden yükleme (reload) yapılana kadar fark etmez. certbot --nginx sizin yerinize yeniden yükleme yapar, ancak --webroot ve --standalone komutları bunu yapmaz. Bu nedenle, yenileme işlemi başarılı olsa bile tarayıcı hala süresi dolmakta olan sertifikayı görebilir. /etc/letsencrypt/renewal-hooks/deploy/ dizinine, nginx -t && systemctl reload nginx komutunu çalıştıran yürütülebilir bir betik yerleştirin; bu betik her başarılı yenilemeden sonra tetiklenecektir.

`certbot renew --dry-run` komutu yenilemenin çalışacağını kanıtlar mı?

Büyük ölçüde evet. Bu komut, gerçek doğrulama sürecini staging ortamında, aynı güvenlik duvarı, aynı DNS ve aynı kod yolu üzerinden çalıştırır. Üretim ortamındaki hız sınırlarını (rate limits) etkilemez ve diske herhangi bir sertifika kaydetmez; bu nedenle başarılı olması, ağ tarafındaki yapılandırmanın sağlam olduğunu gösterir. Ancak, deploy kancanızın (deploy hook) tetikleneceğini kesin olarak kanıtlamaz. Bunu ayrı olarak test edin: kanca betiğini manuel olarak çalıştırın ve sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf kayıtlarını kontrol edin.

#certbot #lets-encrypt #nginx #tls #ubuntu #systemd

Certbot Kurulumu: apt veya snap

HTTP-01 sürecinin işleyişi ve 80 numaralı portun zorunluluğu

Kimlik doğrulayıcı seçimi: --nginx, --webroot, --standalone

Sertifika mevcut olmadan önce ve sonra çalışan bir sunucu bloğu

Wildcard sertifikalar DNS-01 demektir, DNS-01 ise eklenti demektir

Yenileme: 90 gün, zamanlayıcı ve deploy hook

Yenileme işleminin gerçek ortamda test edilmesi

Karşılaşacağınız gerçek hatalar

Ölçeklenebilir yönetim

FAQ

Sitem yalnızca HTTPS üzerinden hizmet veriyorsa 80 numaralı portu açmam gerekir mi?

Ubuntu 24.04 üzerinde nginx için Certbot'u apt ile mi yoksa snap ile mi kurmalıyım?

Certbot, nginx için wildcard sertifikası düzenleyebilir mi?

Başarılı bir yenileme işleminden sonra nginx neden hala eski sertifikayı sunuyor?

certbot renew --dry-run komutu yenilemenin çalışacağını kanıtlar mı?

`certbot renew --dry-run` komutu yenilemenin çalışacağını kanıtlar mı?