# Sertifika Yaşam Döngüsünü Otomatikleştirmek: ACME, Vault ve Pratik Kontroller

- Bağlantı: https://musti.org/guncel-teknoloji/sertifika-yasam-dongusu-otomasyon/
- Yayımlanma: 2026-09-30T08:58:00+03:00
- Yazar: mmutlu

🎧 Bu yazıyı dinleyebilirsiniz

Tarayıcınız ses oynatmayı desteklemiyor.

Bir kurumun en sık gözden kaçırdığı opsiyonlardan biri sertifika yönetimi oluyor.
Ben de uzun yıllarda birkaç kere “sertifika süresi doldu, hizmet kapandı” paniği
yaşadım; o anlarda öğrendiğim en önemli şey, sertifikaları güvencesiz bir dosya 
kutusunda veya bir yöneticinin takvim hatırlatıcısına bırakmanın büyük risk olduğuydu.
Aşağıda sertifika yaşam döngüsünü (envanter, otomasyon, izleme, acil durum planı)
pratik adımlarla anlatıyorum.

## Neden sertifika yönetimi kritik?

Sertifikalar —HTTPS, mTLS, kod imzalama, e-posta S/MIME— hizmetin gizliliğini ve
bütünlüğünü sağlar. Bir sertifikanın beklenmedik şekilde süresi dolduğunda bağlı
servislerin tamamı etkilenebilir; kullanıcılar hata sayfaları, uygulamalar bağlantı
hataları görür. Ayrıca ele geçirilmiş ya da yanlış yapılandırılmış özel anahtarlar
ciddi güvenlik zafiyetleri oluşturur. Bu yüzden sadece “yenileme” değil; envanter,
takvim değil gerçek otomasyon ve reversibility (geri alma) planı gerekir.

## Hızlı envanter ve risk haritası

İlk iş olarak elinizde ne olduğunu doğru listeleyin. Hem dış (internet-facing) hem
iç (intranet, IoT, servis hesapları) sertifikaları toplayın. Basit komutlarla hızlıca
özet alabilirsiniz:

    ```
    # Linux: uzaktan kontrol için
    openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null | openssl x509 -noout -dates

    # Sunucudaki sertifikaların hızlı listesi (Windows PowerShell)
    Get-ChildItem -Path Cert:\LocalMachine\My | Select-Object Subject, NotAfter, Thumbprint

    # Tek bir dosyadaki sertifika bitiş tarihini göster
    openssl x509 -in /etc/ssl/certs/example.crt -noout -enddate
    ```

Bu çıktıların CSV/JSON’a dökülmesiyle kritik sertifikaları, sahibini ve bitiş tarihlerini
gösteren basit bir envanter oluşturabilirsiniz. Kriter örneği: 30 gün içinde süresi
dolacak, wildcard sertifikalar, root/CA’larla ilişkili özel anahtarlar.

## Otomasyon seçenekleri: ACME, Vault, HSM

Otomasyona karar verirken üç yaygın yaklaşım var; her biri farklı seviyede kontrol
ve güvenlik sağlar.

 * **ACME (Let’s Encrypt, acme.sh, Certbot):** İnternet’e açık servisler için hızlı
   ve ücretsiz. Certbot veya acme.sh ile Nginx/Apache otomasyonu kolayca kuruluyor.
 * **HashiCorp Vault PKI:** İç sertifikalar, kısa ömürlü sertifikalar ve dinamik
   istemci sertifikaları için uygundur. Vault, merkezi güvenlik, raf ömrü (TTL) 
   ve görevlendirilmiş revocation mekanizmaları sağlar.
 * **HSM / Cloud KMS:** Özel anahtarların donanım veya cloud KMS içinde tutulması
   gerekiyorsa entegrasyon şart. Anahtar asla düz dosyada olmamalı.

Basit ACME yenileme örneği (certbot):

    ```
    # Sertifika alma
    sudo certbot --nginx -d example.com -d www.example.com

    # Yenileme testi
    sudo certbot renew --dry-run

    # Cron / systemd timer genelde otomatik yenileme sağlar
    ```

Vault ile kısa örnek (konsept):

    ```
    # Vault PKI üzerinden sertifika isteme (Vault yapılandırması sonrası)
    vault write pki/issue/example-dot-com common_name="app.example.com" ttl="72h"
    ```

## İzleme ve doğrulama — otomasyon yeterli değil

Otomasyon kurulduktan sonra doğrulama katmanı olmazsa eksik kalır. İzleme şu başlıkları
içermeli:

 * Sertifika bitiş takibi (30/14/7/1 gün alarmları).
 * Gerçek servis üzerinden doğrulama (TLS handshake testi, OCSP stapling kontrolü).
 * Yenileme sonrasında canary testi: trafik küçük bir kesimde yenilenmiş sertifikayla
   doğrulanmalı.

Örnek izleme komutu (basit):

    ```
    # OpenSSL ile OCSP / expiry kontrolü
    openssl s_client -connect app.example.com:443 -servername app.example.com -status
    ```

## Acil durum: iptal (revoke) ve yedekleme planı

Bir anahtar ele geçirilmişse hızlıca iptal ve yeni sertifika çıkarma kabiliyeti 
hayati. Planınızda şunlar olmalı:

 * Revocation prosedürü ve sorumlular: kim iptal eder, kim yeni sertifika dağıtır.
 * Yedek anahtar veya alternatif CA yol haritası (özellikle dış bağımlılıklar için
   SLA gözden geçirilmeli).
 * Rollback planı: Yeni sertifika sorun yaratırsa eski duruma dönüş adımları (DNS
   veya yük dengeleyici ayarlarıyla hızla switch yapılabilecek şekilde tasarlayın).

## Pratik öneriler — benim uyguladıklarım

 * Wildcard sertifikaları minimumda tutun; mümkünse servis bazlı kısa ömürlü sertifikalara
   geçin. Benzer hizmetlerde wildcard yüzünden geniş çaplı yeniden başlatmalar yaşamıştık.
 * Her yeni sertifika dağıtımında küçük bir “canary” havuzu belirleyin. 5 sunucuda
   test edilmeden prod trafiğe vermem.
 * Yedekleme: Özel anahtarlar için offsite şifreli yedek + audit logging. Anahtar
   taşınması gerektiğinde HSM/KMS tercih edin.
 * İzleme entegrasyonu: Prometheus + blackbox_exporter ile SSL expiry zamanlarını
   metric olarak alın, Grafana’da paneller oluşturun.
 * Dökümantasyon: Sertifikanın hangi sırada yenileneceği, DNS doğrulama adımları,
   sorumlu kişi ve rollback adımları açıkça yazılı olsun.

## Başlarken kısa yol haritası

1) 1 hafta içinde tam envanter çıkartın. 2) Kritik dış servisler için ACME otomasyonunu
kurun ve dry-run yapın. 3) İç PKI gerekiyorsa Vault POC başlatın. 4) İzleme ve canary
testlerini devreye alın. 5) Revocation/rollback prosedürünü tatbikatla doğrulayın.

Benim deneyimim: bir kez haftasonu döndüğümde müşteri portalının kapalı olduğunu
gördüm; sebep basitti: wildcard sertifika süresi dolmuştu ve yenileme tek bir kişinin
e-posta hatırlatıcısına bağlıydı. O günden sonra otomasyonla beraber izleme ve acil
durum talimatı olmadan bir adım bile atmamaya karar verdim.

Sertifika yönetimi sıkıcı gözüken ama operasyonel açıdan düşük maliyetle büyük riskleri
azaltan bir alandır. Küçük bir POC ile başlayın; otomasyonun işe yaradığını gördükçe
kapsamı genişletmek en azından benim için hep işe yaradı. Şimdi envanterle başlayın—
en azından bir komut çalıştırın ve hangi sertifikaların 30 gün içinde biteceğini
görün.