ACME ile Otomatik TLS Sertifika Yönetimi: Doğrulama Yöntemi, Kota ve Durum Saklama

Otomatik sertifika yönetimi "kur, unut" diye satılır ve çoğu kurulumda ilk üç ay gerçekten öyle gider. Sorun, sistemi bir kez daha kurmak zorunda kaldığınızda, geçici test ortamları çoğaldığında ya da bir alan adının DNS'i başka bir ekibin elinde olduğunda başlar. Bu yazı ACME protokolüyle çalışan bir sertifika akışını (Let's Encrypt en yaygın örnek) baştan doğru kurmak için hangi kararların önemli olduğunu, kotanın sizi nerede yakalayacağını ve başınıza gelmesi neredeyse kesin olan tuzakları anlatır.

Üç doğrulama yöntemi, tek gerçek karar

ACME, sertifikayı vermeden önce alan adının sizde olduğunu üç yoldan biriyle doğrular:

• HTTP-01: CA, alan adının 80 portunda /.well-known/acme-challenge/ altındaki bir dosyayı ister. Kurulumu en kolay olanıdır; tek şartı alan adının doğrudan o sunucuya çözülmesi ve 80 portunun dünyaya açık olmasıdır.
• DNS-01: _acme-challenge.<alanadı> adında bir TXT kaydı yazarsınız. Sunucunun internete açık olması gerekmez, joker sertifika (*.example.com) yalnızca bu yolla alınabilir. Bedeli, ACME istemcisinin DNS sağlayıcınıza yazma yetkisi olan bir API anahtarı taşımasıdır.
• TLS-ALPN-01: Doğrulama 443 portunda, özel bir ALPN protokolüyle yapılır. 80 portunu hiç açamadığınız ortamlar için vardır; bunun dışında HTTP-01 ile aynı kısıtları taşır.

Tarafımız net: tek bir herkese açık sunucunuz varsa HTTP-01 yeterlidir ve daha az yetki gerektirir. Birden fazla sunucu, iç ağdaki servisler, geçici ortamlar ya da joker ihtiyacı ortaya çıktığı anda DNS-01'e geçin. Çoğu ekip HTTP-01 ile başlayıp her istisnayı elle yamayarak yıllarca sürünür; ikinci istisnada geçmek daha ucuzdur. DNS API anahtarının yetkisini ise mümkünse tek bir bölgeyle ya da yalnızca TXT kayıtlarıyla sınırlayın. Birçok sağlayıcı bunu destekler; desteklemiyorsa doğrulama için ayrı, delege edilmiş bir alt bölge açmak (CNAME ile _acme-challenge kaydını o bölgeye yönlendirmek) hem güvenli hem yaygın bir çözümdür.

Kota sizi ilk ne zaman vurur

Let's Encrypt'in limitleri günlük kullanımda hissedilmez, çünkü kayıtlı alan adı başına haftada onlarca sertifikaya izin verir. Sizi vuran senaryo şudur: her CI koşusu ya da her deneme ortamı kendine yeni bir alt alan adı üretir ve her biri için ayrı sertifika ister. Limit alt alan adına değil kayıtlı alan adının tamamına (example.com) aittir; test ortamlarınız üretimle aynı alan adını paylaşıyorsa, tükenen kotayı üretim de öder ve o hafta gerçek bir yenileme de reddedilir.

Üç önlem birlikte çalışır:

1. Sertifika akışını test ederken staging ortamını kullanın. Adresi https://acme-staging-v02.api.letsencrypt.org/directory; limitleri çok daha gevşektir, verdiği sertifikaya tarayıcılar güvenmez ama akışın doğruluğunu ölçmeye yeter. certbot için --dry-run bayrağı tam olarak bunu yapar.
2. Geçici ortamlar için ayrı bir üst alan adı altında tek bir joker sertifika alın ve tüm ortamlar onu paylaşsın. Yüz ortam, sıfır yeni sertifika.
3. Aynı ad kümesi için tekrar tekrar sertifika istemeyin. "Yinelenen sertifika" limiti ayrıdır ve çok daha düşüktür; her yeniden kurulumda sıfırdan başlayan bir istemci bu limite iki günde çarpar.

Saklanması gereken şey sertifika değil, durumdur

En sık yapılan hata, sertifikayı yedekleyip ACME hesabını ve istemci durumunu yedeklememektir. Sertifika üç ayda zaten yenilenir; kaybolursa yeniden alınır. Ama hesap anahtarı ve "bu sertifika daha önce verildi" bilgisi kaybolursa istemci her şeyi yeni sayar, kota bir anda dolar ve yenileme muafiyetlerinden yararlanamazsınız.

Pratikte bu şu anlama gelir: certbot için /etc/letsencrypt dizininin tamamı, Traefik gibi araçlarda tek acme.json dosyası, Kubernetes'te cert-manager'ın hesap anahtarını ve verilmiş sertifikaları tuttuğu Secret nesneleri. Küme yedeğinizden Secret'ları dışlıyorsanız, felaket sonrası geri yüklemede önce kota hatasıyla tanışırsınız. Aynı sebeple ACME istemcisi durumu paylaşımlı bir diskte tutulacaksa tek bir örneğin yazmasını garanti edin; iki örnek aynı hesabı paylaşıp ayrı ayrı sipariş açarsa hem limiti hem de birbirinin sertifikasını ezer.

Çalışır örnekler

Tek sunucuda, web sunucusunun kök dizini üzerinden HTTP-01:

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

certbot renew komutu yalnızca süresi yaklaşan sertifikaları yeniler ve dağıtımla gelen zamanlayıcı bunu günde iki kez dener. Kendi cron'unuzu yazıyorsanız aynı sıklığı koruyun; "ayda bir" çalışan bir yenileme, tek bir DNS arızasında sertifikayı düşürür.

Kubernetes'te cert-manager ile DNS-01, Cloudflare örneği:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-dns
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-dns-account-key
    solvers:
      - dns01:
          cloudflare:
            apiTokenSecretRef:
              name: cloudflare-api-token
              key: api-token
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-example
  namespace: ingress
spec:
  secretName: wildcard-example-tls
  dnsNames:
    - "example.com"
    - "*.example.com"
  issuerRef:
    name: letsencrypt-dns
    kind: ClusterIssuer

Önce server satırını staging adresiyle uygulayın, kubectl describe certificate çıktısında Ready gördükten sonra üretim adresine geçin. Bu iki satırlık disiplin, kotayı yakan kurulumların çoğunu önler.

Tuzaklar

• AAAA kaydı varsa doğrulama IPv6 üzerinden gelir. Alan adına IPv6 adresi yayınlayıp o adreste servis vermiyorsanız HTTP-01 sessizce başarısız olur; hata mesajı IPv4'ün çalıştığını söylemez. Ya AAAA kaydını kaldırın ya da IPv6'yı gerçekten sunun.
• CAA kaydı, ekip değişince unutulan bir kilittir. example.com. CAA 0 issue "letsencrypt.org" gibi bir kayıt başka CA'ları engeller; CA değiştirdiğinizde ya da bir alt alan adını başka bir sağlayıcıya verdiğinizde ilk bakılacak yer burasıdır.
• Bölünmüş DNS, istemcinin ön kontrolünü kırar. cert-manager ve benzeri araçlar CA'ya gitmeden önce doğrulamayı kendileri dener. İç ağdaki DNS alan adını özel bir adrese çözüyorsa bu ön kontrol takılır, sipariş hiç açılmaz. DNS-01 kullanıyorsanız istemciye yalnızca dış çözümleyicileri sormasını söyleyin; cert-manager'da --dns01-recursive-nameservers ve --dns01-recursive-nameservers-only bayrakları tam bunun içindir.
• Başarısız doğrulamanın kendi limiti vardır. Yanlış yapılandırılmış bir istemci dakikada bir deneyip aynı saat içinde o ad için kilitlenir. Otomatik yeniden deneme aralığını dakikalara değil saatlere ayarlayın.
• Her herkese açık sertifika şeffaflık günlüklerine yazılır. İç servislerinizin adları (vault.internal.example.com gibi) herkese açık aranabilir hâle gelir. Joker sertifika bu adları saklar; tek tek ad bazlı sertifikalar saklamaz.
• Joker sertifika tek seviye kapsar. *.example.com, a.example.com için geçerlidir ama example.com (apex) ve a.b.example.com için değildir. Apex'i ayrı ad olarak ekleyin.
• 80 portundaki yönlendirme doğrulamayı bozabilir. HTTP'yi HTTPS'e yönlendiriyorsanız /.well-known/acme-challenge/ yolunu bu kuralın dışında bırakın ya da yönlendirmenin geçerli bir sertifikaya düştüğünden emin olun; ilk kurulumda henüz sertifika olmadığı için ikincisi genellikle mümkün değildir.

Ne zaman bu yolu seçmemelisiniz

İnternete hiç çıkmayan ortamlar, kapalı ağlar ve yalnızca kendi istemcilerinizin konuştuğu iç servisler için herkese açık bir CA yanlış araçtır: doğrulama dışarıya bağımlıdır, adlarınız günlüklere düşer ve kısa ömürlü sertifikalar her yenilemeyi dış ağa bağlar. Bu durumda özel bir CA kurun. Bazı özel CA'lar ACME protokolünü konuşur, dolayısıyla aynı istemcileri ve aynı otomasyonu kullanmaya devam edersiniz; değişen tek şey güven zincirinin dağıtımıdır, yani kök sertifikayı istemcilere kendiniz ulaştırırsınız. Kurumsal doğrulama (OV/EV) isteyen bir uyumluluk gereksiniminiz varsa ya da istemci sertifikası (mTLS) dağıtıyorsanız da herkese açık ACME CA'lar bu işi yapmaz.

Herkese açık bir servisiniz varsa ve sertifika ömürleri sektör kararıyla giderek kısalıyorsa, otomasyonsuz sertifika yönetimi zaten bir seçenek olmaktan çıkmıştır. Doğru soru "otomatikleştirelim mi" değil, "hangi doğrulama yöntemiyle, durumu nerede saklayarak ve kotayı nasıl koruyarak" sorusudur.