javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated iletisi, Java (özellikle Apache HttpClient gibi kütüphaneler) bağlantı oturumunda karşı tarafın bir sertifika sunmadığını veya sunduğu sertifikanın kimlik doğrulaması için kullanılamadığını bildirir. Sorun çoğu zaman istemcinin güven deposunda ya da sunucunun sertifika sunumunda yatar.
Belirtiler ve olası nedenler
- Sunucu, TLS el sıkışmasında sertifika göndermiyor (anonim cipher suite veya eksik yapılandırma).
- İstemci JVM'in
cacertsdeposu sunucunun kök CA'sını tanımıyor. - Sunucu birden çok siteyi tek IP'de barındırıyor ve eski bir istemci SNI göndermediği için yanlış veya varsayılan sertifika dönüyor.
- Bir ara proxy veya güvenlik cihazı TLS bağlantısını keserek kendi sertifikasını sunuyor.
- Karşılıklı TLS (mTLS) bekleyen uçta istemci sertifikası eksik.
Adım adım teşhis
- Sunucunun gerçekten sertifika sunduğunu doğrulayın:
openssl s_client -connect ornek.com:443 -servername ornek.com -showcerts - Çıktıda zincirin tam olup olmadığına bakın; ara sertifika eksikse sunucuya ekleyin.
- Java tarafında ayrıntılı günlük açın:
java -Djavax.net.debug=ssl:handshake -jar uygulama.jar - Günlükte "Certificate" mesajının gelip gelmediğini ve hangi cipher suite seçildiğini kontrol edin.
- Kök CA güven deposunda yoksa
keytool -list -keystore $JAVA_HOME/lib/security/cacertsile arayın ve gerekirse ekleyin.
Kalıcı çözüm ve önleme
Sunucuda sertifika ve ara sertifikaları içeren tam zinciri yapılandırın, anonim (anon) cipher suite'leri devre dışı bırakın ve SNI destekleyen güncel bir Java sürümü kullanın. Kurumsal proxy kullanıyorsanız proxy'nin kök sertifikasını JVM güven deposuna eklemeniz gerekir. Zincir eksikliklerini hızlıca görmek için SSL denetleme aracını kullanabilirsiniz; uygun sertifika arıyorsanız SSL sertifikaları sayfasına bakın.
Sık yapılan hatalar
- Hatayı yalnızca istemci kodunda arayıp sunucunun gerçekte hangi sertifikayı gönderdiğine bakmamak.
- Test ortamında çalışan güven deposu ayarının üretim sunucusunda farklı bir JDK'ya bağlı olması.
- Sertifika değiştirildikten sonra uygulamanın yeniden başlatılmaması; JVM güven deposunu açılışta okur.
- Hata iletisindeki ayrıntıyı (hangi ana bilgisayar, hangi oturum) okumadan doğrulamayı kapatmak.
Sorunu çözdükten sonra aynı bağlantıyı hem openssl hem de uygulamanızla tekrar deneyerek iki sonucun tutarlı olduğunu görün. Sonuçlar farklıysa uygulamanızın kullandığı güven deposu ile sistemin deposu ayrışıyor olabilir.
Özetle: hata çoğunlukla "karşı taraf kimliğini kanıtlayamadı" anlamına gelir; zinciri, güven deposunu ve SNI'yi sırasıyla kontrol etmek sorunu büyük oranda çözer.