Onlarca Alan Adı İçin SSL Sertifika Süre Sonu İzleme ve Otomatik Yenileme Stratejisi

Neden Onlarca Alan Adında SSL Süre Sonu Yönetimi Kritik?

Tek bir web sitesinin SSL sertifikası bile bittiğinde SEO kaybı, tarayıcıda "Güvenli değil" uyarıları, ödeme sayfalarında terkler ve itibar zedelenmesi yaşanabiliyor. Bir de işin içine ajans olarak yönettiğiniz 30+ müşteri alan adı, çok dilli kurumsal siteler, SaaS uygulamanızın müşteri alt alan adları, staging ortamları ve API alt alanları girdiğinde bu risk çarpan etkisiyle büyüyor. Manuel Excel listeleri, takvim hatırlatıcıları veya tek tek panel kontrolü bir noktadan sonra sürdürülemez hale geliyor.

Bu yazıda DCHost tarafında sıkça gördüğümüz senaryolardan yola çıkarak, onlarca alan adı için SSL sertifika süre sonu izleme ve tam otomatik yenileme stratejisini uçtan uca ele alacağız. Amaç; hangi sertifikanın nerede kullanıldığını bilmek, süre sonu uyarılarını haftalar öncesinden almak ve yenilemenin arka planda sessizce gerçekleşmesini sağlamak. ACME tabanlı otomasyon, wildcard / SAN sertifika tercihleri, Let’s Encrypt rate limit ve CAA stratejileri, SaaS’te özel alan adları ve operasyonel sorumluluk paylaşımı gibi konuları; gerçekçi, uygulanabilir bir çerçeveyle toparlayacağız.

İlk Adım: SSL Envanterini Çıkarmadan Strateji Kurulmaz

Sağlam bir SSL otomasyon mimarisi için önce "nerede, hangi sertifika var?" sorusuna yanıt vermek gerekiyor. Özellikle ajanslar ve SaaS sağlayıcıları için bu envanter, teknik borcun en görünmez ama en kritik parçalarından biri.

Hangi alan adlarını ve uç noktaları kapsamalısınız?

Sadece ana alan adlarına bakmak yeterli değil. Aşağıdaki grupları mutlaka listeleyin:

• Canlı siteler: kurumsal siteler, e-ticaret, blog, landing sayfaları
• API ve backend alt alanları: api.example.com, backend.example.com, auth.example.com gibi
• Staging ve test ortamları: staging.example.com, test.example.com
• SaaS müşteri alanları: customer1.saas.com, ya da müşteri özel alan adları (customer1.com)
• Yönetim panelleri ve iç araçlar: panel.example.com, monitoring.example.com
• CDN / WAF üzerinden terminasyon yapılan alanlar: SSL’in DCHost sunucusunda mı, yoksa CDN/WAF noktasında mı bittiğini netleştirin.

Birçok ekipte sorun şuradan çıkıyor: Bir alan adı hem CDN üzerinde, hem origin sunucuda, hem de staging sunucuda farklı sertifikalarla sonlandırılıyor. Süre sonunu sadece bir noktadan izlemek bu yüzden yeterli olmuyor.

Envanteri nasıl oluşturmalı?

Pratik bir başlangıç için şu adımı öneriyoruz:

1. Tüm alan adlarını DNS kayıtlarınızdan ve domain panelinizden dışa aktarın.
2. Her alan adı ve alt alan için "HTTPS sonlandırma noktası"nı (hangi sunucu veya hizmet) not edin.
3. Sertifikanın tek alan, wildcard mı, SAN (multi-domain) mi olduğunu ve nereden alındığını ekleyin.
4. Sorumlu ekip / kişi ve kritik seviyesini (ödeme sayfası / admin / düşük önemde) belirtin.

Bu envanter, birazdan anlatacağımız otomatik izleme ve yenileme araçlarının yapı taşını oluşturacak.

Doğru Sertifika Tipiyle Karmaşıklığı Azaltmak

Onlarca alanı yönetirken asıl sorulardan biri şu: "Her alan için ayrı sertifika mı, yoksa wildcard / SAN ile gruplama mı?" Yanlış seçim yaptığınızda hem yönetim karmaşıklaşır hem de Let’s Encrypt gibi CA’lerin oran limitlerine çarpmaya başlarsınız.

Tek alan, wildcard ve SAN sertifika farkları

• Tek alan sertifikalar: www.example.com gibi belirli bir FQDN’i kapsar. Yönetmesi basit; ama 30–40 alanınız olduğunda sayı hızla artar.
• Wildcard (*.example.com): Tüm birincil seviye alt alanları kapsar (www, api, panel vb.). Genelde DNS-01 doğrulaması gerektirir. Çok sayıda alt alan kullanan projelerde hayat kurtarıcıdır.
• SAN (Multi-Domain) sertifikalar: Bir sertifikada birden fazla tamamen farklı alan / alt alan tanımlarsınız. Ajans yapılarında "tek sunucuda barınan birkaç küçük site" için mantıklı olabilir.

Detaylı artı/eksi analizi için hazırladığımız Wildcard SSL ve SAN sertifikalar arasında seçim yaparken dikkat edilmesi gerekenler rehberine göz atmanızda fayda var.

Hangi durumda hangisini tercih etmelisiniz?

• Çok alt alanlı tek marka: Kurumsal siteniz, API’ler, panel, staging vb. hepsi example.com altında ise, wildcard + bazı özel tek alan sertifikaları pratik olur.
• Ajans yapısı: Farklı müşterilere ait siteler aynı sunucudaysa, düşük trafikli birkaç alanı tek bir SAN sertifikada gruplayıp; büyük projelere ayrı sertifika vermek mantıklı.
• SaaS + müşteri alan adları: Müşteriler kendi alan adlarını sisteme bağlarsa, ACME + DNS-01 otomasyonu ile tek alan DV sertifikaları üretip otomatik yönetmek daha esnek olur.

DCHost tarafında çok kiracılı yapılarda ACME/DNS-01 tabanlı otomasyona dair detayları, ACME tabanlı SSL sertifika otomasyonu inovasyonları yazımızda adım adım anlattık. Bu makale de o resmin "envanter, izleme ve operasyon" tarafını tamamlıyor.

Süre Sonu İzleme Mimarisi: Sertifika Durumunu Nasıl Okuyacağız?

Envanteri çıkardık, hangi alanları nasıl gruplayacağımız belli. Şimdi soru şu: Sertifika ne zaman bitecek, bunu sistematik ve otomatik olarak nasıl takip ederiz?

1) Dışarıdan tarayıcı gözüyle kontrol

En basit yöntem, alan adının HTTPS portuna bağlanıp sertifikayı okumaktır. Komut satırında şu tarz bir komutla kalan günü çekebilirsiniz:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -enddate

Bu çıktıyı parse ederek "kalan gün" hesabı yapmak ve belirli bir eşik altına düştüğünde e-posta veya Slack uyarısı göndermek mümkün. Aynı mantıkla küçük bir script yazıp tüm alan adlarınız üzerinde döndürebilir, cron ile günde bir kez çalıştırabilirsiniz.

2) Sunucu içinden sertifika deposunu izlemek

Özellikle DCHost üzerinde VPS veya dedicated sunucularda Certbot, acme.sh veya panel tabanlı AutoSSL kullanıyorsanız, sertifika dosyalarınız belirli dizinlerde depolanır. Bu dizinleri okuyup son kullanma tarihini çeken script’ler yazabilirsiniz. Böylece:

• Hem canlıda kullanılan sertifikayı hem de henüz reload edilmemiş yeni sertifikayı izleyebilirsiniz.
• Yenileme sonrası web sunucusunun (Nginx/Apache) gerçekten reload edildiğini doğrulayabilirsiniz.

3) Merkezi izleme sistemine metrik göndermek

Orta ve büyük yapılarda "kalan gün" bilgisini sadece loglamak yetmez; grafik ve alarm üretmek de isteriz. DCHost tarafında sıkça gördüğümüz pratik yaklaşım:

• Her VPS’te küçük bir exporter ile "ssl_days_remaining" benzeri bir metrik üretmek,
• Prometheus / Netdata / benzeri sistemlere bu metrikleri aktarmak,
• Belirli eşikler için alarm tanımlamak (örneğin 30, 14 ve 7 gün kala).

Uptime ve alarm tarafını yapılandırırken, web sitesi uptime izleme ve alarm kurma rehberi yazımızda anlattığımız genel alarm pratiklerini SSL metriklerine de uygulayabilirsiniz.

4) Tarayıcı hatalarını sonradan değil, önceden görmek

Gerçek hayatta birçok ekip SSL problemini, ancak tarayıcıda kırmızı uyarı çıktıktan sonra fark ediyor. Oysa tarayıcıda görülen SSL sertifika hatalarını analiz etmek ve bunların loglanmasını sağlamak, gizli kalmış alan adlarını da ortaya çıkarır. Örneğin sadece eski bir alt alan veya test ortamı unutulmuş olabilir. Loglardan gelen "expired certificate" uyarılarını, envanterinizi güncellemek için sinyal gibi kullanın.

ACME Tabanlı Otomatik Yenileme: Temel Prensipler

İzleme, sadece "sertifika bitiyor" uyarısını verir. Asıl işi çözen, ACME tabanlı otomatik yenileme sürecidir. Doğru kurgulandığında, Let’s Encrypt veya benzeri CA’lerden alınan DV sertifikalarınız; elle müdahale olmadan yıllarca sorunsuz dönebilir.

ACME challenge türlerini doğru seçmek

ACME protokolü, alan adınızın size ait olduğunu kanıtlamak için üç temel challenge sunar:

• HTTP-01: Web sunucunuzda belirli bir URL altında dosya servis edersiniz. Klasik web siteleri için en çok kullanılan yöntemdir.
• DNS-01: DNS’e belirli bir TXT kaydı eklersiniz. Wildcard ve SaaS senaryolarında vazgeçilmezdir.
• TLS-ALPN-01: Özellikle reverse proxy ve edge terminasyon senaryolarında iş görür.

Hangi challenge türünü ne zaman kullanmanız gerektiğini daha detaylı anlamak için, ACME challenge türleri (HTTP-01, DNS-01, TLS-ALPN-01) rehberimize mutlaka göz atın.

Paylaşımlı hosting ve kontrol panellerinde otomasyon

DCHost üzerindeki paylaşımlı hosting, reseller ve bazı VPS panellerinde (cPanel/DirectAdmin vb.) AutoSSL benzeri mekanizmalar doğrudan entegre gelir. Bu sistemler:

• Alan adınız için HTTP-01 challenge dosyasını otomatik üretir,
• Let’s Encrypt veya benzeri CA ile konuşup sertifikayı alır,
• Sertifikayı ilgili vHost’a bağlar ve web sunucusunu reload eder,
• Süre sonu yaklaştığında tüm bu süreci tekrarlayarak yenilemeyi gerçekleştirir.

Bu ortamlarda dikkat etmeniz gereken şey, DNS kayıtlarınızın doğru şekilde DCHost sunucularına işaret etmesi ve alan adının gerçekten aktif bir site barındırmasıdır. Detaylı kurulum ve otomatik yenileme adımlarını, cPanel ve DirectAdmin’de Let’s Encrypt ile otomatik yenileme rehberi yazımızda adım adım bulabilirsiniz.

VPS / Dedicated sunucularda ACME istemcileri

Kendi Nginx/Apache kurulumunuz olan VPS veya dedicated sunucularda tipik akış şöyle:

1. Sunucuya Certbot, acme.sh veya benzeri bir ACME istemcisi kurulur.
2. Her alan adı / alt alan için "certificate profile" tanımlanır (hangi challenge, hangi web root, hangi DNS API vs.).
3. ACME istemcisi için systemd timer veya cron job ile günlük/haftalık yenileme denemeleri planlanır.
4. Yenileme başarılı olduğunda web sunucusunu reload eden "deploy hook" script’i tetiklenir.

Bu yapıyı onlarca alan adı için ölçeklerken kritik noktalar: yapılandırmanın versiyon kontrolünde olması, staging ortamında test ediliyor olması ve hangi alanın hangi profile bağlı olduğunun dokümante edilmesidir.

SaaS ve özel müşteri alan adlarında otomatik SSL

Eğer çok kiracılı SaaS bir uygulamada müşterilerin kendi alan adlarını sisteme tanımlamasına izin veriyorsanız, manuel sertifika yönetimi imkansız hale gelir. Burada yapılması gereken:

• Uygulama tarafında bir "domain onay" akışı kurgulamak (CNAME veya TXT ile),
• Onaylanan her alan için ACME/DNS-01 tabanlı otomatik sertifika alma sürecini tetiklemek,
• Sertifikaları reverse proxy (Nginx/Traefik) katmanında dinamik olarak yüklemek,
• Yenilemeleri tamamen arka plana atmak ve müşteri tarafına sadece durum bilgisini yansıtmak.

Bu konuyu, pratik örneklerle SaaS’te özel alan adları ve otomatik SSL rehberimizde detaylı anlattık. Buradaki önerileri, bu yazıdaki izleme ve operasyon pratikleriyle birleştirerek tam bir çözüm elde edebilirsiniz.

Let’s Encrypt Rate Limit ve CAA Stratejisi: Onlarca Alanı Kilitlemeden Yönetmek

Onlarca alan adıyla çalışırken sık gördüğümüz iki tuzak: Let’s Encrypt oran limitlerine çarpmak ve yanlış yapılandırılmış CAA kayıtları yüzünden sertifika alamamak.

Rate limit’lere takılmamak için gruplama

Let’s Encrypt, hem tek alan için hem de toplamda sertifika sayısı açısından belirli limitler uygular. Bu limitlere takılmamak için:

• Aynı projeye ait alt alanları mümkün olduğunca wildcard altında toplayın.
• Küçük ve düşük önemdeki siteleri, makul sınırlar içinde SAN sertifikalarda gruplayın.
• Gereksiz sertifika yenilemeyi azaltın; örneğin staging ortamını tek, uzun ömürlü bir sertifikayla yönetebilirsiniz.

Bu konuda pratik örnekler ve hesaplamalarla dolu ayrıntılı bir rehberi, Let’s Encrypt rate limit’lerine takılmadan çok alan adında SSL yönetmek yazımızda paylaştık.

CAA kayıtlarıyla hangi CA’nin sertifika verebileceğini kontrol etmek

CAA (Certification Authority Authorization) kayıtları, "Bu alan adına sadece şu CA sertifika verebilir" demenin DNS yoludur. Güvenlik açısından faydalıdır; ancak yanlış tanımlanırsa ACME istemcisinin sertifika almasını engeller. Özellikle:

• Farklı CA’ler kullanıyorsanız ("kurumsal" sertifikalar + Let’s Encrypt gibi),
• Alt alanları farklı CA’lere dağıtmak istiyorsanız,

CAA kayıtlarınızı dikkatle planlamanız gerekir. Bunun nasıl yapılacağını ve çoklu-CA senaryolarını, CAA kayıtları derinlemesine rehberimizde adım adım işledik.

Operasyonel Pratikler: Etiketleme, Sorumluluk ve Runbook’lar

Teknik otomasyon kadar önemli bir diğer katman da "insan ve süreç" tarafı. Onlarca alan adını yöneten ekiplerde tipik olarak şu sorunlara rastlıyoruz:

• Hangi alan adından kim sorumlu, belli değil.
• Hangi sertifikanın hangi sunucuda sona erdiğini kimse takip etmiyor.
• Yenileme başarısız olduğunda ne yapılacağına dair adım adım runbook yok.

Etiketleme ve sahiplik

DCHost’ta gördüğümüz iyi örneklerde, her alan adı için şu bilgiler mutlaka tutuluyor:

• Sorumlu ekip / kişi: Örneğin "SEO ekibi", "Backend ekibi", "Ajans X".
• Kritiklik seviyesi: "Ödeme sayfası", "Kurumsal broşür site", "İç araç" gibi.
• Barındırma yeri: "DCHost paylaşımlı hosting", "DCHost VPS", "DCHost colocation" vb.
• SSL yönetim modu: "Panel AutoSSL", "acme.sh + DNS-01", "Kurumsal OV sertifika" gibi.

Bu etiketler, izleme ve alarm sistemlerindeki uyarıları doğru kişilere yönlendirmeyi; aynı zamanda kapasite ve maliyet planlamasını kolaylaştırır.

Runbook: Yenileme başarısız olursa ne yapılacak?

Otomasyonun da hata yapabileceğini kabul etmek gerekiyor. İyi bir runbook’ta şu adımlar olur:

1. Alarm geldiğinde ilk bakılacak log dosyaları ve komutlar (ACME istemcisi logu, web sunucusu hataları vb.).
2. DNS hataları için kontrol listesi (yanlış CNAME, eksik TXT kaydı, yanlış IP vb.).
3. Geçici olarak eski sertifikaya dönme veya alternatif bir CA’den sertifika çekme senaryoları.
4. Gerekirse DCHost destek ekibine iletilecek bilgilerin listesi (alan adı, IP, log çıktıları vb.).

Bu runbook’u yılda en az bir kere test etmek, felaket kurtarma provası gibidir; "sertifika bittiğinde panik yapmamak" için işe çok yarar.

DCHost Üzerinde Örnek Çok Alan Adlı SSL Otomasyon Senaryosu

Somutlaştırmak için sık rastladığımız bir senaryoyu düşünelim: 25 müşterili bir dijital ajanssınız. Müşterilerin bir kısmı paylaşımlı hosting paketlerinde, bir kısmı DCHost VPS üzerinde, bazıları da SaaS uygulamanıza kendi alan adlarını bağlamış durumda.

1. Adım: Envanter ve segmentasyon

• Tüm müşteri alan adlarını ve alt alanları bir tabloya döküyorsunuz.
• Paylaşımlı hosting’te olanlar için "Panel AutoSSL" etiketi veriyorsunuz.
• VPS’te barınan siteleri projeye göre gruplandırıp, her proje için wildcard mı yoksa ayrı sertifikalar mı kullanacağınıza karar veriyorsunuz.
• SaaS uygulamanıza bağlı müşteri alan adlarını ayrı bir sekmede topluyorsunuz.

2. Adım: ACME otomasyonu kurmak

• Paylaşımlı hosting hesaplarında DCHost panelindeki Let’s Encrypt / AutoSSL özelliklerini aktif edip, yenileme loglarını düzenli kontrol ediyorsunuz.
• VPS üzerinde acme.sh veya Certbot ile:
• www.example1.com, www.example2.com gibi alanlar için HTTP-01 tabanlı profil,
• *.example3.com gibi alt alanlar için DNS API kullanarak DNS-01 tabanlı profil oluşturuyorsunuz.
• SaaS tarafında, yeni müşteri alanı onaylandığında otomatik tetiklenen "DNS-01 ile sertifika üret" akışını uygulama koduna entegre ediyorsunuz.

3. Adım: İzleme ve alarm katmanını eklemek

• Her VPS’e basit bir script koyup, sistemd timer ile günlük "kalan gün" metriklerini üretiyorsunuz.
• Bu metrikleri merkezi izleme sistemine veya en azından günlük raporlara aktarıyorsunuz.
• Paylaşımlı hosting hesaplarında panelin ürettiği sertifika uyarılarını ajans genel e-posta adresine düşecek şekilde yapılandırıyorsunuz.

4. Adım: Let’s Encrypt rate limit ve CAA’yi planlamak

Şu stratejiyi benimsiyorsunuz:

• Aynı marka altında çok sayıda alt alan varsa wildcard sertifika kullanıp tek sertifika altında topluyorsunuz.
• Küçük müşteri sitelerini mantıklı gruplar halinde SAN sertifikalarda birleştiriyorsunuz.
• CAA kayıtlarında, kritik markalar için hem Let’s Encrypt hem de kurumsal CA’nizi yetkili kılıyorsunuz; böylece gerektiğinde alternatif CA’den hızlı sertifika çekebiliyorsunuz.

Tüm bu bileşenleri kurduktan sonra, SSL tarafındaki operasyon yükünüz dramatik şekilde düşer. Ajans olarak odağınızı altyapı krizi çözmekten çıkarıp, müşteriye değer üreten işlere kaydırabilirsiniz.

Sonuç: SSL Süre Sonu Krizini Sistematik Olarak Ortadan Kaldırmak

Onlarca alan adıyla çalışırken tek tek sertifika hatırlamak imkansız. Gerçekçi çözüm; alan adlarınızı kategorize eden bir envanter, kalan günleri net görebildiğiniz bir izleme katmanı ve eksiksiz çalışan bir ACME tabanlı otomatik yenileme akışını bir arada kurmak. Üstüne Let’s Encrypt rate limit, CAA kayıtları ve operasyonel runbook’ları eklediğinizde, SSL sertifikaları artık "son dakika krizinin" değil, "arka planda sessizce işleyen" bir bileşeninize dönüşüyor.

DCHost olarak hem paylaşımlı hosting hem de VPS / dedicated ve colocation altyapılarında bu modelin farklı varyasyonlarını her gün sahada görüyoruz. İsterseniz basit bir AutoSSL kurulumu, isterseniz onlarca alanı kapsayan ACME/DNS-01 otomasyonu olsun; mimariyi birlikte planlayabilir, mevcut SSL envanterinizi gözden geçirip adım adım iyileştirebiliriz. Bir sonraki SSL alarmının gecenin bir yarısında değil, haftalar öncesinden sakin bir rapor olarak önünüze düşmesini istiyorsanız; önce envanteri çıkarın, ardından bu yazıdaki adımları projelerinize uyarlayın. Takıldığınız yerde DCHost ekibi yanınızda.