SSL/TLS Sertifika Ana Makine Adı Uyuşmazlığı

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
KategoriKriptografik / Sertifika Yanlış Yapılandırması
Tipik Önem DerecesiYüksek
OWASPA07:2021 – Kimlik ve Kimlik Doğrulama Hataları
CWECWE-297: Ana Makine Uyuşmazlığı ile Sertifika Doğrulamasının Hatalı Yapılması
Diğer AdlarıSertifika CN Uyuşmazlığı, SAN Uyuşmazlığı, Yanlış Sertifika, Ana Makine Doğrulama Hatası
Etkilenen SistemlerHTTPS web sunucuları, API uç noktaları, TLS ile güvenli hale getirilmiş posta sunucuları (SMTP/IMAP/POP3), LDAPS ve diğer TLS hizmetleri
İlgili RFC'lerRFC 9110 (HTTP Semantiği), RFC 6125 (Ana Makine Doğrulama), RFC 5280 (X.509 PKI)

Genel Bakış

Bir SSL/TLS sertifikası, açık anahtarı bir veya daha fazla alan adına bağlayarak sunucunun kimliğini doğrular. Tarayıcılar ve TLS istemcileri, URL'deki ana makine adının sertifikanın Subject Alternative Name (SAN) uzantısında ya da eski sertifikalar için Common Name (CN) alanında listelenen bir adla eşleşip eşleşmediğini denetler. Herhangi bir eşleşme bulunamazsa ana makine doğrulaması başarısız olur.

RFC 6125, TLS'de ana makine adı doğrulama için yetkili kuralları tanımlamaktadır. 2017'den itibaren Chrome, Firefox ve Safari gibi büyük tarayıcılar ile RFC 2818, SAN uzantısını zorunlu kılmaktadır; modern istemcilerde artık tek başına CN alanı yeterli değildir. Sensagraph, TLS sertifika incelemesi sırasında ana makine adı uyuşmazlıklarını otomatik olarak tespit eder.

Nasıl Çalışır?

TLS el sıkışması sırasında sunucu sertifika zincirini sunar. İstemci ardından ana makine adı doğrulamasını gerçekleştirir:

  1. İstemci, SAN uzantısındaki tüm dNSName girişlerini (ve IP tabanlı erişim için iPAddress girişlerini) çıkarır.
  2. Her giriş, tam eşleşme veya joker eşleşme (RFC 6125 §6.4.3 uyarınca tek bir baştaki *. etiketi) kullanılarak istenen ana makine adıyla karşılaştırılır.
  3. Hiçbir SAN girişi eşleşmezse bağlantı reddedilir (ya da izin veren/yanlış yapılandırılmış istemcilerde uyarıyla kabul edilir).

Uyuşmazlığa yol açan yaygın senaryolar:

  • Yanlış sertifika yayımlanması: example.com için verilen sertifika, SAN'da listelenmeyen api.example.com üzerinde sunulmaktadır.
  • Joker kapsam aşımı: *.example.com için bir joker sertifika api.example.com adresini kapsar; ancak deep.api.example.com adresini kapsamaz (jokerler yalnızca tek bir etiketi eşleştirir).
  • IP adresiyle erişim: Yalnızca DNS SAN içeren bir sertifika ham IP adresiyle erişildiğinde ve sertifikada iPAddress SAN bulunmadığında uyuşmazlık oluşur.
  • Alan adı değişikliğinden sonra sertifikanın güncellenmemesi: Sunucu yeni bir alan adına taşındı ancak sertifika yeniden düzenlenmedi.
  • Geliştirme/test sertifikasının üretim ortamında kullanılması: dev.internal için tasarlanmış dahili veya öz imzalı bir sertifika yanlışlıkla kamuya açık bir ana makine adında sunulmaktadır.
  • Yük dengeleyici veya CDN yanlış yapılandırması: Trafik, farklı bir sanal ana makine için sertifika sunan bir arka uca yönlendirilmektedir.

İş Etkisi

Ana makine adı uyuşmazlığı, TLS'nin sağlamak üzere tasarlandığı sunucu kimliği güvencesini doğrudan ortadan kaldırır. Pratik sonuçlar şunlardır:

  • Ortadaki adam (MitM) saldırısına maruz kalma: Tarayıcı uyarılarını geçen kullanıcılar veya ana makine doğrulamasını devre dışı bırakan istemciler, trafik dinleme ve kimlik bilgisi çalınma riskiyle karşı karşıyadır.
  • Hizmet kesintisi: Katı istemciler (modern tarayıcılar, mobil uygulamalar, sertifika sabitleme kullanan API'ler) bağlantıyı reddederek kesintilere veya başarısız işlemlere yol açar.
  • Kullanıcı güveninin zedelenmesi: Tarayıcı güvenlik uyarıları (Chrome'da NET::ERR_CERT_COMMON_NAME_INVALID, Firefox'ta SEC_ERROR_BAD_CERT_DOMAIN) son derece görünürdür ve kullanıcıların siteyi terk etmesine neden olur.
  • Uyumluluk ihlalleri: PCI DSS Gereksinim 4.2.1 ve benzeri standartlar, kart sahibi veri ortamları için geçerli ve doğru kapsamlı sertifikaları zorunlu kılar. Uyuşmazlık, QSA denetimlerinde bulgu olarak kaydedilebilir.
  • Otomatik süreç hataları: Sıkı TLS doğrulaması kullanan CI/CD sistemleri, sağlık denetimi ajanları ve API istemcileri başarısız olarak dağıtımları ve izleme işlemlerini aksatır.

Nasıl Düzeltilir?

  1. Kullanılan tüm ana makine adlarını denetleyin. İstemcilerin TLS üzerinden eriştiği her genel ve dahili ana makine adını listeleyin. Her birinin, o uç noktada sunulan sertifikanın SAN'ı tarafından kapsandığını doğrulayın.
  2. Sertifikayı yeniden düzenleyin veya değiştirin. CA'nızdan doğru SAN girişleriyle yeni bir sertifika edinin. Birden fazla alt alan adı için, gerekli tüm ana makine adlarını açıkça listeleyen çok SAN'lı bir sertifika ya da joker sertifika (*.example.com) kullanın.
  3. Otomatik sertifika yönetimini benimseyin. Manuel sertifika yaşam döngüsü hatalarını ortadan kaldırmak ve zamanında yenilemeyi sağlamak için ACME tabanlı otomasyonu (örn. Certbot ile Let's Encrypt veya web sunucularına yerleşik ACME istemcileri) devreye alın.
  4. İstemcilerde ana makine doğrulamasını asla devre dışı bırakmayın. CURLOPT_SSL_VERIFYHOST=0 (libcurl), verify=False (Python requests) veya checkServerIdentity: () => undefined (Node.js) gibi bayraklar ayarlayan uygulama kodu sessiz MitM açıklarına yol açar. Bunun yerine sertifikayı düzeltin.
  5. Gerektiğinde IP SAN'ları ekleyin. Hizmetlere IP adresiyle erişilmesi gerekiyorsa CN'e güvenmek yerine sertifikaya iPAddress SAN girişi olarak IP'yi ekleyin.
  6. Sertifika envanterini sürekli izleyin. Kullanıcıları etkilemeden önce uyuşmazlıkları tespit etmek için sertifika şeffaflık günlüğü izlemesini ve otomatik taramayı kullanın.
  7. Sorun çözüldükten sonra HSTS uygulayın. Sertifikalar doğru hale geldikten sonra, protokol düşürme saldırılarını önlemek için uygun max-age değeriyle HTTP Strict Transport Security (HSTS) dağıtın.

Kaynaklar

Sıkça sorulan sorular

Süresi dolmuş bir sertifika, geçerlilik süresini (sertifikadaki notAfter tarihini) aşmıştır. Ana makine adı uyuşmazlığında ise sertifika geçerlidir, ancak erişilen alan adından farklı alan adları için düzenlenmiştir. Her iki durum da TLS doğrulamasının başarısız olmasına neden olur; ancak farklı hata mesajları üretir ve farklı çözüm adımları gerektirir.

Bir joker sertifika (örn. *.example.com) yalnızca tek bir alt alan adı derinliğini kapsar. api.example.com ve www.example.com adreslerini eşleştirir, ancak deep.api.example.com veya example.com apex alan adını (apex SAN olarak ayrıca listelenmediği sürece) kapsamaz. Karmaşık alt alan adı yapıları için her ana makine adını açıkça listeleyen çok SAN'lı sertifikalar daha güvenilirdir.

Evet, ancak sertifikanın IP adresiyle eşleşen bir iPAddress SAN girişi içermesi gerekir. Yalnızca DNS adlarını listeleyen bir sertifika, IP üzerinden erişildiğinde ana makine uyuşmazlığı hatası verir. Genel CA'ların çoğu genel IP'ler için IP SAN düzenlemez; bu senaryo daha çok dahili altyapıda karşılaşılır.

Evet. Kullanıcı tarayıcı uyarısını geçerse ya da bir istemci ana makine doğrulamasını atlatacak şekilde yapılandırılmışsa, TLS el sıkışması doğrulanmamış bir sunucu kimliğiyle tamamlanır. Aynı Wi-Fi ağında veya BGP ele geçirmesi yoluyla ağ aracısı konumundaki bir saldırgan kendi sertifikasını sunarak tüm trafiği dinleyebilir.

Şu OpenSSL komutunu kullanabilirsiniz: openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'. Bu komut, sunulan sertifikadaki SAN'ları gösterir ve hedef ana makine adının dahil olup olmadığını doğrulamanızı sağlar. Alternatif olarak curl -I https://alanadiniz.com komutu, uyuşmazlık varsa sertifika hatasını raporlar.