Let's Encrypt'i Otomatikleştirip Sertifikaları Bir Daha Düşünmemek

Let's Encrypt sertifikaları 90 gün geçerli, manuel renewal'ı gerçekçi olmaktan çıkaracak ve otomasyonu fiilen zorunlu kılacak kadar kısa. Devraldığım sunucuların çoğunda certbot renew zaten bir cron job'ında ya da systemd timer'ında, certbot'un installer'ı bunu varsayılan olarak kuruyor. Genelde eksik olan, tablonun gerisi: renew edilmiş bir sertifikanın onu kullanan servis tarafından gerçekten alındığından emin olmak, wildcard sertifika gerektiren domain'leri handle etmek, ve bir renewal failure'ını sertifika expire olduktan sonra değil olmadan önce öğrenmek.

İnsanların unuttuğu reload adımı

Certbot bir sertifikayı renew ettiğinde, /etc/letsencrypt/live/example.com/'a yeni dosyalar yazıyor. Bu, kendi başına, o sertifikayı kullanan Nginx'e, Postfix'e, ya da başka her neyse, yeni olanı kullanmaya başlamasını söylemiyor. Çözüm bir deploy hook, certbot'un başarılı bir renewal'dan sonra çalıştırdığı bir script:

certbot renew --deploy-hook "systemctl reload nginx"

Birden fazla servisin sertifika kullandığı bir setup için, deploy hook birden fazla şey yapabilir:

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

/etc/letsencrypt/renewal-hooks/deploy/ içindeki her şey her başarılı renewal'dan sonra otomatik olarak çalışıyor, yani bu her 90 günde hatırlanması gereken bir şey değil, tek seferlik bir setup adımı.

Wildcard sertifikalar DNS-01 gerektiriyor

Varsayılan HTTP-01 challenge'ı (certbot geçici olarak Let's Encrypt'in kontrol ettiği bir dosyayı serve ediyor), wildcard sertifikalar için çalışmıyor, bunlar domain ownership'i bir TXT kaydı oluşturarak kanıtlayan DNS-01 challenge'ını gerektiriyor. Certbot DNS plugin'i olan provider'lar için bu hâlâ tamamen otomatikleştirilebilir:

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d example.com -d '*.example.com'

Credentials dosyası sadece DNS edit'lerine scope edilmiş bir API token tutuyor, ve hiçbir manuel adım olmadan certbot TXT kaydını oluşturuyor, propagate olmasını bekliyor, ve validation tamamlandığında onu kaldırıyor. Şu anda bir wildcard'a ihtiyacınız olmasa bile bunu kurmaya değer, çünkü bir projenin buna ihtiyaç duyduğu an (örneğin her müşteri için yeni bir subdomain), alternatif her 90 günde manuel bir DNS-01 challenge oluyor, ki bu da tam olarak sonunda atlanacak türden recurring manuel bir task.

Sertifikadan önce failure'ları öğrenmek

Renewal'ın sessizce fail etmesi asıl risk, certbot her run'da retry ettiği için bir sertifika expire olmadan haftalarca fail edebilir, ve kimse bunu izlemiyorsa, bir problemin ilk işareti production'daki bir site'da bir browser uyarısı oluyor. Haftalık çalışan basit bir kontrol, bunu erkenden yakalıyor:

#!/bin/bash
# cert-expiry-check.sh
for domain in example.com mail.example.com; do
  expiry=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null \
    | openssl x509 -noout -enddate | cut -d= -f2)
  days=$(( ($(date -d "$expiry" +%s) - $(date +%s)) / 86400 ))
  if [ "$days" -lt 14 ]; then
    echo "WARNING: $domain certificate expires in $days days"
  fi
done

Her 60 günde renew etmesi gereken (certbot'un varsayılan renewal threshold'u) bir sertifikanın 14 gün kalmış olması, renewal'ın sessizce fail etmeye başladığının bir işareti, genelde HTTP-01 challenge'ını bloklayan değişmiş bir firewall kuralı, DNS-01 için expire olmuş bir DNS API token'ı, ya da certbot'un config'i güncellenmeden başka bir yere yönlendirilmiş bir domain yüzünden.

Burada "otomatik" gerçekte ne anlama geliyor

Var olan ama servisleri reload etmeyen, DNS-01 gerektiren domain'leri handle etmeyen, ve bir failure'ı görünür kılmanın hiçbir yolu olmayan bir renewal cron job'ı gerçekten otomatik değil, hâlâ implicit olarak loop'ta bir insan olan bir process, sadece bu insan bir problem olduğunu bir müşteri öğrenene kadar öğrenmiyor. Asıl hedef, bir sertifikanın renew olmasının, bir servisin yeni sertifikayı almasının, ve bu adımlardan biri fail ederse birinin bunu öğrenmesinin, 90 günlük bir cycle'da kimsenin hiçbir şeyi hatırlamasına gerek kalmadan gerçekleştiği bir setup. Bu kurulduğunda, sertifikalar bir sunucuda gerçekten kendi başına halledilen az sayıdaki şeyden biri haline geliyor.