Kendi ACME istemcinle otomatik wildcard SSL yönetimi (bulut DNS)

Wildcard TLS (".domain.tld") kullanımında en kritik risk, sertifikanın doğru zamanında yenilenmemesi ve DNS doğrulamasının (ACME DNS-01*) hatalı yapılmasıdır. Let’s Encrypt tek seçenek değildir: kendi ACME istemcinizi (client) çalıştırarak yenileme mantığını kontrol eder, rate limit, politika ve sertifika altyapısı kararlarını sizin verdiğiniz şekilde uygularsınız. Bu rehberde bulut DNS sağlayıcısını (Route 53, Cloudflare, Google Cloud DNS gibi) devreye alıp wildcard sertifikayı otomatik doğrulayan uçtan uca bir kurgu kuracaksınız; ayrıca doğrulama, izinler, anahtar saklama ve sıfır kesinti yenileme için net kontroller öğreneceksiniz.

Hedef: wildcard sertifikayı ACME DNS-01 ile otomatik doğrulamak

Wildcard sertifika için ACME CA (Certificate Authority) doğrulaması genellikle DNS-01 ile yapılır. Mantık şu şekildedir:

• Sertifika isteği: *.example.com
• ACME istemcisi, doğrulama için belirli bir isimde bir DNS TXT kaydı üretir.
• CA, ilgili domain için TXT kaydını sorgular.
• TXT kaydı göründüğünde sertifika verilir.

Let’s Encrypt kullanmıyor olsanız da ACME protokolü benzer akışı korur. Fark genellikle:

• Hangi ACME CA ile çalıştığınız (endpoint, hesap yapısı)
• İstemcinin kullandığı challenge entegrasyon eklentisi (DNS sağlayıcı API’si)
• Sertifika dosyalarının sunuculara dağıtımı (Nginx/Apache/reload)

Bu rehberin odağı, CA bağımsız olacak şekilde "DNS tarafını otomatik yönetip" otomasyonu sağlamlaştırmaktır.

Neden kendi ACME istemcini çalıştırıyorsun?

Aşağıdaki kontrol başlıkları, kararınızı teknik olarak somutlaştırır:

• Yenileme zamanlaması: Varsayılan yenileme pencereleri yerine kendi eşiğinizi ayarlarsınız.
• Anahtar güvenliği: ACME istemcisinin private key saklama stratejisini kontrol edersiniz.
• Operasyon: Farklı servislerde aynı sertifikayı kullanırken dağıtımı siz tasarlarsınız.
• Bulut DNS entegrasyonu: API token kapsamlarını (scoped permissions) siz belirlersiniz.

Mimari seçimleri: tek sunucu mu, çok servis mi?

Önce sertifikayı kim kullanacak sorusunu netleştirin. ACME istemcisinin sertifikayı ürettiği anda doğru yere koyulması gerekir.

Dağıtım senaryoları

Aşağıdaki senaryoların her biri farklı pratik gerektirir:

1) Tek reverse proxy (Nginx/HAProxy) - ACME istemcisi sertifikayı /etc/ssl/... altına yazar. - nginx -t sonrası systemctl reload nginx ile devreye alma yapılır.

2) Birden fazla uygulama sunucusu - Sertifika dağıtımı için ya merkezi bir “certificate distribution” noktası kurulur ya da her sunucu ACME istemcisi çalıştırır. - En sorunsuz yaklaşım genelde: tek ACME istemcisi + dağıtım (SSH/SCP/agent) ile tutarlılık.

3) Kubernetes / container ortamı - Sertifika dosyaları secret olarak yönetilir. - Dosya değişimleri için reload mekanizması (ingress controller) net tasarlanır.

Bu rehber, 1 ve 2 numarayı esas alır; çünkü “bulut DNS dahil wildcard otomasyonu”nda kritik kısım DNS-01 akışıdır.

Bulut DNS entegrasyonu (API token ile)

Wildcard DNS-01 doğrulamasında kritik parça, TXT kaydını doğru isim ve doğru değerle ekleyip kaldırabilmenizdir. Bunun yolu, DNS sağlayıcının API’sine kimlik doğrulayıp geçici TXT kaydını yazmaktır.

TXT kayıt ismi ve değer mantığı

ACME istemcisi çoğu zaman şu bilgileri sizin yerinize hesaplar:

• TXT kaydının adı (record name)
• TXT kaydının değeri (token + hashing/CA beklentisine göre)

Sizin yapacağınız iş genellikle şudur:

• ACME istemcisine “bu domain için bu DNS sağlayıcısında TXT yaz/oku yap” demek
• DNS sağlayıcı tarafında yeterli yetkiye sahip token ile çalışmak

Aşağıdaki tablo, pratikte hangi parametrelerin değiştiğini gösterir:

Token kapsamları (least privilege)

DNS provider token’ınızı en düşük kapsamla verin. Örnek olarak:

• Sadece ilgili zone için “TXT record: write/delete”
• Gerekirse “read” (ACME istemcisi mevcut record çakışmasını kontrol edebilir)
• Tüm DNS yönetimini değil, sadece gereken işlemleri verin

Bu yaklaşım, yanlışlıkla yanlış zone’da record yazma riskini ciddi azaltır.

Kendi ACME istemcini kurma: DNS-01 otomasyonu + güvenli anahtar saklama

ACME istemcisi seçimi serbesttir; pratikte kullanacağınız bileşenler şunlardır:

• ACME hesabı (account key): Sertifika talebi için
• Order / challenge yönetimi: DNS-01
• Sertifika çıktıları: fullchain ve private key
• Hook (event) mekanizması: doğrulama bittikten sonra reload/dağıtım

Önerilen klasör ve dosya ayrımı

Sertifikalar üretildikten sonra iki şeyi ayırın:

• Private key (private) — en sıkı izinler ile
• Certificate chain (fullchain) — web sunucusu tarafından okunur

Örnek klasör şeması (yol isimleri ACME istemcine göre değişebilir):

• /etc/acme/<instance>/keys/
• /etc/acme/<instance>/certs/<domain>/
• /etc/acme/<instance>/work/ (challenge geçici dosyalar)

Önemli teknik hedef: private key için chmod 600 ve yalnızca reload yapan servis kullanıcısına okuma izni.

Zamanlama ve yenileme eşiği

Wildcard sertifikada en büyük operasyonel hata, CA yenileme penceresine yaklaşmadan dosya değişimini yapmamak veya yanlış TTL yüzünden CA sorgusunda TXT kaydını kaçırmaktır.

Somut yaklaşım:

• DNS record yazıldıktan sonra, acme istemcisinin “bekleme” parametresi veya “propagation wait” mantığı kullanılmalı.
• Yenileme için "sertifika süresi bitmeden" bir takvim eşiği belirlenmeli (ör. 30 gün kala yenileme). CA ile çalıştığınız model ne olursa olsun, pratikte bu değer kararsız bir “yakın zaman” hatasını azaltır.

Sıfır kesinti yenileme (reload ve doğrulama adımları)

Sertifika yenilendiğinde web sunucusunun kademesiz reload edebilmesi gerekir. Amaç: bağlantıları düşürmeden yeni sertifikayı devreye almak.

Nginx için güvenli reload sırası

Aşağıdaki akış, pratikte en az arızaya sebep olan akıştır:

1) Yeni sertifika dosyaları yazıldıktan sonra 2) nginx -t ile yapı doğrulama 3) systemctl reload nginx 4) Sonra kısa bir sağlık kontrolü: openssl s_client veya basit HTTPS istekleri

Eylem adımı örnekleri (komutlar ortamınıza göre uyarlanır):

• nginx -t
• systemctl reload nginx

Apache için güvenli reload sırası

Apache tarafında genellikle:

• apachectl configtest
• systemctl reload apache2 (dağıtıma göre servis adı değişebilir)

Sağlık kontrol listesi (somut)

Her yenileme sonunda şunları otomasyona dahil edin:

• DNS-01 TXT kaydı CA tarafından doğrulandı mı? (istemci logundan)
• Sertifika dosyaları doğru dizine yazıldı mı?
• Web sunucusu yeni sertifikayı gördü mü? (sıradaki TLS handshake ile)
• Sertifika zinciri (fullchain) doğru mu?

Net teşhis: DNS-01 başarısızlığında tipik nedenler ve kesin kontroller

Kendi istemcinle wildcard yönetiminde başarısızlığın çoğu, DNS tarafındaki görünürlük gecikmesi ve yetki kapsamı kaynaklı olur.

1) TXT kaydı yanlış zone’a yazıldı

Belirti: CA hiç doğru token’ı göremez.

Kontrol: - DNS sağlayıcı panelinde ilgili zone’da TXT kaydı göründü mü? - Token’ın zone ID kapsamı doğru mu?

2) TTL düşük / propagasyon gecikmesi

Belirti: TXT kaydı yazıldı ama CA sorgusunda “henüz yok”.

Kontrol: - DNS sağlayıcı propagasyon davranışı - İstemcide “propagation wait” ayarı

3) Aynı isimde çakışan challenge

Belirti: Token değer eşleşmez.

Kontrol: - Aynı anda iki yenileme süreci çalışıyor mu? - Cron/systemd timer çakışması var mı?

4) Yetki eksikliği (write/delete yok)

Belirti: Record hiç eklenmez veya silinemez.

Kontrol: - API token kapsamında TXT write ve delete izinleri var mı? - İstemci “cleanup” işlemini yapabiliyor mu?

Teşhis için log standardı

Operasyon ekibinin hızlı teşhis yapabilmesi için logları şu ana başlıklarla ayrıştırın:

• Challenge başlatma
• DNS TXT yazma sonucu
• CA doğrulama sonucu
• Sertifika üretim sonucu
• Reload/dağıtım sonucu

Wildcard kapsamı ve domain yapısı: pratik kısıtlar

Wildcard sertifika üretmek istediğiniz domain yapısı net olmalı:

• *.example.com yalnızca foo.example.com için çalışır; example.com apex domainini kapsamaz.
• Birden fazla alt alan için (ör. *.example.com, *.sub.example.com) ayrı sertifikalar veya SAN (Subject Alternative Name) stratejileri gerekebilir.

Bu nedenle, ACME istemcinizi kurarken hangi domainleri istiyorsunuz:

• Tek wildcard: *.example.com
• Apex + wildcard: example.com + *.example.com

Bu kombinasyon, uygulama tarafında beklenmedik 404/SSL uyarısı riskini azaltır.

ACME istemci seçerken kontrol listesi (DNS-01 uyumluluk)

Let’s Encrypt dışına çıktığınızda, “DNS-01 otomasyonu” her istemcide aynı kalitede değildir. Şu maddeleri kontrol edin:

• DNS sağlayıcıları için hazır eklenti var mı? (Cloudflare/Route53/GCP DNS vb.)
• TXT kaydını yazıp sildiğinde “cleanup” yapıyor mu?
• Challenge için bekleme (propagation wait) veya benzeri mekanizma var mı?
• Sertifika çıktısı sonrası reload için hook (deploy hook) var mı?
• Rate limit / hata durumunda yeniden deneme stratejisi var mı?

Bu liste, seçimi “fikir”den “doğrulanabilir teknik kriter”e taşır.

Somut kurulum akışı (özet) ve önerilen sonraki adım

Aşağıdaki adımlar, projeyi sahaya taşımada pratik bir yol haritası sağlar:

1) Bulut DNS sağlayıcınızda ilgili zone için TXT write/delete kapsamlı API token oluşturun. 2) Kendi ACME istemcinizi wildcard için DNS-01 challenge kullanacak şekilde yapılandırın. 3) Sertifika üretiminden sonra web sunucusunu (Nginx/Apache) güvenli reload yapacak hook’u ekleyin. 4) Yenileme sırasında cron/systemd çakışmasını engelleyin; tek akış kuralı koyun. 5) İlk yenilemeyi üretimden önce test ortamında denetleyin (TXT doğrulama + TLS handshake kontrolü).

Sonuç olarak: Wildcard SSL otomasyonunda asıl kontrol noktası “sertifikanın ne zaman üretileceği” kadar “CA’nın DNS’te TXT token’ı gördüğünden emin olma” sürecidir. Kendi ACME istemcinle bulut DNS entegrasyonunu doğru yetki (least privilege) ve doğru reload stratejisiyle kurduğunuzda, Let’s Encrypt’e bağlı riskleri azaltıp operasyonu standartlaştırırsınız. Bir sonraki adım olarak, kullanmayı düşündüğünüz ACME istemcisini seçin, sonra hedef bulut DNS sağlayıcınızda TXT-01 yazma/silme yetkisini test edin ve ilk wildcard yenilemeyi loglar üzerinden doğrulayın.