Let’s Encrypt kurumsal için yeterli mi? Kriterler ve doğru kurulum

Kurumsal sitelerde SSL yalnızca "HTTPS olsun" konusu değildir. Tarayıcı uyarıları, kesinti riskleri, doğrulama seviyesi, otomasyonun güvenilirliği ve e-ticaret uyumu gibi başlıklar birlikte değerlendirilir. Bu yazıda Let’s Encrypt’in kurumsal ihtiyaçlarda ne kadar yeterli olduğunu net kriterlerle ölçüyor; doğru kurulum, izleme ve alternatif stratejiyi karşılaştırmalı biçimde anlatıyoruz.

Let’s Encrypt’in kurumsalda güçlü olduğu noktalar

Let’s Encrypt (ACME tabanlı) ücretsiz sertifika sağlar ve otomasyonla yenileme süreci yönetilebilir. Kurumsal tarafta en çok iş çıkaran faydalar şunlardır:

• Sertifika yenileme otomasyonu: Sertifikalar genelde 90 gün geçerlidir; ACME akışı ile düzenli yenileme yapılır. Doğru kurulumla yenileme operasyonel yükü düşürür.
• Hızlı devreye alma: Tek domain ya da alt domain’lerde (wildcard dışı) hızla sertifika alınabilir.
• Güvenlik güncellemeleri: Let’s Encrypt, tarayıcıların güvendiği kökler (trusted root programı) üzerinden çalışır. Bu sayede çoğu modern tarayıcıda uyarı problemi yaşanmaz.
• Maliyet kontrolü: Kurumsal ölçekte sertifika yenileme bütçesi; çoklu domain, staging/prod ve farklı ortamlar için hızla büyür. Let’s Encrypt burada belirgin avantaj sağlar.

Kritik nokta: Kurumsal yeterlilik, "ücretsiz olması" ile değil; doğrulama yöntemi, otomasyonun denetlenmesi ve operasyonel tasarım ile belirlenir.

Kurumsal için doğrulama seviyesi ne anlama gelir?\nLet’s Encrypt sertifikaları genellikle Domain Validation (DV) seviyesindedir. Bu, alan adının kontrol edildiğinin kanıtlandığı anlamına gelir. Kurumsal tarafta bu durum iki açıdan değerlendirilir:

1. Kullanıcı güveni: EV/OV (Extended Validation / Organization Validation) seviyelerindeki gibi şirket bilgisi tarayıcı çubuğunda her zaman görünmez. Bu, bazı sektörlerde karar vericinin talep ettiği görsel güven sinyali olabilir.
2. Uygunluk ve risk: DV sertifika, modern tarayıcı ekosisteminde güvenli bağlantı için yeterlidir. Ancak marka güveni ve mevzuat/danışman beklentileri EV/OV isteyebilir.

Kurumsal için yeterli olup olmadığını belirleyen 8 kriter

Aşağıdaki liste, NetKıyas’ta karşılaşılan kurumsal taleplerin pratik bir kontrolüdür. Her maddeye evet/hayır yanıtı verip toplam resme karar verin.

1) Sertifika türü: single, SAN, wildcard ihtiyacınız var mı?

• Tek domain / çoklu alt domain (wildcard yok): Let’s Encrypt çoğu kurulumda yeterlidir.
• Wildcard (*.example.com): Let’s Encrypt wildcard için DNS-01 doğrulama gerekir. Bu yöntem çalışır; ancak DNS tarafında otomasyon ve yetki yönetimi ister.
• Yoğun SAN kullanımı: Kurumsal ortamda çok sayıda domain tek sertifikada talep ediliyorsa, ACME tarafında planlama gerekir (performans/limitler, yenileme zamanlaması).

2) Otomasyonun nerede çalışacağı (webroot vs DNS-01)

Let’s Encrypt otomasyonu şu yollarla çalışır: - HTTP-01 (webroot): 80 portu üzerinden doğrulama yapılır. - TLS-ALPN-01: 443 tarafında özel doğrulama yaklaşımı. - DNS-01 (wildcard’da zorunlu): DNS kaydı oluşturup doğrulama yapılır.

Kurumsal yeterlilik için temel soru: Doğrulama mekanizması sizin altyapınızda her zaman kesintisiz çalışıyor mu?

3) Yenileme başarısız olduğunda planınız var mı?

90 gün aralık mantığıyla, yenileme başarısız olursa takvimsel olarak geçerlilik bitimi yaklaşır. Kurumsal tasarımda şunlar gerekir: - Yenileme loglarının izlenmesi - Sertifika son kullanma (expiry) durumunun alarmı - Otomasyonun tek bir noktaya (tek sunucu/tek pipeline) bağımlı olmaması

4) Birden fazla ortam (prod, staging, test) var mı?

Kurumsal projelerde staging/prod ayrımı yaygındır. Let’s Encrypt, staging ortamında da kullanılabilir; fakat şu hataya düşmeyin: - staging’de prod gibi log/alert kullanılmazsa, prod yenilemelerini fark etmeyebilirsiniz.

5) Revocation ve olay yönetimi (incident response)

Sertifika özel anahtar (private key) sızması veya yanlış CA/yanlış kayıt gibi durumlarda revocation gerekebilir. Let’s Encrypt’te bu süreç tanımlıdır; kurumsal tarafta sizden beklenen şey: - private key saklama biçimi - anahtar rotasyonu prosedürü - revocation sonrası yeni sertifika dağıtım planı

6) E-ticaret ve tarayıcı uyumu için güven değil, performans da kritik

SSL doğru olsa bile; kurumsal ölçekte CDN, WAF ve load balancer davranışları TLS handshake gecikmesi oluşturabilir. Burada Let’s Encrypt’i "sertifika" olarak değil; TLS konfigürasyonu olarak düşünmelisiniz.

• Eski TLS sürümlerini kapatma
• Doğru cipher suite
• HSTS (HTTP Strict Transport Security) planı

7) Kontrol paneli entegrasyonu (Plesk/cPanel gibi)

Bazı kurumsal ekipler, manuel komut yerine kontrol paneli otomasyonuna güvenir. Let’s Encrypt çoğu modern kontrol panelinde entegre çalışır. Ancak entegrasyonun: - yenileme sıklığı - alarm üretip üretmediği - wildcard desteği

konuları netleştirilmelidir.

8) “Kurumsal görünürlük” beklentisi (OV/EV talebi)

Marka güveni veya danışmanlık/ihale şartnamesi, DV sertifikaları yerine OV/EV isteyebilir. Bu durumda Let’s Encrypt teknik olarak yeterli olsa bile organizasyonel gereksinimi karşılamayabilir.

Let’s Encrypt vs ücretli kurumsal SSL: pratik kıyas

Aşağıdaki tablo, kurumsal karar verirken kullanılan tipik farkları özetler. Buradaki "uygunluk" teknik + operasyonel toplamdır.

Kurumsal kurulumda doğru yaklaşım: “Tek komut” değil, izleme planı

Let’s Encrypt’i kurumsal için doğru yapan şey; ACME’yi doğru şekilde kurmak + yenileme/dağıtım akışını denetlemektir.

Tek sunucu yerine yedekli dağıtım modeli

Kurumsal sitede sertifika dağıtımı tek sunucuya bağlıysa risk artar. Uygulanabilir yaklaşımlar: - Load balancer/Reverse proxy üzerinde TLS sonlandırma yapıyorsanız, sertifika güncelleme işlemini tüm düğümlerde tutarlı hale getirin. - Birden fazla web node varsa, sertifika dosyalarının senkronizasyonunu prosedürleştirin.

Sertifika yenilemesini alarm ile izleyin

Kurumsal izleme için pratik hedef: - Sertifika bitimine 30 gün kala uyarı - 14 gün kala kritik uyarı - Yenileme komutu/log çıktısında hata yakalama

Bu amaçla kontrol paneli/agent/monitoring üzerinden "expiry date" takibi yapılmalıdır.

Staging → Prod akışı: hatayı büyümeden yakalayın

Aynı domain üzerinde yanlış DNS/yanlış challenge ayarları birden fazla denemeye yol açabilir. Kurumsal süreçte önerilen adımlar: 1. Staging subdomain veya test domain üzerinde ACME doğrulama testi 2. Prod’de aynı DNS/HTTP yönlendirme mantığını doğrulama 3. Yenileme başarısını bir döngüde ölçme

Sık görülen kurumsal hatalar ve net çözümler

Hata 1: 80/443 yönlendirme firewall’da bloklu

HTTP-01 doğrulama kullanıyorsanız 80 portu erişilemezse yenileme başarısız olur. Çözüm: - 80 -> ilgili reverse proxy/web entry point yönlendirmesi doğrulanmalı - firewall kuralı ile country/IP bazlı bloklar kontrol edilmeli

Hata 2: DNS-01 için otomasyon yetkisiz ya da yanlış provider

Wildcard için DNS-01 kullanılan senaryolarda, DNS sağlayıcısında API yetkileri yanlışsa kayıt oluşturma başarısız olur. Çözüm: - DNS provider API token yetkileri (read/write) doğrulanmalı - API limitleri ve rate konusunda test yapılmalı

Hata 3: Kontrol paneli ile manuel işlem çakışıyor

Panel otomatik yenileme yaparken aynı anda manuel değişiklik yaparsanız konfigürasyon bozulabilir. Çözüm: - “tek yönetim noktası” belirleyin (ya panel ya ACME client) - Jenkins/GitLab pipeline varsa sertifika aşamasını kilitleyin

Hata 4: Sertifika çalışıyor ama TLS ayarları zayıf

Kurumsal güven sadece sertifikayla bitmez. Çözüm: - Sunucuda TLS 1.0/1.1 kapatılmalı - modern ciphers kullanılmalı - HSTS ve redirect politikası kademeli uygulanmalı

Peki sonuçta: Let’s Encrypt kurumsal için yeterli mi?

Kurumsal yeterlilik, "evet/hayır" yerine şu şekilde netleşir:

• Let’s Encrypt yeterlidir: DV kabul ediliyorsa, wildcard ihtiyacınız varsa DNS-01 otomasyonunuz güvenilir ise, yenileme izleme ve olay yönetimi kurguladığınız sürece.
• Let’s Encrypt yeterli değildir (veya gereksinimi tam karşılamaz): EV/OV şartnamesi varsa, sertifika yenileme otomasyonunu izleme/alert ile denetleyemiyorsanız, DNS-01 otomasyonunu kurumsal standartta yönetemiyorsanız veya tek sunucu bağımlı bir dağıtım modeliniz varsa.

Aksiyon önerisi: 30 dakikalık karar testi

Bu yazıdan sonra hemen yapılacak en somut kontrol şudur:

1. Domain(ler)iniz için sertifika türünü belirleyin: single mı wildcard mı?
2. Doğrulama yöntemini sabitleyin: HTTP-01 mi DNS-01 mi?
3. Yenileme başarısızlığında alarm planını yazın: bitiş tarihi + log hata yakalama.
4. “Marka/ihale” gereksinimini kontrol edin: DV kabul ediliyor mu?

Bu 4 maddeden herhangi biri net değilse, Let’s Encrypt yerine ücretli OV/EV ve/veya daha yönetilen bir sertifika operasyonu değerlendirilmelidir. Net gereksinimlerle eşleşen plan yapıldığında Let’s Encrypt, kurumsal TLS ihtiyacını maliyet avantajı ile karşılayacak şekilde kullanılabilir.