Let’s Encrypt Wildcard SSL ve Nginx/Apache Otomatik Yenileme

Wildcard SSL (joker sertifika), tek bir sertifikayla "*.example.com" alt alan adlarını kapsar. Ancak Let’s Encrypt wildcard sertifika, standart HTTP doğrulamasından (HTTP-01) farklı bir doğrulama gerektirir. Bu rehberde wildcard sertifikanın mantığını, doğru DNS/route kurulumunu ve Nginx ile Apache üzerinde otomatik yenilemenin kesintisiz (zero-downtime) nasıl yapılandırılacağını net adımlarla anlatıyorum. Son bölümde, yenileme hatalarını hızlı tespit etmek için kontrol listesi bırakıyorum.

Wildcard SSL’de Let’s Encrypt doğrulaması nasıl çalışır (DNS-01)

Let’s Encrypt’in wildcard sertifika verebilmesi için doğrulama yöntemi DNS-01 olmalıdır. Mantık şu: Sertifika otoritesi, doğrulamayı yapmak için domain üzerindeki _TXT kayıtlarına bakar.

DNS-01 neden şart

• HTTP-01, yalnızca belirli bir URL’den (/.well-known/acme-challenge/...) doğrulama ister.
• Wildcard için bu yöntem güvenli şekilde yapılamaz; çünkü "*" kapsama her alt alan adı için farklı HTTP yolu gerektirir.
• DNS-01 ise tek bir TXT kaydı ile doğrulamayı tüm alt alan adlarına yayar.

İstenen şey: TXT kaydı

Let’s Encrypt client (genellikle Certbot veya acme.sh) wildcard için şu tarz bir TXT kaydı üretir: - Kayıt adı: _acme-challenge.example.com (domaininize göre) - Kayıt değeri: Let’s Encrypt tarafından verilen token

Sertifika otoritesi bu TXT kaydı görünce doğrulamayı başarılı sayar ve wildcard sertifika üretir.

DNS provider ile otomasyonun anahtarı

Wildcard yenileme sırasında her seferinde TXT kaydı üretip kaldırmak gerekir. Otomasyonu sorunsuz yapmak için şu iki yaklaşımdan biri kullanılır: 1. DNS API: Sağlayıcının (Cloudflare, Hetzner DNS, Route53 vb.) API’si üzerinden TXT kaydı otomatik eklenir/silinir. 2. Dosya/Proxy değil, DNS anahtarlı yöntem: Certbot DNS eklentisi ile “manual” üretim yapılır; bu pratikte yalnızca kontrollü senaryolarda tercih edilir.

Uygun plan: Nginx ve Apache mimarisini hazırlama

Wild card sertifikayı aldığınızda dosyalar belirli bir dizine yazılır. Otomatik yenileme esnasında yeni sertifika dosyaları güncellenir ve web sunucusunun yeniden yüklenmesi gerekir.

Dosya yolları ve reload mantığı

Nginx/Apache için temel hedef: - Sertifika dosyası güncellendiğinde servis kesilmeden reload edilsin. - Sürekli restart yerine reload tercih edilir.

Nginx tarafında kesintisiz yaklaşım genelde şöyledir: - systemctl reload nginx (veya nginx -t sonrası reload)

Apache tarafında: - apachectl graceful / systemctl reload apache2

Bu yaklaşım, aktif bağlantıları kesmeden yeni konfigürasyonun alınmasını sağlar.

Wildcard kapsamı: sadece alt alan adları

Wildcard sertifika şunu kapsar: - a.example.com, b.example.com gibi alt alanlar Kapsamaz: - example.com kök alan adı Pratikte çoğu kişi example.com için de ayrı bir sertifika SAN olarak ekler ya da ayrı bir doğrulama ile aynı sertifikaya dahil eder.

Nginx üzerinde wildcard SSL kurulum ve otomatik yenileme

Aşağıdaki akış; wildcard sertifikayı DNS-01 ile alır, Nginx’i konfigüre eder ve yenilemeyi otomatikleştirir.

1) Certbot’u kur

Sunucu dağıtımınıza göre paket yöneticisi kullanın. - Debian/Ubuntu: apt - RHEL/CentOS: dnf/yum

2) DNS eklentisi seçimi (en önemli adım)

Wildcard otomasyon için Certbot DNS eklentisi, DNS sağlayıcınızı desteklemeli.

Kontrol listesi: - DNS sağlayıcınızın API’si var mı? - Certbot DNS plugin mevcut mu? - API kimlik bilgilerini sunucuya güvenli şekilde saklayabiliyor musunuz?

3) Sertifikayı almak (örnek komut şablonu)

Örnek kullanım şu mantıktadır (token/API değişkenleri sizde):

• Joker: -d "*.example.com"
• Kök alan: -d "example.com" (istenirse)

Komut şablonu: - Certbot DNS plugin ile wildcard request edilir.

Not: Burada sağlayıcınıza göre komut parametreleri değişir. En doğrusu, DNS eklentinizin resmi dökümantasyonundaki komutu birebir uygulamaktır.

4) Nginx konfigürasyonunda sertifika dosyalarını bağla

Nginx server block içinde server_name ve ssl_certificate/ssl_certificate_key tanımlayın.

Tipik yapı: - Sertifika zinciri: fullchain.pem - Özel anahtar: privkey.pem

Örnek konfigürasyon mantığı: - server_name olarak example.com ve *.example.com birlikte belirtilir. - Sertifika dosya yolları Certbot’un yazdığı path’lere işaret eder.

5) Yenileme sırasında Nginx reload (kesintisiz)

Certbot zaten genelde cron/timer ile yenilemeyi planlar. Sizden beklenen, yenileme sonrası reload tetiklemektir.

Aşağıdaki hedefi sağlayın: - Yenileme başarılı olduğunda Nginx’i reload edin. - Reload öncesi konfigurasyon test edin (en azından nginx -t).

Bu amaçla certbot çalıştırılırken “post-hook” mantığı kullanılır. Örneğin mantıksal olarak: - nginx -t doğrula - doğruysa systemctl reload nginx

6) Dosya izinleri ve sahibi

Sertifika dosyaları güncellendiğinde Nginx’in okuyabilmesi gerekir. - Sertifika dizinlerinde www-data veya Nginx’in çalıştığı kullanıcıya okuma izni olmalı. - Özel anahtarın iznini gelişi güzel gevşetmeyin.

Apache üzerinde wildcard SSL kurulum ve otomatik yenileme

Apache tarafında da aynı dosyalar kullanılır; fark konfigürasyon ve reload yaklaşımıdır.

1) Apache modülleri

• SSL/TLS modülü aktif olmalı (dağıtıma göre mod_ssl).

2) VirtualHost içinde sertifika bağla

Özellikler: - ServerName example.com - wildcard için ServerAlias *.example.com - SSLCertificateFile ve SSLCertificateKeyFile path’leri Certbot’un ürettiği dosyalara bağlanır.

3) Yenileme sonrası graceful reload

Kesintisiz hedef: - graceful reload kullanın. - Sürekli restart yerine mevcut bağlantılar kesilmesin.

4) Konfigürasyon doğrulama

Yenileme sonrası en azından: - Apache’nin konfigürasyonu hatasız mu kontrol edilir. - Sonra graceful reload yapılır.

Bu iki adım, yenileme sırasında yanlış path ya da izin sorunu gibi hataların hızlı fark edilmesini sağlar.

Otomatik yenileme: Certbot yenileme takvimi, test ve doğrulama

Wild card sertifikada en kritik nokta yenileme mekanizmasının “gerçekten” çalışmasıdır.

Yenilemeyi simüle edin (dry-run)

Gerçek yenileme yapmadan önce test edin. - “Dry-run” testleri yenilemeyi simüle eder. - DNS-01 doğrulamasının çalıştığını görürsünüz.

Özellikle şu kontrolleri yapın: - DNS-01 TXT kaydı doğru _acme-challenge altında ekleniyor mu? - Sağlayıcı API kimlik bilgileri hatasız mı? - Sertifikayı aldıktan sonra Nginx/Apache reload gerçekten tetikleniyor mu?

Güvenlik: DNS API anahtarlarını saklama

DNS sağlayıcılarının API anahtarlarını dosyada saklıyorsanız: - Dosya izinlerini sadece certbot kullanıcısı okuyabilsin. - Anahtarları loglara yazdırmayın. - “manual” yerine API destekli eklentiyi tercih edin; insan hatasını azaltır.

“Kök alan + wildcard” stratejisi

Pratik bir kural: - *.example.com yanında example.com için de aynı sertifikayı alırsanız yönetim basitler. - Aksi halde farklı sertifika dosyaları ve ayrı renewal süreçleri oluşur.

Sık yapılan hatalar ve hızlı teşhis

Wildcard TLS tarafında sorun genelde “sertifika alınamıyor” değil, “yenileme otomasyonu çalışmıyor” kısmında çıkar.

DNS TTL ve yayılma gecikmesi

DNS-01 doğrulamada TXT kaydının görünmesi gerekir. Eğer ortamda uzun TTL varsa: - TXT kaydı eklenip kaldırıldığında doğrulama zamanında görünmeyebilir.

Çözüm: - DNS sağlayıcınızda doğrulama sırasında kısa TTL kullanın (mümkünse). - Ya da certbot’un bekleme sürelerini DNS sağlayıcınıza göre ayarlayın.

Yanlış _acme-challenge hedefi

Wild card doğrulamada TXT kaydı adı kritik bir detaydır. - example.com ve alt domain hedefi karışırsa doğrulama başarısız olur.

Çözüm: - Certbot DNS eklentisinin talimatında geçen kayıt adını birebir uygulayın.

Web sunucusu reload tetiklenmiyor

Sertifika dosyaları yenilenmiş olsa bile web sunucusu yeni dosyaları okumazsa: - Eski sertifika kullanmaya devam edebilirsiniz.

Çözüm: - Renewal sonrası post-hook ile reload yaptığınızdan emin olun. - Yenileme loglarında reload satırlarını arayın.

Sertifika zinciri (fullchain) hatası

Bazı kurulumlarda sadece cert.pem bağlanır. Bu çoğu senaryoda çalışsa da istemci uyumluluğu düşebilir.

Çözüm: - Nginx/Apache tarafında zincir için fullchain.pem kullanın.

Nginx vs Apache: otomasyonda pratik farklar

Bu bölümde karar vermeyi kolaylaştıracak şekilde, yenileme sürecindeki farkları özetliyorum.

Net kontrol listesi (yayına almadan önce)

Aşağıdaki maddeler tamamlanmadan wildcard TLS’i yayına almak yerine test edin.

Sertifika doğrulama

• [ ] *.example.com kapsama testini yaptım
• [ ] example.com için de sertifika aldım (gerekiyorsa)
• [ ] DNS-01 TXT kaydı doğru isimde ve doğru değerde üretildi

Yenileme otomasyonu

• [ ] Certbot dry-run çalıştırdım
• [ ] Yenileme sonrası Nginx/Apache reload tetiklendi
• [ ] Loglarda yenileme başarılı mesajları var

İstemci tarafı doğrulama

• [ ] Tarayıcıda sertifika zinciri görünüyor
• [ ] Gerekli ara sertifika (chain) doğru taşınıyor (fullchain)

Sonuç: Kesintisiz wildcard için doğru sırayı izleyin

Wildcard Let’s Encrypt SSL’de sorunların büyük kısmı DNS-01 doğrulaması ve yenileme sonrası reload adımının eksik kalmasından çıkar. Doğru yaklaşım şudur: DNS-01’i sağlayıcı API ile otomatikleştirin, web sunucusunda reload’u renewal’a bağlayın ve dry-run ile gerçek senaryoyu simüle edin. Bu üç adımı yaptıktan sonra wildcard sertifikayı düzenli aralıklarla yenileme süreciniz otomatik ve öngörülebilir hale gelir; yayında sürpriz yaşama riskiniz ciddi şekilde düşer.

İlk kurulum için önce dry-run testini tamamlayın; ardından Nginx/Apache reload davranışını loglardan doğrulayın. Sertifika alımından ziyade otomatik yenilemenin çalıştığını kanıtlayın.