SSL Sertifika Otomasyonu: ACME, DNS-01 ve Kubernetes

SSL Sertifika Otomasyonu Nasıl Planlanır?

SSL sertifika otomasyonu; sertifika alma, yenileme ve doğru sunucuya yükleme adımlarını izlenebilir bir iş akışına dönüştürür. ACME protokolü CA ile doğrulama ve sertifika işlemlerini yürütür; zamanlama, dosya dağıtımı ve servisin yeni sertifikayı kullanması ayrıca yapılandırılmalıdır. Burada “SSL sertifikası” ifadesi, güncel HTTPS bağlantılarında kullanılan TLS sertifikasını anlatır.

Alan adları ve TLS sonlandırma noktaları arttıkça elle takip zorlaşır. Süresi geçmiş bir sertifika ödeme sayfasına veya e-posta hizmetine bağlanan istemcilerin bağlantıyı reddetmesine neden olabilir. Amaç yalnızca yeni dosya üretmek değil, geçerli sertifikanın bütün hedef uç noktalarda sunulduğunu doğrulamaktır.

Bu yazıda SSL sertifika otomasyonundaki güncel yaklaşımları, ACME protokolünden DNS‑01 tabanlı wildcard çözümlerine, SaaS ve Kubernetes dünyasındaki çok kiracılı mimarilere kadar adım adım ele alacağız.

ACME Protokolü ve Yeni Nesil Otomasyon Yaklaşımları

ACME ile manuel süreçlerden kurtulmak

SSL otomasyonunda yaygın yaklaşımlardan biri ACME (Automatic Certificate Management Environment) protokolüdür. ACME, istemci ile sertifika otoritesi (CA) arasındaki doğrulama ve sertifika işlemlerini otomatikleştirir. İstemci ve sunucu entegrasyonları birlikte şu iş akışını sağlayabilir:

• Alan adı üzerinde kontrolünüz olduğunu kanıtlama (challenge)
• Sertifika isteği (CSR) üretme
• Sertifikanın alınması ve sunucuya yerleştirilmesi
• Otomatik yenileme denemeleri ve hata yönetimi

Tekrarlanan elle işlemleri azaltmak yenileme hatalarını azaltmaya yardımcı olur; yanlış yetki, zamanlayıcı veya dağıtım ayarı yine kesinti yaratabilir. Tek bir ACME istemcisiyle (örneğin sunucuda çalışan bir agent veya ters proxy bileşeni), istemci kapasitesi ve CA limitleri dahilinde çok sayıda alan adını ve alt alan adını yönetebilirsiniz. İç servisler için ise kullanılan adların seçilen CA’nın sertifika politikasına uygun olması gerekir; yalnızca özel ağda anlamlı olan adlar için özel bir CA gerekebilir.

HTTP‑01, DNS‑01 ve TLS‑ALPN‑01’in otomasyondaki rolü

ACME’nin gücü biraz da farklı challenge türlerini desteklemesinden geliyor. Özellikle üç mekanizma öne çıkıyor:

• HTTP‑01: CA, alan adının TCP 80 portundaki /.well-known/acme-challenge/ yolundan doğrulama yanıtını alır. CDN, yönlendirme ve bütün olası ön uçlar bu isteği doğru yanıtlamalıdır. Let’s Encrypt bu yöntemle wildcard sertifika vermez.
• DNS‑01: Belirli bir TXT kaydı ekleyerek alan adı üzerindeki kontrolü doğrular. İstemci, token ve hesap anahtarından ürettiği değeri _acme-challenge adına yazar. Web sunucusunun internete açık olması gerekmez; CA’nın DNS yanıtına erişmesi gerekir.
• TLS‑ALPN‑01: TCP 443 üzerinde acme-tls/1 ALPN protokolü ve doğrulamaya özel sertifika kullanır. CA, istemci ve TLS sonlandırıcısının bu akışı desteklemesi gerekir. Let’s Encrypt bu yöntemle de wildcard doğrulamaz.

Her projenin ihtiyacı farklı olduğu için hangi türün ne zaman doğru olduğunu anlamak kritik. Bu konuda detaylı teknik senaryoları, hazırladığımız HTTP‑01, DNS‑01 ve TLS‑ALPN‑01 challenge türlerini derinlemesine anlattığımız rehberde adım adım görebilirsiniz.

Kısa ömürlü sertifikalar ve sık yenileme trendi

Kamuya açık güvenilen TLS sunucu sertifikalarında süre kısaltma takvimi Nisan 2025’te kabul edildi. Bu yazının Aralık 2025’teki ilk yayınında zorunlu üst sınır 398 gündü. 4 Kasım 2026 tarihli politika kontrolü: 15 Mart 2026’dan itibaren düzenlenen sertifikalarda üst sınır 200 gün; 15 Mart 2027’den itibaren 100, 15 Mart 2029’dan itibaren 47 gündür. Bunlar üst sınırlardır; CA daha kısa süreli sertifika verebilir. Özel PKI ve satın alınan abonelik süresi bu takvimle aynı şey değildir. Yenileme aralıklarının kısalmasının iki operasyonel sonucu vardır:

• Özel anahtarın ele geçirilmesi durumunda, ilgili sertifikanın kötüye kullanılabileceği süre kısalır. Bu, anahtarın değiştirilmesi ve sertifikanın iptal edilmesi gereğini ortadan kaldırmaz.
• Manuel yönetimin yükü artar: Onlarca alan adı için üç ayda bir yenileme yapmak, otomasyon olmadan hata ve gecikme riskini artırır.

Yenilemeyi sertifikanın son gününe bırakmayın. İstemcinin ve CA’nın desteklediği yenileme zamanlamasını kullanın; hata düzeltme için yeterli süre bırakın. Daha kısa geçerlilik, daha sık çalışan doğrulama ve dağıtım sürecinin kapasitesini ve alarm eşiklerini de yeniden değerlendirmeyi gerektirir.

DNS‑01 Tabanlı Otomasyon ve Wildcard Dönemi

Wildcard sertifikalarla çoklu alt alan adı yönetimi

Bir işletme büyüdükçe alt alan adlarının sayısı hızla artıyor: www., api., panel., cdn., staging., dev.… Bu noktada wildcard sertifikalar (*.ornek.com) ciddi bir esneklik sağlıyor. Tek bir sertifikayla bu kalıba uyan, aynı seviyedeki alt alan adlarını kapsayabilirsiniz; kök alan adı ve daha derin alt alan adları bu wildcard kapsamına kendiliğinden girmez.

Let’s Encrypt ile wildcard sertifika alırken DNS‑01 challenge kullanılır; farklı CA’larda desteklenen doğrulama yöntemini ayrıca kontrol edin. Yani yenilemeyi müdahalesiz yürütmek için DNS tarafında otomasyona hazır olmanız gerekir; TXT kaydını elle eklemek doğrulamayı mümkün kılsa da otomatik yenileme sağlamaz. SAN sertifikası ise birden çok adı açıkça listeler; wildcard içermeyen bir SAN isteği için DNS‑01 her durumda zorunlu değildir. Ortak özel anahtarın ele geçirilmesi kapsanan birden çok adı etkileyebilir.

Bu yaklaşımı pratikte nasıl kuracağınızı, özellikle cPanel, Plesk ve Nginx gibi yaygın ortamlarda adım adım anlatan Let’s Encrypt wildcard SSL otomasyonu rehberimizde uygulamalı örneklerle görebilirsiniz.

API destekli DNS sağlayıcı entegrasyonları

DNS‑01’in otomasyon gücünden faydalanmak için DNS bölgenizi de otomasyona açmanız gerekiyor. Burada tipik akış şöyle:

1. ACME istemcisi sertifika isteği oluşturur.
2. CA, DNS‑01 challenge bilgilerini sağlar; istemci bunlardan gerekli TXT değerini hesaplar.
3. ACME istemcisi DNS sağlayıcınızın API’sine bağlanarak ilgili TXT kaydını otomatik ekler.
4. Kayıt yetkili DNS sunucularında görünür hale gelince istemci doğrulamayı başlatır. Yetkilendirmeler tamamlandıktan sonra istemci CSR ile siparişi sonlandırır; CA, doğrulama ve diğer kontroller başarılıysa sertifikayı üretir.
5. İstemci üretilen sertifikayı indirir ve yapılandırılmış dağıtım adımını yürütür. Sertifikanın üretilmesi, web sunucusuna yüklenmiş olduğunu göstermez.

Bu akışın sağlıklı çalışması için:

• DNS sağlayıcınızın stabil ve belgelenmiş bir API sunması,
• API anahtarlarının güvenli şekilde saklanması (örneğin vault/secrets yönetimi) ve yetkilerinin gerekli DNS kayıtlarıyla sınırlandırılması,
• TTL’nin önbellek süresi olduğunun dikkate alınması ve doğrulama öncesinde TXT kaydının yetkili DNS sunucularında kontrol edilmesi,
• Başarı veya hata sonrasında yalnızca ilgili denemenin TXT değerlerini kaldıran temizleme (cleanup) adımlarının uygulanması

Bu kontroller doğrulama hatalarını teşhis etmeyi kolaylaştırır. Delegasyon kullanıyorsanız istemcinin CNAME/NS desteğini ayrıca inceleyin: cert-manager DNS‑01 çözücüsünde CNAME izleme varsayılan olarak kapalıdır ve uygun cnameStrategy: Follow ayarı gerekir. DNS API sırlarını kaynak kodu, komut çıktısı veya loglara yazmayın.

Çoklu sağlayıcı DNS ve CAA kayıtlarıyla güvence

İş kritik projelerde yalnızca SSL sertifikasını değil, DNS altyapısını da yedekli kurgulamak gerekiyor. Çok sağlayıcılı DNS kullanıldığında challenge TXT kayıtlarının ve CAA politikasının tüm yetkili DNS sunucularında tutarlı olması gerekir. Anycast ve geo‑routing ise tek sağlayıcıda da kullanılabilir; bunlar tek başına kayıtların birden fazla DNS platformuna yayıldığı anlamına gelmez.

Bu senaryolarda CAA kayıtları ile hangi sertifika otoritelerinin alan adınız için sertifika üretmeye yetkili olduğunu tanımlayabilirsiniz. CAA, kurala uyan CA’ların sertifika üretimini sınırlar; istemcinin CA seçimini otomatik düzeltmez ve mevcut sertifikaları iptal etmez. Çok sağlayıcılı DNS kurgularını daha detaylı incelemek isterseniz, octoDNS ile çoklu sağlayıcı DNS ve zero‑downtime geçiş rehberimizi ve CAA kayıtlarının neden ve nasıl kullanılacağını anlattığımız yazımızı mutlaka gözden geçirmenizi öneririz.

SaaS ve Çok Kiracılı Mimarilerde Otomatik SSL

Her müşteri alan adı için otomatik sertifika akışı

Müşterinin kendi alan adını bağladığı SaaS modelinde, örneğin app.musteri.com için, sertifika süreci alan adının hangi kiracı hesabına ait uygulamaya bağlanacağını da dikkate almalıdır:

• Bir müşteri birden çok özel alan adı ekleyebilir; her alan adı–kiracı eşleşmesini ayrı izleyin.
• DNS yönetimi çoğu zaman müşterinin elinde.
• Yanlış CNAME/A kaydı, hatalı yönlendirme veya seçilen CA’ya izin vermeyen CAA kayıtları doğrulamayı ya da sertifika üretimini engelleyebilir.

Bu ortamda yapılması gereken, yeni bir müşteri alan adı eklendiği anda tetiklenen bir “otomatik SSL onboarding” akışı kurmak. Tipik bir akış şu adımlardan oluşuyor:

1. Müşteri panelde alan adını tanımlar.
2. Sistem, müşterinin alan adını bu hesaba bağlama yetkisini doğrular ve başka bir kiracıyla çakışma olmadığını kontrol eder.
3. Sistem, DNS kaydının uygulamanın beklenen giriş noktasına işaret edip etmediğini kontrol eder. DNS‑01 kullanılacaksa TXT kaydını oluşturabilecek API erişimi veya doğrulama delegasyonu da gerekir; A/CNAME yönlendirmesi tek başına yeterli değildir.
4. Şartlar sağlandığında ACME üzerinden otomatik sertifika isteği tetiklenir.
5. Başarılı üretimden sonra sertifika ve doğru kiracı yönlendirmesi hedef ters proxy uçlarına dağıtılır; alan adı eşleşmesi, güven zinciri ve gerçekten sunulan sertifika kontrol edilir.
6. Alan adı kaldırıldığında yönlendirmeyi ve ilgili yenileme işini sonlandırın; saklama politikasına göre anahtar/sertifika kalıntılarını temizleyin. Başka hesaba yeniden bağlanırken yetkiyi tekrar doğrulayın; eski DNS kaydını yeni kiracının yetkisi saymayın.

Bu modelin adımlarını anlatmak için hazırladığımız SaaS’te özel alan adları ve otomatik SSL rehberinde çok kiracılı mimarilerde işe yarayan kalıpları detaylandırıyoruz.

Çok kiracılı mimarilerde olası hata senaryoları

Çok kiracılı bir projede karşılaşılabilecek hata senaryolarına örnekler:

• DNS yanlış yönlendirme: Müşteri A kaydını staging IP’sine, CNAME’i eski altyapıya yönlendiriyor.
• CAA çakışması: Müşteri alan adında, yalnızca farklı bir CA’ya izin veren CAA kaydı bulunuyor.
• Oran limitleri: Hatalı konfigürasyon sebebiyle aynı alan adı için dakikalar içinde onlarca başarısız ACME denemesi yapılıyor.
• Gecikmeli DNS güncellemesi: Önceki kayıtlar yüksek TTL nedeniyle önbellekte kalabiliyor; yeni TXT değerinin yetkili DNS sunucularına henüz ulaşmaması da doğrulamayı geciktirebiliyor.

Onboarding akışına DNS ve CAA kontrolleri, anlaşılır durumlar ve sınırlı tekrar denemeleri ekleyin. CA’nın Retry-After yanıtına uyun; geçici hatalarda aralığı artıran ve isteklerin aynı anda yığılmasını önleyen tekrar zamanlaması kullanın. Yetki veya DNS yapılandırması hatasını sürekli yeniden denemek yerine operatöre yönlendirin.

ACME oran limitleri ve yedekli CA stratejileri

ACME servislerinin limit kategorileri ve eşikleri CA’ya göre değişir. Geçerli sertifikaları her uygulama dağıtımında yeniden üretmeyin; yenilemeleri zamana yayın. Let’s Encrypt’te uygun ARI (ACME Renewal Info) yenilemeleri oran limitlerinden muaftır; bunun için istemci desteği ve ARI yenileme koşulları gerekir. Aynı adları içeren her yeni istek bu muafiyeti kazanmaz.

acme.sh içinde --server ile CA seçmek veya varsayılan CA’yı değiştirmek otomatik hata anı geçişi kurmaz. Yedek CA için önceden hesap, uygun doğrulama yöntemi, CAA izni, limitler, istemci güven zinciri ve dağıtım yolu hazırlanıp test edilmelidir. CA değiştirmek bozuk DNS veya challenge yapılandırmasını düzeltmez ve kesintisiz üretim garantisi vermez. acme.sh ile yedekli CA otomasyonu yazımız bu hazırlık adımlarıyla birlikte değerlendirilmelidir.

Kubernetes, K3s ve Konteyner Dünyasında Sertifika Otomasyonu

cert‑manager ve Ingress ile uçtan uca otomasyon

Kubernetes ve K3s kümelerinde cert-manager, sertifika isteğini Kubernetes kaynaklarıyla tanımlamayı sağlar. Ingress kullanımı için temel akış şöyledir:

• ACME hesabını ve HTTP‑01/DNS‑01 çözücüsünü yapılandıran bir Issuer veya ClusterIssuer oluşturun. Issuer yalnızca kendi namespace’i içindeki Certificate kaynaklarınca kullanılabilir; ClusterIssuer küme kapsamındadır.
• İstenen DNS adlarını, issuerRef ve secretName alanlarını içeren bir Certificate oluşturun. Alternatif olarak Ingress üzerindeki uygun issuer annotation’ı ve spec.tls ayarı, ingress-shim’in aynı namespace’te Certificate oluşturmasını sağlar.
• cert-manager doğrulamayı yürütür ve alınan sertifika/özel anahtarı Certificate ile aynı namespace’teki belirtilen Secret’a yazar. Ingress controller, Ingress’in TLS Secret başvurusunu kullanacak şekilde yapılandırılmalıdır; cert-manager genel olarak uygulama pod’larına otomatik sertifika enjekte etmez.
• Yenileme ve anahtar rotasyonunu, tüketen bileşenin yeni Secret içeriğini yüklemesiyle birlikte test edin. Açıkça belirlenen rotationPolicy: Always anahtar rotasyonunu ister; sürüm varsayımına dayanmayın. Sadece başlangıçta okuyan uygulama için reload veya kontrollü restart gerekir.
• Secret erişimini RBAC ile sınırlayın ve saklama sırasında şifrelemeyi yapılandırın; base64 kodlama şifreleme değildir. ClusterIssuer kullanılması Secret’ı bütün namespace’lere dağıtmaz.

Küme mimarisi ve ilgili bileşenleri 3 VPS ile K3s yüksek erişilebilirlik kümesi ve cert‑manager kurulum rehberimiz üzerinden inceleyebilirsiniz. Kurulumda kullanılan cert-manager ve Ingress controller sürümlerinin resmi belgeleriyle kaynak alanlarını, yetkileri ve yenileme davranışını ayrıca doğrulayın.

Geliştirme, staging ve canlı ortam ayrımında otomasyon

Tek küme veya çoklu küme yapılarında, geliştirme (dev), test/staging ve canlı (prod) ortamların sertifika politikalarını da ayrıştırmak gerekiyor:

• Geliştirme: İç CA veya self-signed sertifika kullanılıyorsa güven dağıtımını açıkça tasarlayın; sertifika denetimini kapatmayı çözüm olarak kullanmayın.
• Staging: Let’s Encrypt staging ortamı test içindir; kendisinin de oran limitleri vardır. Sertifikaları normal tarayıcı güven depolarında güvenilmez. Test güven köklerini canlı veya günlük kullanım güven deposuna eklemeyin.
• Canlı: İstemcilerin güvendiği, kullanım amacına uygun CA ve doğrulanmış TLS politikası kullanın. Staging ve canlı hesap/sır/yetkilerini ayırın; aynı güven deposunu varsaymayın.

Ortam ayrımı hata etkisini sınırlar; canlıya geçişte güven zinciri, DNS, ağ erişimi, rate limit ve dağıtım farkları ayrıca test edilmelidir. Geliştirme–staging–canlı yolculuğu rehberimiz bu geçişin uygulama ve altyapı tarafını birlikte ele alır.

mTLS ve servis içi sertifika yönetimi

Servisler arası bağlantılarda mTLS (karşılıklı TLS), iki tarafın sertifikayla kimlik doğrulamasını sağlayabilir. Dış HTTPS sertifikalarından farklı olarak servis kimlikleri ve güven kökleri çoğu zaman iç PKI politikasıyla yönetilir. Tasarım şu işleri kapsayabilir:

• İş yükü kimliğine bağlı kısa ömürlü sertifikaların verilmesi ve dağıtılması.
• Istio gibi service mesh bileşenleriyle sertifika/anahtar rotasyonu; seçilen ürün ve sürümde gerçekten kapsanan trafik yollarının doğrulanması.
• Kök ve ara CA koruması, güven kökü değişimi ve CA arızasından kurtarma planı.
• Kimlik kaldırma ve anahtar ele geçirilmesi için müdahale: ürünün desteklediği iptal/yenileme mekanizmasını ve etkili olma süresini doğrulama, erişim politikasını güncelleme ve olay kaydı.

mTLS kimlik doğrulaması yetkilendirme politikasının yerine geçmez. Örneğin Istio’nun permissive modu hem düz metin hem mTLS kabul eder; yalnızca mesh kurmak zorunlu mTLS sağlamaz. Gereken yollarda strict politika, uygun erişim kuralları ve bypass denetimi uygulanmalıdır. Mesh dışındaki bir veritabanının veya kapsanmayan bağlantıların otomatik korunduğunu varsaymayın.

Gözlemlenebilirlik, Güvenlik Politikaları ve Denetim Boyutu

Sertifika envanteri, bitiş uyarıları ve raporlama

Otomasyon sadece “yenileme çalışıyor mu?” sorusundan ibaret değil. Gerçek dünyada şu soruların da cevabı olmalı:

• Hangi alan adında, hangi CA’dan, ne zaman alınmış sertifikalar var?
• Hangi sertifikalar müdahale için belirlediğiniz eşiklere yaklaşıyor? Örneğin 7, 14 veya 30 gün; eşikleri gerçek sertifika ömrüne ve yenileme penceresine göre seçin.
• Hangi ortamda (dev / staging / prod) hangi TLS sürümü ve cipher seti kullanılıyor?

ACME işlemlerinin loglarını, zamanlayıcı çalışmasını ve dağıtım sonucunu izleyin. Prometheus blackbox exporter gibi bir uç nokta denetimiyle istemciye gerçekten sunulan sertifikayı kontrol edebilir, Grafana/uyarı sisteminde eşik ve alıcı tanımlayabilirsiniz. Yenileme başarılı olsa bile reload veya bir edge’e dağıtım başarısız olabilir. Her hedefi doğru SNI ile test edin; denetimin çalışmaması, log kaybı ve alarm teslimatını da ayrı izleyin. Sırları loglamayın.

Policy‑as‑code ile TLS standartlarını kodlamak

Policy-as-code, seçtiğiniz sertifika ve TLS kurallarını gözden geçirilebilir yapılandırma ve testler halinde tanımlamanızı sağlar. Sertifika üretimi ile sunucunun TLS protokol/şifre takımı ayarları ayrı kontrollerdir:

• İzin verilen CA’lar, ACME hesapları ve üretim sırasında CAA kontrolü.
• CA ve istemci uyumluluğuna uygun anahtar algoritması ve asgari güç; yalnızca ECDSA kullanmayı evrensel zorunluluk saymayın.
• DV/OV/EV kimlik doğrulama sınıfı ve ayrı bir kapsam özelliği olan wildcard/SAN kullanımı.
• RFC 9325 rehberliğiyle SSL ve TLS 1.0/1.1’i kapatma; TLS 1.2 desteği, desteklenen yerde TLS 1.3 tercihleri ve uygun şifre takımları.

CI/CD kontrolü yalnızca kapsadığı yapılandırmayı ve akışları denetler. Elle değiştirilen sunucular, farklı proxy’ler veya başarısız dağıtımlar için canlı uç nokta kontrolleri ve sapma takibi gerekir. PCI DSS gibi bir standarda tabi ortamda hangi kontrollerin uygulanacağını ve kimin kanıt üreteceğini ayrıca belirleyin.

KVKK, GDPR ve PCI DSS ile ilişkisi

Sertifika otomasyonu güvenli aktarımın sürdürülmesine ve yapılan işlemlerin izlenmesine yardımcı olur. KVKK/GDPR veri koruma yükümlülüklerini veya PCI DSS kapsamındaki bütün kontrolleri tek başına karşılamaz. Bu yazı bir uyumluluk değerlendirmesi değildir; ilgili kapsamda şunları eşleştirin:

• Veri akışları, TLS sonlandırma noktaları, sertifika doğrulaması ve gerekli aktarım koruması.
• HTTPS yönlendirmesi, karma içerik, HSTS ve uygulama güvenliği gibi sertifika yenilemesinden ayrı yapılandırmalar.
• Sorumlular, gerekli olay kayıtları, erişim yetkileri ve kontrollerin sürekliliğine ilişkin doğrulama kanıtları.

Geçerli bir sertifika tarayıcı uyarılarının tamamını gidermez ve denetim sonucunu garanti etmez. Hangi teknik ve idari yükümlülüklerin geçerli olduğunu veri akışına, sözleşmelere ve ilgili standart/mevzuata göre değerlendirin.

Hosting Mimarisine Göre SSL Otomasyonu

Paylaşımlı hosting, VPS ve dedicated için önerilen mimariler

Ürün türünden önce sertifika üretimi, yenileme, dağıtım ve arıza müdahalesinin sorumlusunu belirleyin. Şu seçenekler değerlendirilebilir:

• Paylaşımlı hosting: Panelin otomatik sertifika özelliğini, CA’sını, uygun alan adlarını ve zamanlayıcısını doğrulayın. cPanel’in Let’s Encrypt plugin’i ile wildcard için DNS’in yerel sunucuda veya DNS kümesinde olması gerekir; üçüncü taraf DNS bu plugin akışında desteklenmez. Diğer panel/entegrasyonların koşulları farklı olabilir.
• VPS: Certbot/acme.sh veya ters proxy’nin entegre ACME işlevinden birini kontrollü şekilde seçin. Aynı sertifika için çakışan üreticiler çalıştırmayın. Cron/systemd zamanlamasını, gerekli DNS API yetkilerini ve başarılı yenileme sonrası deploy/reload adımını doğrulayın.
• Dedicated / colocation: Merkezi yönetim ya da planlı dağıtık üretim seçimini erişim sınırlarına göre yapın. Merkezi sistemde yüksek erişilebilirlik, kalıcı durum, kilitleme, kurtarma ve bütün edge’lere korumalı anahtar dağıtımı gerekir; tek bileşen yeni bir arıza noktası oluşturabilir.

Sertifika herkese açık olabilir; özel anahtar, DNS API anahtarı ve ACME hesap anahtarı sırdır. Bunları kaynak koduna veya kontrolsüz CI çıktısına koymayın. Sınırlı erişimli secret deposundan kimliği doğrulanmış, şifreli kanalla dağıtın. Sertifika/anahtar eşleşmesini, dosya izinlerini ve yapılandırmayı kontrol edip atomik değişim ve uygun reload uygulayın; sonra her uçta güven zincirini ve sunulan sertifikayı doğrulayın. Kubernetes Secret adı tek başına güvenlik garantisi değildir.

Aşamalı geçiş: Örnek 30 günlük çalışma planı

Aşağıdaki süreler örnektir; ekip kapasitesi ve gerçek yenileme döngüsü takvimi belirler. Otuz günün dolması işi tamamlanmış saymak için yeterli değildir:

1. Envanter (Gün 1–3): Alan adları, SAN kapsamı, CA, bitiş tarihi, TLS uçları, özel anahtar konumları ve sorumluları listeleyin.
2. Pilot (Gün 4–7): Düşük etkili alan adında staging doğrulaması yapın. Sertifika güveni ve canlı dağıtımın ayrıca doğrulanacağını kaydedin.
3. DNS ve CA hazırlığı (Gün 8–12): DNS API/delegasyon yetkisini, bütün yetkili DNS yanıtlarını, CAA’yı ve rate limit/tekrar politikasını test edin.
4. Dağıtım ve geri dönüş (Gün 13–18): Certbot deploy-hook veya acme.sh install-cert/reloadcmd akışını uygun istemciyle kurun. Certbot dry-run varsayılan olarak deploy-hook çalıştırmaz ve normalde staging kullanır; özel –server ayarı bu davranışı değiştirebilir. Test başarısını canlı dağıtım kanıtı saymayın. Geri dönüşte yalnızca geçerli, iptal edilmemiş ve anahtarı ele geçirilmemiş sertifikaları kullanın; mümkünse güncel sertifikayı koruyup yapılandırmayı geri alın.
5. Gözlem ve arıza provası (Gün 19–24): Pilot sırasında izlemeyi etkin tutun; DNS hatası, durdurulmuş zamanlayıcı, başarısız reload ve alarm alıcısını güvenli test ortamında sınayın.
6. Kademeli yayılım (Gün 25–30 ve sonrası): Ancak doğrulama, yenileme, bütün uçlara dağıtım ve müdahale kanıtı varsa kapsamı büyütün. Gerçek yenileme döngüsünü gözleyin; acil müdahale runbook’unu ve sorumlusunu koruyun.

DCHost dahil bir sağlayıcının paylaşımlı hosting, VPS, dedicated veya colocation hizmetini değerlendirirken panel desteğini, DNS yetkilerini, yönetim kapsamını ve arıza sorumluluğunu yazılı netleştirin. Planın yalnızca sertifika üretimini mi, dağıtım ve izlemesini de mi kapsadığını kontrol edin.

Uygulamaya Başlamadan Önce Son Kontroller

ACME, DNS‑01, wildcard/SAN, müşteri alan adı yönetimi, cert-manager ve mTLS farklı ihtiyaçları karşılar. Doğru mimari; alan adı yetkisini, CA politikasını, anahtar korumasını, dağıtımı ve bağımsız uç nokta denetimini birlikte ele alır.

SSL sertifika otomasyonu için tamamlanma ölçütünüz yalnızca “sertifika alındı” olmamalıdır. Şunları kanıtlayın:

• Yenileme zamanında tetikleniyor ve hata durumunda sorumlu kişiye ulaşan alarm üretiyor.
• Her hedef uç, doğru alan adlarını kapsayan geçerli ve güvenilir sertifikayı sunuyor.
• Sırlar korunuyor; kaynak yapılandırması ile canlı TLS davranışı birlikte kontrol ediliyor.
• Geliştirme, staging ve canlı ortamlarının güven/yetki sınırları ayrı; geri dönüş ve olay müdahale adımları belgeli.

İlk adım olarak bir alan adı seçin ve üretimden dağıtıma bütün akışı ölçün. Pilotun doğrulama kayıtlarını ve müdahale planını tamamladıktan sonra diğer alan adlarına geçin. Başarılı otomasyon, düzenli yenilemenin yanında hatanın fark edilmesini ve giderilmesini de kapsar.

Birincil Teknik Kaynaklar

• RFC 8555 — ACME
• CA/B Forum — TLS Baseline Requirements
• Let’s Encrypt — Challenge Types
• Let’s Encrypt — Rate Limits
• cert-manager — Ingress
• cert-manager — Certificate
• Certbot — Using Certbot
• acme.sh — Server Selection