Ubuntu 24.04 Nginx Certbot Kurulumu ve Yapılandırma

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 üst kaynak belgeleri sizi snap kullanımına yönlendirir; aradaki fark küçüktür: snap sürümü üst kaynak sürümlerini takip ederken, arşiv paketi LTS sürümüyle birlikte sunulan ve güvenlik yamaları alan sürümü takip eder.

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 beklenmedik bir anda 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 birlikte gelir. Snap kurulumunu yapmadan önce apt paketini kaldırın.

Her iki kurulum yöntemi de sonrasında aynı şekilde davranı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ı, live/ güncel olanlara yönelik sembolik bağlantıları, renewal/ sertifika başına bir yapılandırma dosyasını, accounts/ ise ACME hesap anahtarınızı barındırır.

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

HTTP-01 sınaması bir geri çağrıdır (callback). Let's Encrypt'ten example.com alan adını kapsayan bir sertifika talep ettiğinizde; servis, genel DNS üzerinden ismi çözer, bulduğu adreste 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. Mekanizmanın tamamı bundan ibarettir. Bu durumdan kaynaklanan üç temel sonuç, başarısız sertifika oluşturma girişimlerinin çoğunun nedenidir.

• 80 numaralı port, genel internetten erişilebilir olmalıdır. Sadece kendi bilgisayarınızdan erişebiliyor olmanız yeterli değildir. Bir ufw kuralı, bulut sağlayıcı güvenlik grubu veya sadece 443 numaralı portu açan bir VPS konsol güvenlik duvarı, sertifika oluşturma işlemini ve gelecekteki tüm yenileme süreçlerini engeller.
• DNS kayıtları halihazırda bu sunucuyu işaret etmelidir. Doğrulama sunucusu kendi sorgusunu dışarıdan 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, IPv6 bağlantısı tamamen başarısız olduğunda IPv4 üzerinden tekrar dener; ancak bağlantıyı kabul eden fakat başka bir içerik sunan eski bir AAAA kaydı, işlemin doğrudan başarısız olmasına neden olur.

Yönlendirmelere izin verilir: doğrulama süreci, HTTP üzerinden HTTPS'e yapılan yönlendirmeleri takip eder ve karşı taraftaki sertifikanın eksik, süresi dolmuş veya kendinden imzalı olmasıyla ilgilenmez. Ancak süreç, 80 numaralı port dışında bir yerden başlatılamaz. Certbot'un TLS-ALPN-01 uygulaması bulunmadığından, "sadece 443 numaralı portu kullanalım" 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 dosyanın bulunmadığı bir yolu işaret ettiğinde başlatılamaz; Certbot ise nginx kapalıyken doğrulama yapamaz. Siteyi önce 80 numaralı port üzerinde 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 sunucu dışından geldiğini doğrulayın ve ardından sertifikayı alın. 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;
    }
}

ACME konumu üzerindeki ^~ ön eki işlevini yerine getirir: return 301 bloğunun doğrulama isteğini yutmasını engeller. Bu konumu 80 numaralı portta tutmak, sitenin geri kalanı yalnızca HTTPS'e geçtikten sonra da yenileme işlemlerinin çalışmaya devam etmesini sağlar.

Yukarıdaki her iki blok da dosyaları diskten 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 yönergeleri ise olduğu gibi kalır.

HTTP/2 sözdizimi nginx sürümünüze bağlıdır ve iki biçimin karıştırılması başlatma hatasına yol açar. Ubuntu 24.04, HTTP/2'yi satır içi olarak isteyen nginx 1.24 sürümü ile gelir, listen 443 ssl http2;. Debian 13 ise ayrı bir http2 on; yönergesi isteyen daha yeni bir nginx sürümü ile gelir. Önce nginx -v komutunu kontrol edin.

nginx'i her zaman live/ yoluna yönlendirin, asla archive/ yoluna değil. live/ sembolik bağlantıları her yenilemede yeniden işaretlenir; archive/ içine verilen sabit bir yol, sizi süresi dolacak bir sertifikaya hapseder.

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 boyunca geçerlidir. Certbot, geçerlilik süresinin bitimine 30 günden az kaldığında yenileme işlemini gerçekleştirir; bu da size, hatalı bir yenilemenin kesintiye yol açmadan düzeltilebileceği 30 günlük bir zaman aralığı sağlar. Let's Encrypt artık süresi dolan sertifikalar için uyarı e-postaları göndermemektedir, kimse sizi bu konuda uyarmayacaktır; dolayısıyla izleme sorumluluğu tamamen size aittir.

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

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

certbot renew, /etc/letsencrypt/renewal/ dizinindeki her yapılandırmayı gözden geçirir, 30 günlük pencerenin dışındaki sertifikaları atlar ve geri kalanını ilk çalıştırmadaki bayrakları (flags) tam olarak kullanarak yeniler. İlk çalıştırmanın önemi buradan gelir: kayıt altına alınan yapılandırma budur.

Disk üzerindeki dosyanın yenilenmesi 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 yenileme işleminden 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 yapar; --webroot ve --standalone kurulumları bunu otomatik yapmaz. Eksik bir hook, certbot certificates komutu yeni bir sertifika olduğunu neşeyle raporlarken sitenin neden süresi dolmuş bir sertifika sunduğunun tam olarak nedenidir. Başlangıçta sertifikayı okuyan diğer tüm uygulamalar da aynı hook mekanizmasına ihtiyaç duyar; örneğin Docker, TLS ve yedeklemeler ile Nextcloud VPS kurulumu gibi konteyner tabanlı bir uygulama, kendi yeniden başlatma veya yeniden yükleme adımının buraya eklenmesini gerektirir.

Yenileme işleminin gerçek ortamda test edilmesi

sudo certbot renew --dry-run

Bu komut, Let's Encrypt'in hazırlık (staging) ortamına karşı tüm doğrulama sürecini çalıştırır: aynı kod yolu, aynı güvenlik duvarı kuralları, aynı DNS yapılandırması kullanılır; hız sınırlamasına (rate-limit) takılmaz ve diske herhangi bir kalıcı veri yazılmaz. Eğer bu test bugün başarılı olursa, sunucu altyapısında bir değişiklik olmadığı sürece 60 gün sonra gerçekleşecek otomatik yenileme işlemi de başarılı olacaktır.

Kuru çalışma (dry run) testi, yeniden yükleme (reload) kancanızın tetiklenip tetiklenmediğini kanıtlamaz; bu davranış Certbot sürümlerine göre değişiklik gösterebilir. 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 ile durumu kontrol edin.

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

Could not bind to IPv4 or IPv6., --standalone hatası, nginx halihazırda 80 numaralı portu tuttuğu için oluşur. --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 noktadan 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 doğrulama belirteci (token) sunulamıyor. İstek farklı bir server bloğuna ulaştı (hangisinin default_server üzerinde yetkili 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 olmamıştır.

DNS problem: NXDOMAIN looking up A for example.com, alan adı genel ağda çözümlenemiyor. Henüz yayılmamış yeni kayıtlar veya kayıt kuruluşunuzun servis etmediği bir bölgedeki (zone) kayıt söz konusu olabilir.

too many certificates already issued for: example.com, bir hız sınırı (rate limit) hatasıdır; hata ayıklama sırasında döngüye girenlerin en sık karşılaştığı durumdur. Let's Encrypt, aynı alan adı kümesine sahip mükerrer sertifikaları haftada beş adet ile sınırlar; ayrıca kayıtlı alan adı başına haftada 50 yeni sertifikaya izin verir. Zaman geçmesi dışında bu sınırı kaldıran bir yöntem yoktur. --dry-run ile staging ortamında hata ayıklaması yapın.

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

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed, bu dosya nginx eklenti paketiyle birlikte gelir. python3-certbot-nginx içermeyen bir certonly makinesinde, 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ını barındırabilir 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ğrulama sürecini başarısızlığa uğratarak o sertifikadaki diğer tüm alan adlarını devre dışı bırakabilir. Her site için ayrı sertifika kullanıldığında, birindeki hata diğerlerini etkilemez; birden fazla servisin barındırıldığı bir sunucuda tercih edilmesi gereken yöntem budur. Birkaç siteden fazlası söz konusu olduğunda, ACME protokolünü destekleyen bir giriş kapısı kullanmak operasyonel yükü hafifletir: Docker Compose üzerinde birden fazla uygulamayı yöneten bir Traefik reverse proxy, sertifika talep ve yenileme işlemlerini otomatik olarak gerçekleştirir ve Certbot tamamen devre dışı kalır. Hangi proxy çözümünün kullanılacağı kişisel bir tercihtir; Nginx, Caddy ve Traefik karşılaştırması yaparken, proxy'nin sertifika ve uygulama bazlı yapılandırma yükünü ne ölçüde üstlenmesini istediğiniz belirleyici olacaktır.

/etc/letsencrypt dizinini, sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt kullanarak ve sembolik bağları (symlinks) koruyarak bütün halinde yedekleyin. Bu ağaç yapısı, yeniden aynı şekilde oluşturamayacağınız ACME hesap anahtarınız olan accounts/ dosyasını içerir. Yeni bir VPS'e geçiş süreci şu şekilde basitleşir: -a ile dizini rsync üzerinden aktarın, Certbot'u kurun, DNS kayıtlarını güncelleyin ve geçişi tamamlamadan önce certbot renew --dry-run komutunu çalıştırın.

Sunucuyu yeniden kurduğunuzda veya yeni bir LTS sürümüne geçtiğinizde, yenileme zamanlayıcısı otomatik olarak taşınmaz. Herhangi bir taşıma, snapshot geri yükleme veya dağıtım yükseltme işleminden sonra systemctl list-timers 'certbot*' ve ardından bir adet --dry-run komutunu çalıştırın. Bu adımı 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.

Tüm bu süreçler, kontrolün sizde olduğu, genel IP adresine sahip ve 80 numaralı portu dış dünyaya açık olan bir makineyi, yani bir VPS'i varsayar. Yukarıdaki mekanizmalar tüm bu platformlarda aynı şekilde çalışır.

Aynı sertifika adımları Nginx yerine Apache üzerinde de geçerlidir; genel bir sertifikanın seçenek olmadığı durumlarda ise Ubuntu üzerinde kendinden imzalı sertifika kullanımı dahili servisler için yeterli olacaktır.

FAQ

Sitem sadece 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 sadece 443 numaralı portu açan bir güvenlik duvarı, hem ilk sertifika alımını hem de sonraki tüm otomatik yenilemeleri engeller. 80 numaralı porttan HTTPS'e yönlendirme yapmakta bir sakınca yoktur, doğrulama bu yönlendirmeyi takip eder. 80 numaralı portu tamamen devre dışı bırakmanın tek yolu, bir sağlayıcı eklentisi ile DNS-01 yöntemini kullanmaktır.

Ubuntu 24.04 üzerinde nginx için apt mi yoksa snap mi kullanmalıyım?

apt kullanın. sudo apt install certbot python3-certbot-nginx, Ubuntu 24.04 üzerinde bu kılavuzdaki her işlem için yeterli güncellikte 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. Yalnızca en yeni sürüme hemen ihtiyaç duyuyorsanız veya yalnızca snap olarak dağıtılan bir DNS eklentisi kullanacaksanız snap yöntemini seçin. Hangi yöntemi seçerseniz seçin, sadece birini kullanın: iki farklı kurulum, aynı /etc/letsencrypt dizinine işaret eden iki ayrı yenileme zamanlayıcısı anlamına gelir ve unutulan kurulum, sertifika süresi dolduğunda sorun yaratır.

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

Sadece DNS-01 yöntemi ile mümkündür. *.example.com gibi bir wildcard sertifikası için doğrulama dosyasının çekilebileceği 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, kısıtlı yetkiye sahip bir API anahtarını sadece root kullanıcısının erişebileceği bir kimlik bilgisi dosyasına kaydedin ve kabuğun wildcard karakterini işlemesini engellemek için tırnak işareti kullanarak 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 yeniden yüklenene kadar diskteki yeni dosyayı fark etmez. certbot --nginx sizin yerinize yeniden yükleme işlemini yapar ancak --webroot ve --standalone komutları bunu yapmaz. Bu nedenle yenileme 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 çalışacaktır.

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. Herhangi bir hız sınırı (rate-limit) maliyeti yoktur ve diske yazma işlemi yapmaz; bu nedenle başarılı olması, ağ tarafındaki yapılandırmanın sağlam olduğu anlamına gelir. Ancak, dağıtım betiğinizin (deploy hook) çalışacağını kesin olarak kanıtlamaz. Bunu ayrı olarak test edin: betiği manuel olarak çalıştırın ve sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf kayıtlarını kontrol edin.