TLS El Sıkışma Hatası Neden Oluşur?
TLS el sıkışma hatası, güvenli bağlantı kurulurken istemci ile sunucunun ortak güvenlik koşullarında anlaşamaması veya sunulan kimliği doğrulayamaması nedeniyle oluşur. Uyuşmazlık; TLS sürümü, şifre takımı, imza algoritması, anahtar değişimi, SNI (Server Name Indication), sertifika zinciri ya da hizmet kimliği doğrulamasında ortaya çıkabilir.
Bazı yazılımların kullandığı “SSL handshake failed” iletisi, bağlantının gerçekten TLS’den önce kullanılan SSL protokolüyle kurulduğu anlamına gelmez; bu ad güncel TLS hataları için de korunabilir. “TLS bağlantısı kurulamıyor” gibi genel iletiler kök nedeni tek başına kanıtlamaz. Hatanın hangi aşamada oluştuğunu ve istemci, ara sistem ya da sunucudan hangisinin uyarıyı ürettiğini ayrıca belirlemek gerekir.
TLS Hatası İstemciden mi, Ağdan mı, Sunucudan mı Kaynaklanıyor?
Aynı hata metni farklı katmanlardan kaynaklanabilir. Bu nedenle önce sorunun tek bir cihazda mı, belirli bir ağda mı, yoksa tüm istemcilerde mi görüldüğünü belirleyin.
İstemci Katmanı
Eski bir TLS kitaplığı, sınırlı şifre takımı desteği, güncel olmayan güvenilen kök sertifika deposu veya hatalı sistem saati yalnız belirli istemcilerde başarısızlığa yol açabilir. İstemcinin bağlantıyı alan adı yerine doğrudan IP adresiyle kurması da SNI gönderimini ve kimlik doğrulamasını değiştirebilir.
Bir tarayıcı bağlanırken eski bir uygulama ya da API istemcisi bağlanamıyorsa sunucu tamamen erişilemez değildir. Fark çoğu durumda istemcilerin desteklediği TLS sürümleri, imza algoritmaları, güvenilen kök sertifikalar veya hizmet kimliği doğrulama davranışlarından kaynaklanır.
Ara Ağ Katmanı
CDN, reverse proxy (ters proxy), yük dengeleyici, kurumsal TLS inceleme sistemi veya güvenlik duvarı bağlantının gerçek TLS uç noktası olabilir. Bu katmandaki sertifika, SNI eşlemesi ve güvenlik politikası arka uç sunucudan farklıdır; bu nedenle yalnız arka ucu kontrol etmek yeterli olmayabilir.
Ara cihaz TLS bağlantısını sonlandırmıyor olsa bile istemcinin başlangıç seçeneklerini taşıyan ClientHello mesajındaki belirli uzantıları veya paket boyutlarını kabul etmeyebilir; kendi güvenlik politikası nedeniyle bağlantıyı da engelleyebilir. Sorun yalnız belirli bir ağda görülüyorsa doğrudan bağlantı ile ara sistem üzerinden kurulan bağlantının sonuçlarını ayrı değerlendirin.
Sunucu Katmanı
Sunucunun ilgili portta TLS yerine farklı bir hizmet sunması, yanlış sanal hostu seçmesi, eksik sertifika zinciri göndermesi veya istemciyle ortak seçenek bırakmayacak kadar dar bir güvenlik politikası uygulaması el sıkışmayı durdurabilir. Birden fazla sunucu düğümü kullanılıyorsa yapılandırmaların aynı olmaması hatanın aralıklı görünmesine neden olabilir.
Sunucu günlüklerindeki TLS uyarıları, seçilen sanal host, protokol sürümü ve sertifika bilgileri istemci tarafındaki genel hata metninden daha açıklayıcıdır. Yine de TLS günlüğünde kayıt bulunmaması, trafiğin sunucuya hiç ulaşmadığını tek başına göstermez; ilgili olayın kaydı kapalı olabilir. Bağlantının daha önce bir ara ağ cihazında kesilmiş olması da mümkündür.
TLS Sürümü, Şifre Takımı, SNI ve Sertifika Kaynaklı Hatalar
TLS el sıkışması tek bir kontrol değildir. İstemci, desteklediği sürüm ve uzantıları ClientHello adlı başlangıç mesajında bildirir; sunucu kabul ettiği ortak seçenekleri seçer ve taraflar el sıkışmanın bütünlüğünü doğrular. Sertifikayla doğrulanan bağlantıda sunucu, kendi kimliğini gösteren sertifika zincirini de bu süreçte gönderir.
Ortak TLS Sürümü Bulunamaması
İstemci yalnız sunucunun kapattığı eski sürümleri destekliyorsa veya sunucu yalnız istemcinin desteklemediği daha yeni sürümlere izin veriyorsa ortak protokol sürümü seçilemez. Bu durumda “protocol version” benzeri bir uyarı görülebilir, ancak bazı uygulamalar ayrıntıyı gizleyip yalnız genel bir el sıkışma hatası gösterir.
Çözüm, güvenlik politikasını rastgele gevşetmek değildir. Mevcut uygulamalarda TLS 1.2 desteği uyumluluk için gerekebilir; iki sürüm de destekleniyorsa TLS 1.3 tercih edilmelidir. Bütün hedef istemcileri destekleyen bir hizmet yalnız TLS 1.3 sunabilir; TLS 1.0 ve 1.1 yeniden etkinleştirilmemelidir. Yeni tasarlanan protokollerde varsayılan sürüm TLS 1.3 olmalı; dağıtım gereksinimi varsa TLS 1.2 ek ve varsayılan olmayan bir seçenek olarak desteklenebilir. Eski bir istemcinin çalışması gerekiyorsa genel sunucu politikasını zayıflatmak yerine istemci güncellemesini, kapsamı sınırlı bir uyumluluk katmanını veya kullanım dışı bırakmayı değerlendirin.
Şifre Takımı, İmza ve Anahtar Değişimi Uyumsuzluğu
Ortak TLS sürümü bulunması tek başına yeterli değildir. Tarafların şifre takımı, sertifika imzası, desteklenen kriptografik gruplar ve anahtar değişimi seçeneklerinde de uyum sağlaması gerekir.
TLS 1.3'te şifre takımı, kimlik doğrulamalı simetrik şifreleme algoritmasını ve anahtar türetmede kullanılan özet işlevini tanımlar; imza ve anahtar değişimi ayrı uzantılarla görüşülür. Bu ayrım önemlidir, çünkü “ortak şifre takımı var” sonucu sertifikanın imza algoritmasının veya anahtar değişiminin desteklendiğini tek başına göstermez.
SNI ile Yanlış Sertifika Seçilmesi
SNI, istemcinin ulaşmak istediği sunucu adını el sıkışmanın başında bildirmesini sağlar. Aynı IP adresinde birden fazla site barındıran sunucu, bu bilgiye göre doğru sanal hostu ve sertifikayı seçebilir.
İstemci SNI göndermiyorsa, yanlış adı gönderiyorsa veya sunucudaki eşleme hatalıysa sunucu varsayılan sertifikayı gönderebilir. Sunucu adı tanınmadığında sunucu el sıkışmayı da sonlandırabilir. SNI seçimi ile hizmet kimliği doğrulaması aynı kontrol değildir: SNI sunucunun hangi sertifikayı sunacağını etkiler; istemci daha sonra bu sertifikayı bağlanmak istediği DNS adı veya IP adresiyle karşılaştırır.
Sertifika Zincirinin Doğrulanamaması
Sunucu genellikle yaprak sertifikayı ve güven yolunu kurmak için gereken ara sertifikaları gönderir; istemcinin önceden güvendiği kök sertifika çoğu durumda istemcinin sertifika deposundadır. Eksik ara sertifika, uygunsuz zincir, sertifikanın sunucu kimliği doğrulaması için geçerli olmaması veya istemcinin deposunda uygun güven kökünün bulunmaması doğrulama yolunu bozabilir.
unknown_ca uyarısı, sunulan zincirin doğrulamayı yapan tarafın güvendiği bir köke bağlanamadığını gösterebilir. mTLS (mutual TLS) kullanılıyorsa istemci sertifikasını reddeden taraf sunucu da olabilir; uyarıyı hangi tarafın gönderdiğini belirleyin. Kesin düzeltme yöntemi sunucu yazılımına, sertifika sağlayıcısına ve dağıtım mimarisine göre değişir; yaprak ve ara sertifikaları hedef sistemin gereksinimlerine göre yapılandırın.
Sertifika Süresi, Sistem Saati ve İptal Durumu
Sertifikanın geçerlilik başlangıcı ile bitişi, istemcinin saatine göre değerlendirilir. Süresi dolmuş ya da henüz geçerli olmayan sertifika kadar yanlış sistem saati de aynı sınıfta hata doğurabilir. Sertifika yenilendiği halde CDN veya yük dengeleyici düğümlerinden biri eski sertifikayı sunuyorsa sorun yalnız bazı kullanıcılarda görülebilir.
Geçerlilik süresi ile iptal durumu aynı kontrol değildir. İstemci, OCSP (Online Certificate Status Protocol) veya CRL (Certificate Revocation List) politikasına göre ek denetim yapabilir. Ağ erişimi, istemci politikası ve sertifikadaki TLS özellikleri değiştiği için iptal denetimi hataları bütün istemcilerde aynı sonucu vermeyebilir.
Alan Adının Sertifikayla Eşleşmemesi
İstemci, bağlanmak istediği hizmet kimliğini sertifikanın SAN (Subject Alternative Name) uzantısındaki uygun DNS adı veya IP adresi kimliğiyle karşılaştırır. DNS adı için dNSName, IP adresi için iPAddress türü gerekir; metin olarak DNS alanına yazılmış bir IP adresi, IP kimliği yerine geçmez.
Güncel doğrulama kuralları hizmet kimliği için sertifikanın CN (Common Name) alanına geri dönülmesini kabul etmez. Wildcard sertifikada yıldız yalnız en soldaki etiketin tamamı olabilir ve tek bir etiketi karşılar: *.example.com, www.example.com adını kapsayabilir; example.com veya a.b.example.com adını kapsamaz.
Bu kontroller sertifikanın süresinden ve güven yolundan bağımsızdır. Geçerli, iptal edilmemiş ve güvenilir bir sertifika yanlış hizmet için sunulduğunda kimlik doğrulaması yine tamamlanmaz.
TLS Hatalarında Belirtiye Göre İlk Kontroller
Aşağıdaki belirtiler hangi alanı önce incelemek gerektiğini gösterir; ancak hiçbiri tek başına kesin kök nedeni kanıtlamaz.
| Belirti | Öncelikli İnceleme Alanı | Tek Başına Kanıtlamaz |
|---|---|---|
protocol_version (protokol sürümü) | İstemci ve sunucunun desteklediği TLS sürümleri | Hangi tarafın politikasının hatalı olduğu |
handshake_failure veya insufficient_security | Şifre takımı, imza algoritması, grup ve güvenlik politikası | Uyuşmazlığın yalnız şifre takımından kaynaklandığı |
unrecognized_name veya beklenmeyen sertifika | SNI değeri ve sanal host eşlemesi | Sertifika zincirinin mutlaka bozuk olduğu |
unknown_ca veya zincir doğrulama hatası | Ara sertifikalar ve uyarıyı gönderen tarafın güvenilen kök sertifika deposu | Sertifikanın hizmet kimliğiyle eşleşmediği |
certificate_expired veya tarih uyarısı | Sertifika başlangıç-bitiş zamanı, istemci saati ve tüm TLS uçları | Sertifikanın güven yolunun ya da SAN kaydının doğru olduğu |
| Hizmet kimliği eşleşme hatası | İstenen DNS veya IP kimliği ile sertifikadaki SAN kayıtları | TLS sürümü ya da şifre takımı uyumsuzluğu bulunduğu |
| Aralıklı başarısızlık | Yük dengeleyici düğümleri, CDN uçları ve ağ yolu | Sorunun istemciden tamamen bağımsız olduğu |
TLS Hatasında Hedef, Protokol, SNI ve Sertifika Kontrolleri
Genel hata iletisini gördüğünüzde doğrudan sertifikayı yenilemeyin; önce bağlantının hangi aşamada koptuğunu belirleyin. Aşağıdaki sıra, istemci, ara ağ, sertifika ve sunucu olasılıklarını birbirine karıştırmadan ilerlemeyi sağlar.
- Kapsamı belirleyin: Hata tek istemcide, tek ağda, tek alan adında veya tüm bağlantılarda mı görülüyor?
- Hedefi doğrulayın: Alan adı, port, DNS sonucu ve ulaşılan IP adresi beklenen hizmete mi gidiyor?
- TLS sürümlerini karşılaştırın: İstemci teklifleri ile sunucu politikasında ortak ve izin verilen sürüm bulunuyor mu?
- Kriptografik seçenekleri karşılaştırın: Şifre takımının yanında imza algoritmalarını, desteklenen grupları, anahtar değişimini ve sertifika anahtar türünü inceleyin.
- SNI ve sanal hostu kontrol edin: İstemcinin beklenen SNI değerini gönderdiğini ve bu değerin doğru sertifikayı seçtiğini doğrulayın.
- Uygulama protokolünü kontrol edin: ALPN (Application-Layer Protocol Negotiation) teklif ve seçiminin istemciyle sunucuda ortak değer bıraktığını doğrulayın.
- Zincir, süre ve kimliği ayırın: Güven yolunu, geçerlilik zamanını, iptal durumunu ve SAN eşleşmesini dört ayrı kontrol olarak ele alın.
- Ara katmanı izole edin: CDN, ters proxy, yük dengeleyici veya TLS inceleme sisteminin bağlantıyı nerede sonlandırdığını belirleyin.
- Karşılaştırmalı deneme yapın: Aynı alan adı ve SNI değerini koruyarak farklı istemci, ağ ve sunucu düğümlerinin sonuçlarını kaydedin.
- Kayıtları eşleştirin: İstemci hatasını, sunucu TLS uyarısını ve ara sistem günlüklerini aynı saat aralığında karşılaştırın.
Komut satırı tanısında, alanadi.example yerine inceleme yetkiniz olan hizmetin gerçek alan adını yazarak openssl s_client -connect alanadi.example:443 -servername alanadi.example -verify_hostname alanadi.example -showcerts -verify_return_error örneğini kullanabilirsiniz. -servername SNI değerini gönderir; -verify_hostname ise sertifikanın beklenen alan adıyla eşleşmesini ayrıca denetler. -verify_return_error doğrulama hatasında el sıkışmayı durdurur; bu seçenek olmadan OpenSSL hatayı gösterdiği halde devam edebilir.
OpenSSL’in kullandığı güvenilen kök sertifika deposunun hedef istemcideki depoyla aynı olduğunu varsaymayın. -showcerts sunucunun gönderdiği sertifikaları listeler; bu liste tek başına doğrulanmış bir güven yolu değildir. OpenSSL eski CN alanıyla eşleşmeyi de kabul edebildiğinden, güncel hizmet kimliği koşulu için SAN kaydını ayrıca kontrol edin. Örnek komut her istemcinin iptal denetimini ve uygulama politikasını yeniden oluşturmaz.
Karşılaştırmalı denemelerde yalnız istemciyi değiştirmek yeterli değildir. Aynı alan adı farklı DNS yanıtlarıyla farklı uçlara ulaşabilir; alan adı yerine IP adresini hizmet kimliği olarak kullanmak ise SNI ve kimlik kontrolünü değiştirir. Belirli bir düğümü karşılaştırmak için OpenSSL’de yalnız -connect hedefini o düğümün IP adresi ve portuyla değiştirin; alan adıyla hizmet alınıyorsa -servername ve -verify_hostname değerlerini aynı gerçek alan adı olarak koruyun. Bu nedenle alan adını, portu, ağı, istemci sürümünü, SNI değerini ve ulaşılan IP adresini birlikte kaydedin. Aksi halde iki farklı TLS uç noktasının sonuçlarını tek bir sistemin davranışı sanabilirsiniz.
TLS Hatasının Kaynağına Göre Düzeltme
Düzeltmeyi hatanın görüldüğü katmanda yapın. Yalnız eski bir istemci etkileniyorsa istemci kitaplığını, işletim sisteminin güvenilen kök sertifika deposunu, saat ayarını ve desteklenen TLS özelliklerini inceleyin. Tüm istemciler etkileniyorsa önce sunucuyu veya TLS bağlantısını sonlandıran ön ucu kontrol edin.
- Protokol veya kriptografik uyumsuzlukta istemci ile sunucunun ortak ve kabul edilebilir bir güvenlik profili kullanmasını sağlayın.
- SNI sorununda alan adı ile sanal host, sertifika ve ön uç yönlendirmesi arasındaki eşlemeyi düzeltin.
- Zincir sorununda sunulan sertifika zincirinin sırasını ve ara sertifikaları hedef sunucu yazılımına göre doğrulayın.
- Kimlik uyuşmazlığında sertifikanın istenen DNS adını veya doğrudan bağlantı kurulan IP adresini içerip içermediğini kontrol edin.
- Ara ağ kaynaklı durumda düzeltmeyi arka uçta değil, TLS bağlantısını sonlandıran veya trafiği filtreleyen cihazda yapın.
Sertifika doğrulamasını kapatmak veya bilinmeyen bir kök sertifikaya güvenmek kalıcı çözüm değildir. Doğrulama kapalıyken bağlantının kurulması, hizmetin kimliğinin doğrulandığı anlamına gelmez. Düzeltmeden sonra aynı hedef ve istemciyle, kimlik ve zincir doğrulaması açıkken yeniden deneyin.
