ACME/Let’s Encrypt Otomatik SSL Yenileme: Staging→Prod Akışı

SSL sertifikası yenileme, birçok altyapıda “yapılacaklar listesinde en sonda” kalır. Son kullanma tarihi yaklaşınca doğru ayarın yokluğu servis kesintisi, tarayıcı uyarıları ve e-ticarette kayıp olarak geri döner. Bu rehberde ACME istemcisini (Let’s Encrypt) staging (test) ortamında doğrulayıp prod (gerçek) ortama geçmenin kontrol listesini; ayrıca cron ve systemd ile doğrulama akışını net biçimde kuruyoruz. Amaç: Sertifika yenileme otomasyonunun çalıştığını, hata durumunda ne olacağını ve nereden izleyeceğinizi önceden görmeniz.

1) Staging → prod geçişi neden kritik? (ve risk kontrolü)

Let’s Encrypt’te sertifika alma ve yenileme süreçlerinde iki ayrı ACME uç noktası kullanılır: - Staging: Tarayıcı uyarısı vermeyen bir test akışı değil; amaç hatasız akış denemesi ve limit tüketmeden doğrulamadır. - Prod: Gerçek sertifika limitleri ve gerçek kullanıma yönelik emisyon.

Staging’den prod’a geçmezseniz şu sorunlar yaşanır: - Otomasyon “çalışıyor” sanılır ama prod uç noktasında doğrulama/izin/route farkı nedeniyle yenileme başarısız olur.

Prod’a geçmeden staging doğrulaması yapmanın somut getirileri: - HTTP-01 veya DNS-01 doğrulama adımlarının çalıştığını görürsünüz. - Sunucuda web root, yönlendirme (redirect) kuralları, firewall izinleri ve DNS kayıtlarını kontrol edersiniz. - Yenileme tetikleyicisinin (cron/systemd) gerçekten çalıştığını log üzerinden doğrularsınız.

Staging ile doğrulamanız gereken minimum senaryolar

Aşağıdaki senaryolardan her biri staging üzerinde en az bir kez gerçekleşmelidir: 1. Sertifika ilk kez oluşturma (initial issuance) 2. Otomatik yenileme (renew) 3. Yenileme sonrası servisin yeniden yüklenmesi (nginx/apache reload) 4. Hata durumunda uygun log üretimi (ör. doğrulama başarısız)

Not: “Wildcard” ve “multi-domain (SAN)” kullanıyorsanız staging üzerinde doğru alan adları için doğrulamayı ayrıca test edin.

2) Doğru ACME doğrulama yöntemini seçin: HTTP-01 vs DNS-01

Yenileme başarısı, doğrulama yöntemine bağlıdır. En sık iki yöntem: - HTTP-01: Alan adına gelen isteğin doğrulama dosyasını sunucuya ulaştırmasını ister. - DNS-01: Alan adına geçici TXT kaydının eklenmesini ister.

Aşağıdaki tabloda net karşılaştırma var:

Net öneri

• Sunucunuz sabitse ve 80 portu sorunsuz çalışıyorsa HTTP-01 pratik olabilir.
• Cloud DNS üzerinden wildcard yönetimi, CDN katmanı veya sık IP/route değişimi varsa DNS-01 daha güvenilir bir otomasyon zemini sunar.

3) Staging’da çalıştırma: ACME istemcisi kurulum ve doğrulama

ACME istemcisi olarak pratikte en yaygın seçenek certbot veya daha hafif alternatiflerdir (ör. acme.sh). Bu rehber yöntemi anlatır; kullandığınız istemciye göre komut isimleri değişebilir.

Staging için net akış

1. ACME istemcisini kurun.
2. Doğrulama yöntemini belirleyin (HTTP-01/DNS-01).
3. Staging uç noktasını aktif edin.
4. Logları kontrol edin.
5. Yenilendikten sonra servisi reload edin.

Örnek bir akış (istemciye göre değişir) şu mantığı izler: - İlk çalıştırmada staging ile sertifikayı alın. - Sertifika dosyalarının beklenen dizine geldiğini doğrulayın. - Reload adımının gerçekten tetiklendiğini kontrol edin.

Yenileme komutunu “deneme” yaptırın

Sertifikanın gerçek son kullanım süresini beklemeden yenileme akışını test etmek için istemcinin “dry-run” benzeri özelliği kullanılır. Bu sayede staging’de renew komutunun tetiklenmesi ve servis reload’unun çalışması teyit edilir.

4) prod’a geçiş: limit tüketmeden güvenli doğrulama

Staging testleri tamamlanınca prod’a geçin. Burada kritik nokta: prod’a geçerken aynı alan adlarıyla sertifikayı yeniden üretmeden önce yenileme mantığının doğru çalıştığından emin olmanızdır.

Prod geçişinde yapılacak 5 kontrol

1. DNS kayıtları doğrulama yöntemiyle uyumlu mu?
2. HTTP-01 kullanıyorsanız: 80’den gelen istek doğru sunucuya gidiyor mu?
3. Sertifika dosya yolları (live/archive) doğru mu?
4. Servis reload komutu çalışıyor mu?
5. Otomasyon tetikleyicisi (cron/systemd) staging’te log üretti mi?

Log doğrulaması için net hedefler

• Yenileme başlangıcı logu
• ACME doğrulama adımı logu
• Başarılı yenileme sonucu
• Reload tetiklenmesi

Bir otomasyon kurduğunuzda en sık yapılan hata şudur: “Komut çalışıyor” ama reload hiç tetiklenmiyor ya da yanlış bir servis adı kullanıldığı için prod’da yine tarayıcı uyarısı görülüyor.

5) cron mu systemd mi? Yenileme doğrulama akışı tasarımı

Otomatik yenilemenin iki yaygın yolu var: - cron: Belirli aralıklarla komutu çalıştırır. - systemd timers: Daha deterministik zamanlama ve durum yönetimi sağlar.

Karşılaştırma (somut farklar)

Cron ile net akış (pratik şablon)

1. Düzenli aralık belirleyin (ör. günde 1 kez kontrol).
2. Yenileme komutu “renew” yapmalı; “get-new” gibi fazla emisyon yapmamalıdır.
3. Başarısızlıkta log üretmelidir.
4. Yenileme sonrası reload olmalıdır.

Cron’un asıl riski: Komutun “başarısız ama sessiz” kalmasıdır. Bu nedenle cron satırını oluştururken hata çıkışlarını loga yönlendirin.

systemd ile net akış (daha sağlam)

systemd tarafında iki ünite yaklaşımı yaygındır: - timer: belirli aralıkla çalıştırır - service: yenileme komutunu çalıştırır

systemd ile en önemli kazanım: “servis başarısız mı?” sorusunu doğrudan birim durumu üzerinden yanıtlayabilmenizdir.

Akış adımı: staging→prod uyumlu doğrulama

• Staging testlerinde timer/service dosyasında staging hedefini doğrulayın.
• Prod’a geçerken yalnızca environment/arg değiştirin; servis adımlarını aynı tutun.

“Doğrulama” denetimi: yalnızca komutun çalıştığını değil, sonucu da kontrol edin

Aşağıdaki iki kontrol otomasyon kalitesini belirler: 1. Sertifika dosyalarının modification time değişti mi? (yeni dönem aktif oldu mu) 2. Web sunucusu gerçekten yeni sertifikayı çekiyor mu?

Web sunucusu reload doğrulaması

• nginx: konfigurasyon yeniden yüklenince sertifika zinciri güncellenir.
• apache: graceful reload ile kesinti azaltılır.

Bu doğrulamayı manuel yapmayı değil, otomasyona “reload sonrası kontrol” eklemeyi hedefleyin.

6) Kesintisiz yenileme (zero-downtime) için servis reload tasarımı

Sertifika yenilendiğinde web sunucusunu reload etmezseniz risk şudur: Yenileme başarılı olsa bile kullanıcılar eski sertifikayı görmeye devam eder.

Net strateji

• Yenileme komutu bittiğinde yalnızca “başarı” durumunda reload çalıştırın.
• Reload komutunu restart değil, tercihen reload/graceful modunda kullanın.
• Birden fazla site (vhost) varsa reload bir kez yapılmalı; her domain için ayrı reload tetiklenmemelidir.

Çoklu domain ve wildcard senaryosunda kontrol listesi

• Aynı sunucuda birden fazla alan adı varsa: her domain için sertifika dosyaları doğru dizinde mi?
• Wildcard kullanıyorsanız: wildcard içeren doğrulama yöntemi (DNS-01) otomasyonda tam otomatik mi?

7) Failure (başarısızlık) yönetimi: ne zaman uyarı alacaksınız?

Otomasyonun başarısız olması kaçınılmazdır; kritik olan bunun fark edilme hızıdır. Bu rehberde hedef, “ertesi gün tarayıcı uyarısı gelmeden” önce fark etmektir.

Net alarm/izleme önerileri

• systemd için: unit exit code ve journal loglarına günlük bakın.
• cron için: stdout/stderr log dosyasında “renewal succeeded” / “failed” benzeri anahtar kelimeleri arayın.

Minimum izleme hedefi

• Yenileme denemesi her gün çalışmalı
• “Başarılı” logu görülmeli
• En azından haftada bir kez sertifikanın geçerlilik tarihini (notAfter) kontrol edin

Staging’de kalma hatası (prod’a hiç geçmemek)

En çok atlanan hata: staging anahtarının prod’a alınmaması. Bunu engellemek için şu kuralı uygulayın: - Prod’a geçtiğiniz gün bir kez “prod endpoint ile issuance” tamamlanmalı. - Yenilenen sertifikanın seri/çıkarım bilgileri (issuer) üzerinden staging olmadığını doğrulayın.

8) Uygulanabilir kontrol listesi (staging→prod ve cron/systemd)

Son bölümde hepsini tek bir akışa indiriyoruz.

Staging kontrol listesi

• [ ] Doğrulama yöntemi (HTTP-01/DNS-01) doğru
• [ ] Yenileme denemesi (dry-run) logları üretildi
• [ ] Sertifika dosyaları oluştu
• [ ] Servis reload tetiklendi
• [ ] Hata senaryosunda log üretimi var

Prod kontrol listesi

• [ ] Staging parametresi kapalı
• [ ] İlk prod issuance başarılı
• [ ] Timer/cron her gün çalışıyor
• [ ] Reload başarısı doğrulanıyor
• [ ] Basit izleme (günlük log kontrolü + geçerlilik tarihi) kurulu

Son aksiyon (NetKıyas tavrıyla karar kolaylaştırma)

Bu rehberi temel alarak şu sırayı uygulayın: Önce staging’de doğrulama ve renew+reload akışını log ve sertifika dosyası değişimi üzerinden teyit edin; ardından prod’a geçip timer/cron doğrulamasını aynı mantıkla sürdürün. Eğer doğrulama yöntemi belirsizse mevcut altyapınıza göre HTTP-01/DNS-01 seçimini netleştirin. Bu planı takip eden sistemlerde sertifika yenileme, son dakika sürprizinden çıkıp ölçülebilir ve yönetilebilir bir operasyon haline gelir.