Süresi Dolmuş veya Geçersiz SSL/TLS Sertifikası

SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Kayıtlar

Sitenizi Tarayın

Sitenizi bu zafiyete karşı kontrol edin

Otomatik bir tarama başlatın ve sitenizin etkilenip etkilenmediğini görün — sade dille bulgular ve çözümlerle.

Taramaya Başla
Kategori Kriptografik / Aktarım Katmanı Yanlış Yapılandırması
Tipik Önem Derecesi Yüksek
OWASP A02:2021 – Kriptografik Hatalar; A05:2021 – Güvenlik Yanlış Yapılandırması
CWE CWE-297 – Ana Makine Uyuşmazlığında Hatalı Sertifika Doğrulaması; CWE-298 – Sertifika Süresinin Hatalı Doğrulanması; CWE-295 – Hatalı Sertifika Doğrulaması
Diğer adları Güvenilmeyen Sertifika, Öz İmzalı Sertifika Uyarısı, Sertifika Süre Sonu Hatası, TLS Sertifikası Uyuşmazlığı
Etkilenen sistemler TLS sonlandıran her türlü HTTPS etkin web sunucusu, API uç noktası, posta sunucusu (STARTTLS/SMTPS), yük dengeleyici veya CDN
İlgili standartlar RFC 5280 (X.509 PKI), RFC 8446 (TLS 1.3), CA/Tarayıcı Forumu Temel Gereksinimleri

Genel Bakış

SSL/TLS sertifikaları, bir Sertifika Otoritesi (CA) tarafından verilen ve bir genel anahtarı bir kimliğe (genellikle alan adı veya kuruluş) bağlayan X.509 dijital belgeleridir. HTTPS ve diğer TLS korumalı protokoller tarafından sağlanan kimlik doğrulama ve şifrelemenin temelini oluştururlar.

Bir sertifika aşağıdaki nedenlerden biri veya birkaçı nedeniyle geçersiz hale gelebilir:

  • Süre sonu: Her sertifikanın bir notAfter alanı bulunur; geçerli tarih bu alanı aştığında sertifikanın süresi dolmuş sayılır. 2020 itibarıyla CA/Tarayıcı Forumu, kamuya güvenilir sertifikalar için maksimum geçerlilik süresini 398 gün ile sınırlandırmıştır.
  • Ana makine adı uyuşmazlığı: Konu Alternatif Adı (SAN) veya Ortak Ad (CN), istemcinin bağlandığı alan adıyla eşleşmez (örneğin, www.example.com için düzenlenmiş sertifikanın api.example.com'da kullanılması).
  • Güvenilmeyen veren: Sertifika öz imzalıdır veya istemcinin güven deposunda bulunmayan bir CA tarafından düzenlenmiştir.
  • İptal: CA, genellikle anahtar ele geçirilmesi veya yanlış düzenleme nedeniyle sertifikayı belirtilen son kullanma tarihinden önce CRL veya OCSP aracılığıyla iptal etmiştir.
  • Zayıf veya bozuk kriptografi: Sertifika, modern istemcilerin reddettiği kullanımdan kaldırılmış imza algoritmalarını (örn. MD5, SHA-1) veya yetersiz anahtar boyutlarını (örn. RSA-1024) kullanmaktadır.

Sensagraph, HTTPS uç noktalarını sürekli olarak tarar ve süresi dolmuş, yakında sona erecek, uyuşmayan, öz imzalı veya başka şekillerde güvenilmeyen sertifikaları işaretler.

Nasıl çalışır?

TLS el sıkışması sırasında sunucu, sertifika zincirini istemciye (tarayıcı, API tüketicisi, mobil uygulama) sunar. İstemci, şifreli oturumu kurmadan önce bir dizi doğrulama kontrolü gerçekleştirir:

  1. Zincir doğrulama: Zincirdeki her sertifika, istemcinin güven deposundaki güvenilir bir kök CA'ya kadar bir sonraki tarafından imzalanmış olmalıdır.
  2. Geçerlilik süresi kontrolü: İstemci, geçerli zamanı sertifikanın notBefore ve notAfter alanlarıyla karşılaştırır.
  3. Ana makine adı doğrulaması: İstemci, sunucunun ana makine adını SAN uzantısıyla (veya RFC 6125 uyarınca kullanımdan kaldırılan CN ile) eşleştirir.
  4. İptal kontrolü: OCSP zımbalama veya CRL dağıtım noktaları yapılandırılmışsa, istemci sertifikanın iptal edilmediğini doğrulayabilir.

Herhangi bir kontrol başarısız olduğunda, modern tarayıcılar engelleme ara yüzü uyarısı görüntüler (NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID vb.) ve kullanıcının açık bir geçişi olmadan sayfayı yüklemesini engeller. Tarayıcı dışı istemciler (mobil uygulamalar, mikro hizmetler) bağlantıyı tamamen reddedebilir ya da kritik bir şekilde doğrulamayı atlamak üzere yanlış yapılandırılmış olabilir; bu da sessiz bir güvenlik açığı yaratır.

  • Ağda konumlanmış bir saldırgan (MITM), sahte bir sertifika sunabilir; geçerli sertifika sabitleme veya CA güveni olmadan ve doğrulama devre dışı bırakıldığında istemcinin sahteciği tespit etme mekanizması kalmaz.
  • Süresi dolmuş sertifikalar şifrelemeyi doğası gereği bozmaz, ancak operatörün altyapıyı yönetemeyeceğine işaret eder ve tarayıcılar bağlantıyı engeller.
  • Joker sertifikalar (*.example.com) yalnızca tek bir alt alan adı düzeyini kapsar; daha derin alt alan adları için kullanıldığında ana makine adı uyuşmazlığına neden olurlar.

İş Etkisi

Süresi dolmuş veya geçersiz bir sertifikanın ani ve kümülatif sonuçları bulunmaktadır:

  • Hizmet kesintisi: Tarayıcılar erişimi tamamen engeller; uyarıyı manuel olarak geçmeyen kullanıcılar için site veya API erişilemez hale gelir — kullanıcıların büyük çoğunluğu geçmeyi seçmeyecektir.
  • Veri ele geçirilme riski: Sertifika doğrulamasının devre dışı bırakıldığı ortamlarda (örn. yanlış yapılandırılmış mobil uygulamalar veya dahili hizmetler) şifrelenmiş trafik bir MITM saldırganı tarafından ele geçirilebilir ve deşifre edilebilir.
  • Yasal ve uyumluluk riski: PCI DSS (Gereksinim 4), HIPAA ve GDPR aktarımdaki verilerin korunmasını şart koşar. Geçersiz bir sertifika bir denetim kontrolü başarısızlığı oluşturur ve para cezalarına veya denetim bulgularına yol açabilir.
  • İtibar hasarı: Tarayıcı uyarıları kullanıcı güvenini anında zedeler. Araştırmalar, kullanıcıların büyük çoğunluğunun sertifika hatası görüntüleyen sitelerden ayrıldığını ve bu siteleri kimlik avı veya güvenlik ihlaliyle ilişkilendirdiğini göstermektedir.
  • Arama motoru etkisi: Arama motorları, kalıcı HTTPS hataları olan siteleri alt sıralara iter veya listeden çıkarır.
  • Tedarik zinciri riski: Üçüncü taraf entegrasyonlar (ödeme işlemcileri, kimlik sağlayıcılar), geçersiz sertifika sunan hizmetlerden gelen bağlantıları reddedebilir ve ardışık arızalara neden olabilir.

Nasıl düzeltilir?

  1. Süresi dolmuşsa veya 30 gün içinde sona erecekse sertifikayı hemen yenileyin. Kamuya açık alan adları için ACME uyumlu bir CA (örn. Let's Encrypt) veya ticari bir CA kullanın. Let's Encrypt sertifikaları ücretsizdir, 90 gün geçerlidir ve otomatik yenileme destekler.
  2. Sertifika yaşam döngüsü yönetimini otomatikleştirin. Düzenleme ve yenilemeyi otomatikleştirmek için ACME istemcilerini (Certbot, acme.sh, Kubernetes için cert-manager) kullanın. Yenilemenin süre sonu tarihinden 60–30 gün önce tetiklenmesini ayarlayın. Asla yalnızca manuel süreçlere güvenmeyin.
  3. Ana makine adı uyuşmazlıklarını düzeltin. Sertifikanın SAN listesinin, hizmetin altında erişildiği her ana makine adını içerdiğinden emin olun. Doğru SAN'larla yeni bir sertifika düzenleyin veya eksik alan adını mevcut sertifika kapsamına ekleyin.
  4. Üretimdeki öz imzalı sertifikaları kamuya güvenilir bir CA tarafından düzenlenmiş sertifikalarla değiştirin. Öz imzalı sertifikaları yalnızca her istemcinin güven deposunun açıkça yönetildiği izole geliştirme veya yalnızca dahili ortamlar için saklayın.
  5. İzleme ve uyarıları uygulayın. Tüm uç noktalardaki sertifika süre sonu tarihlerini takip edin. Süre sonu öncesinde 60, 30 ve 7. günlerde uyarılar yapılandırın. Blackbox exporter ile Prometheus veya özel sertifika izleme hizmetleri bu süreci otomatikleştirebilir.
  6. OCSP Zımbalamayı etkinleştirin. Web sunucunuzda OCSP zımbalamayı etkinleştirin (Nginx: ssl_stapling on;, Apache: SSLUseStapling on). Bu, istemcilerin doğrudan CA'ya sorgu göndermeden iptal durumunu verimli şekilde kontrol etmesine olanak tanır.
  7. Güçlü kriptografi kullanın. RSA-2048 veya RSA-4096 (minimum) ya da ECDSA P-256/P-384 ile sertifika düzenleyin. İmza algoritması için SHA-256 veya daha güçlüsünü kullanın. SHA-1, MD5 ve 2048 bitin altındaki RSA anahtar boyutlarından kaçının.
  8. Dahili/özel CA'ları denetleyin. Özel CA kullanan dahili hizmetler için, bağlanan her istemcinin güven deposunun özel kök CA sertifikasını içerdiğinden ve özel CA'nın kendi sertifikalarının fark edilmeden sona ermediğinden emin olun.
  9. Tüm istemcilerde sertifika doğrulamasını zorunlu kılın. TLS sertifika doğrulamasının devre dışı bırakılmadığından emin olmak için uygulama kodunu denetleyin (örn. Python requests'te verify=False, Node.js'te rejectUnauthorized: false). Bu devre dışı bırakmalar asla üretime ulaşmamalıdır.

Kaynaklar

Sıkça sorulan sorular

Mutlaka değil. Süresi dolmuş bir sertifika, kriptografik güven ilişkisinin sona erdiği ve tarayıcıların erişimi bir hatayla engellediği anlamına gelir. Kendi başına aktif bir saldırıya işaret etmez; ancak istemcilerin ortadaki adam saldırısını tespit etmesini sağlayacak temel korumayı ortadan kaldırır. Sertifika hatasını atlayan veya yok sayan istemciler için ele geçirilme riski mevcuttur.

Modern tarayıcıların çoğu tam sayfa engelleme uyarısı görüntüler (örn. Chrome'da NET::ERR_CERT_DATE_INVALID) ve kullanıcıların 'Gelişmiş' geçişini manuel olarak tıklamasını gerektirir; kullanıcıların büyük çoğunluğu bunu yapmayacaktır. API istemcileri ve tarayıcı dışı uygulamalar, sertifika doğrulama hatalarını yoksaymak üzere açıkça yapılandırılmadıkça genellikle bağlantı hatasıyla başarısız olur.

Süresi dolmuş bir sertifika, bir zamanlar güvenilir bir CA tarafından düzenlenmiş ancak notAfter tarihini geçmiştir. Öz imzalı bir sertifika ise hiçbir zaman güvenilir bir CA tarafından düzenlenmemiştir; kendi özel anahtarıyla imzalandığından herhangi bir standart istemciye sunulduğu andan itibaren güvenilmezdir. Her ikisi de güven başarısızlığına yol açar; ancak farklı nedenlerle.

CA/Tarayıcı Forumu, kamuya güvenilir sertifika geçerliliğini 398 günle sınırlandırmıştır. Let's Encrypt sertifikaları 90 gün geçerlidir ve otomatik araçlar kullanılarak her 60 günde bir yenilenmelidir. En iyi uygulama, yenilemeyi otomatikleştirmek ve sertifikaların süre sonu tarihinden 30 gün önce uyarı alacak şekilde yapılandırmaktır.

Hizmete bağlanan her istemcinin öz imzalı sertifikanın CA'sını güven deposuna eklemiş olması ve sertifikanın ve özel anahtarının uygun şekilde korunması durumunda kabul edilebilir olabilir. Ancak bunu büyük ölçekte manuel olarak yönetmek hataya açıktır. Dahili hizmetler için daha iyi bir yaklaşım, özel bir dahili CA (örn. HashiCorp Vault PKI veya cfssl kullanarak) işletmek ve özel kök CA sertifikasını tüm dahili istemcilere dağıtmaktır.

Çevrimiçi Sertifika Durum Protokolü (OCSP) zımbalama, bir web sunucusunun TLS el sıkışmasına CA'dan imzalı ve zaman damgalı bir OCSP yanıtını proaktif olarak dahil etmesine olanak tanır; bu da sertifikanın iptal edilmediğini kanıtlar. Zımbalama olmadan istemci, CA'nın OCSP yanıtlayıcısıyla doğrudan iletişim kurmak zorundadır; bu da gecikme ve gizlilik sorunlarına yol açar. Zımbalama, Nginx, Apache ve modern web sunucularının büyük çoğunluğunda desteklenmekte olup sertifika dağıtımıyla birlikte etkinleştirilmelidir.