Kendinden İmzalı 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 / PKI Yanlış Yapılandırması
Tipik Önem Derecesi Orta
OWASP A02:2021 – Kriptografik Hatalar; A05:2021 – Güvenlik Yanlış Yapılandırması
CWE CWE-295 – Hatalı Sertifika Doğrulaması
Diğer Adları Güvenilmeyen Sertifika, Doğrulanmamış Sertifika, Kendinden Düzenlenen Sertifika
Etkilenen Sistemler Web sunucuları, API'ler, posta sunucuları, dahili servisler, IoT cihazları, HTTPS üzerinden erişilen yönetim panelleri
İlgili Standartlar RFC 5280 (X.509 PKI), RFC 8555 (ACME/Let's Encrypt), CA/Browser Forum Temel Gereksinimler

Genel Bakış

Bir SSL/TLS sertifikası, bir sunucunun kimliğini doğrular ve şifreli iletişimi mümkün kılar. Normal Açık Anahtar Altyapısı'nda (PKI) bir sertifika, tarayıcıların ve işletim sistemlerinin kök deposuna dahil ettiği güvenilir bir Sertifika Otoritesi (CA) tarafından imzalanır. Kendinden imzalı sertifika ise barındırdığı ortak anahtarın karşılığı olan özel anahtarla bizzat imzalanır; herhangi bir bağımsız üçüncü taraf, sertifikanın öznesini (alan adı) anahtar çifti sahibiyle ilişkilendirme konusunda onay vermemiştir.

Kendinden imzalı sertifikalar standart güven depolarındaki herhangi bir köke bağlanamadığından tarayıcılar ve HTTP istemcileri varsayılan olarak uyarı veya hata gösterir; otomatik istemcilerin büyük çoğunluğu (API tüketicileri, mobil uygulamalar) ise doğrulamayı atlamak üzere açıkça yapılandırılmadıkça bağlantıyı tamamen reddeder. Sensagraph, taranan hostların TLS incelemesi sırasında kendinden imzalı sertifikaları otomatik olarak tespit eder.

Nasıl Çalışır?

TLS sertifika doğrulaması, RFC 5280'de tanımlanan güven zinciri modeline dayanır. Bir istemci sertifikayı şu şekilde doğrular:

  1. Sertifikanın dijital imzasının, istemcinin güven deposundaki güvenilir bir kök CA'ya kadar izlenebilir olduğunu doğrular.
  2. Sertifikanın Subject Alternative Name (SAN) veya Common Name (CN) alanının istenen ana makine adıyla eşleştiğini teyit eder.
  3. Sertifikanın geçerlilik süresi içinde olduğunu ve iptal edilmediğini (OCSP / CRL) kontrol eder.

Kendinden imzalı sertifika, tanım gereği 1. adımda başarısız olur: Issuer ve Subject alanları aynıdır ve imza sertifikanın kendi özel anahtarıyla yapılmıştır. Bu nedenle katı doğrulama uygulayan istemciler hata gösterir (örn. Chromium'da ERR_CERT_AUTHORITY_INVALID). Teknik sonuçlar şunlardır:

  • Kimlik güvencesi yok: Herhangi biri herhangi bir alan adı için kendinden imzalı sertifika oluşturabilir. İstekçinin alan adı sahipliğini denetleyen bir CA yoktur.
  • Ortadaki Adam (MITM) saldırısı riski: Tarayıcı uyarılarını geçen kullanıcılar veya doğrulamayı atlayacak şekilde yapılandırılan istemciler, meşru sunucuyu kendi kendinden imzalı sertifikasını sunmuş bir saldırıcıdan ayırt edemez. Trafik şifreli olabilir; ancak saldırganın anahtarıyla.
  • HSTS ile uyumsuzluk: Kendinden imzalı sertifikalar HSTS ön yükleme listelerine katılamaz ve standart sertifika şeffaflığı (CT) günlükleriyle uyumsuzdur.
  • Otomatik istemci hataları: curl, Java'nın HttpsURLConnection, Python'un requests kütüphanesi ve mobil SDK'lar güvenilmeyen sertifikaları varsayılan olarak reddeder; entegrasyonları kırar ve geçici çözüm olarak --insecure veya trustAllCerts gibi güvenlik açıkları barındıran bayrakların kullanılmasını zorunlu kılar.
  • İptal mekanizması yok: CRL veya OCSP yanıtı yayımlayacak bir CA bulunmadığından, özel anahtar ele geçirildiğinde sertifikanın süre dolmadan geçersiz kılınmasının standart bir yolu yoktur.

İş Etkisi

Kendinden imzalı sertifikaların üretim veya internete açık sistemlerde bulunması çeşitli somut riskler doğurur:

  • Kullanıcı güveninin sarsılması: Tarayıcı güvenlik uyarıları son kullanıcıları caydırır ve marka itibarına zarar verir. Bilinçli kullanıcılar oturumu tamamen terk edebilir.
  • Kimlik bilgisi ve veri ele geçirme: Kullanıcılar veya otomatik sistemler sertifikayı kabul ederse aktif bir MITM saldırganı; kimlik doğrulama bilgileri, oturum belirteçleri ve hassas veriler dahil tüm trafiği şifresini çözüp değiştirebilir.
  • Uyumluluk ihlalleri: PCI DSS (Gereksinim 4), HIPAA Güvenlik Kuralı ve NIST SP 800-52 Rev. 2, düzenlenmiş veri işleyen sistemler için düzgün sertifika yönetimi ve güvenilir CA istemini zorunlu kılar. Kapsam dahilindeki sistemlerdeki kendinden imzalı sertifikalar denetim bulgularına ve yaptırımlara yol açabilir.
  • Entegrasyon kesintileri: HTTPS üzerinden bağlanan üçüncü taraf hizmetler, ödeme işlemcileri veya iş ortakları sertifika doğrulamasında başarısız olarak hizmet kesintilerine veya güvensiz atlatma yapılandırmalarına neden olabilir.
  • Olay müdahale açığı: CA destekli iptal mekanizması olmadığından, ele geçirilen bir sertifika süresi dolmadan etkili biçimde geçersiz kılınamaz ve maruz kalma penceresi uzar.

Nasıl Düzeltilir?

  1. CA imzalı sertifika ile değiştirin: Kamuoyunca güvenilen bir CA'dan sertifika edinin. İnternete açık servislerin büyük çoğunluğu için Let's Encrypt, ACME protokolü (RFC 8555) aracılığıyla ücretsiz ve otomatik Alan Adı Doğrulama (DV) sertifikaları sunar. Daha yüksek güvence gerektiren durumlar için ticari bir CA'dan OV veya EV sertifikası edinin.
  2. Yenilemeyi otomatikleştirin: Sertifika alımı ve yenilenmesini otomatikleştirmek için ACME istemcilerini (Certbot, acme.sh, Caddy'nin yerleşik ACME desteği, Traefik) kullanın. Sona ermeden 60–30 gün önce yenilemenin tetiklenmesini sağlayın.
  3. Dahili / özel ağlar: Genel internetten erişilemeyen sistemler için (dahili API'ler, yönetim panelleri, iç mikroservisler), kurumun kontrol ettiği özel bir dahili CA kurun (örn. HashiCorp Vault PKI Secrets Engine, Microsoft AD CS veya CFSSL) ve kök sertifikasını tüm dahili istemcilere MDM veya yapılandırma yönetimi araçlarıyla dağıtın. Bu yaklaşım, genel CA gerek duymadan güven zinciri ilkesini korur.
  4. HSTS'yi etkinleştirin: Güvenilir bir sertifika yerleştirildikten sonra uygun max-age değeriyle Strict-Transport-Security başlığını ayarlayın ve protokol indirgeme saldırılarını önlemek için HSTS ön yüklemeyi değerlendirin.
  5. Sertifika izlemeyi uygulayın: Beklenmedik sertifika değişikliklerini ve yaklaşan son kullanma tarihlerini tespit etmek için sertifika şeffaflığı günlüğü izlemesini ve otomatik son kullanma tarih uyarılarını (örn. crt.sh bildirimleri veya dahili araçlar) kullanın.
  6. İstemci kodunu denetleyin: Kendinden imzalı sertifikalar için geçici çözüm olarak eklenen sertifika doğrulama devre dışı bırakma kodlarını (verify=False, trustAllCerts, -k bayrakları, InsecureSkipVerify: true) arayın ve meşru sertifikalar devreye alındıktan sonra bu atlatmaları kaldırın.
  7. Üretimden kaldırın: Kendinden imzalı sertifikaları asla üretim veya dışarıdan erişilebilen herhangi bir uç noktaya dağıtmayın. Kullanımlarını üretim verisiyle bağlantısı olmayan yalıtılmış geliştirme veya laboratuvar ortamlarıyla sınırlı tutun.

Kaynaklar

Sıkça sorulan sorular

Kendinden imzalı bir sertifika, aktarım sırasındaki trafiği şifreler; bu durum pasif dinleme açısından düz HTTP'den biraz daha iyidir. Ancak kimlik güvencesi sağlamaz; saldırgan MITM saldırısı sırasında kendi kendinden imzalı sertifikasını yerleştirebilir ve kullanıcılar meşru sunucuyu taklit edenden ayırt edemez. Herhangi bir üretim veya kullanıcıya yönelik sistem için CA imzalı sertifika zorunludur.

Gerçek kullanıcı veya hassas verinin olmadığı yalıtılmış geliştirme ortamlarında, yerel testlerde veya otomatik test hattında kendinden imzalı sertifikalar yaygın biçimde kabul edilebilir. Üretim sistemleri, internete açık uç noktalar veya düzenlemeye tabi veri işleyen herhangi bir ortamda kabul edilemez. Dahili sistemler için kendinden imzalı sertifikalar yerine özel dahili CA kullanılmalıdır.

Kendinden imzalı sertifika kendi anahtarıyla imzalanır ve hiçbir veren zinciri yoktur. Özel (dahili) CA'dan alınan sertifika ise kurumun kontrol ettiği ve kendi istemcilerine güvenilir kök olarak dağıttığı bir CA tarafından imzalanır. Özel CA modeli güven zinciri ilkesini korur; özel köküne sahip istemciler, sunucu sertifikalarını tarayıcı uyarısı olmaksızın tam olarak doğrulayabilir.

Evet. TLS el sıkışması incelemesi sırasında bir tarayıcı sertifika zincirini alabilir, verenin aynı varlık olup olmadığını (kendinden imzalamayı belirtir) ve veren kökün standart bir güven deposunda mevcut olup olmadığını doğrulayabilir. Sensagraph bu kontrolü sürekli TLS incelemesinin bir parçası olarak gerçekleştirir.

Evet; istemci sertifika zincirini doğrulamadan bağlanırsa (örn. tarayıcı uyarısını geçen bir kullanıcı) trafik TLS katmanında şifrelenir ve salt pasif gözlemcilere karşı koruma sağlar. Ancak aktif MITM saldırılarına karşı koruma sağlamaz; çünkü saldırgan kendi kendinden imzalı sertifikasını sunabilir ve istemcinin bunu reddetmek için hiçbir gerekçesi yoktur.