El sıkışma hatası çeşitli nedenlerden dolayı meydana gelmiş olabilir:
- İstemci ve sunucu tarafından kullanılan uyumsuz şifre paketleri. Bu, istemcinin sunucu tarafından desteklenen bir şifre paketini kullanmasını (veya etkinleştirmesini) gerektirir.
- Kullanımdaki uyumsuz SSL sürümleri (sunucu yalnızca TLS v1'i kabul ederken, istemci yalnızca SSL v3 kullanabilir). Yine, istemcinin SSL / TLS protokolünün uyumlu bir sürümünü kullandığından emin olması gerekebilir.
- Sunucu sertifikası için eksik güven yolu; sunucunun sertifikasına muhtemelen istemci tarafından güvenilmiyor. Bu genellikle daha ayrıntılı bir hatayla sonuçlanır, ancak oldukça olasıdır. Genellikle düzeltme, sunucunun CA sertifikasını istemcinin güven deposuna aktarmaktır.
- Sertifika, farklı bir alan adı için verilir. Yine, bu daha ayrıntılı bir mesajla sonuçlanırdı, ancak nedeninin bu olması durumunda düzeltmeyi burada belirteceğim. Bu durumda çözüm, sunucunun (sizinki gibi görünmüyor) doğru sertifikayı kullanması olacaktır.
Altta yatan arıza tam olarak belirlenemediğinden, -Djavax.net.debug=allkurulan SSL bağlantısının hata ayıklamasını etkinleştirmek için bayrağı açmak daha iyidir . Hata ayıklama açıkken, anlaşmadaki hangi aktivitenin başarısız olduğunu belirleyebilirsiniz.
Güncelleme
Şu anda mevcut olan ayrıntılara göre, sorunun sunucuya verilen sertifika ile kök CA arasındaki eksik sertifika güven yolundan kaynaklandığı görülmektedir. Çoğu durumda, bunun nedeni kök CA'nın sertifikasının güven deposunda bulunmaması ve bunun bir sertifika güven yolunun var olamayacağı duruma yol açmasıdır; sertifika, istemci tarafından esasen güvenilmezdir. Tarayıcılar, kullanıcıların bunu görmezden gelebilmesi için bir uyarı sunabilir, ancak aynı durum SSL istemcileri için geçerli değildir ( HttpsURLConnection sınıfı veya Apache HttpComponents Client gibi herhangi bir HTTP İstemci kitaplığı gibi ).
Bu istemci sınıflarının / kitaplıklarının çoğu, sertifika doğrulaması için JVM tarafından kullanılan güven deposuna güvenir. Çoğu durumda, bu cacertsJRE_HOME / lib / security dizinindeki dosya olacaktır . Güven deposunun konumu JVM sistem özelliği kullanılarak belirtilmişse javax.net.ssl.trustStore, bu yoldaki depo genellikle istemci kitaplığı tarafından kullanılan depodur. Şüpheniz varsa, şuna bir bakın:Merchant sınıfınıza ve bağlantı kurmak için kullandığı sınıfı / kütüphaneyi belirleyin.
CA'yı veren sunucunun sertifikasını bu güven deposuna eklemek sorunu çözmelidir. Sen benim başvurabilirsiniz araçları alma konusunda ilgili soru üzerine cevap bu amaçla, ancak Java'nın keytool yarar bu amaç için yeterlidir.
Uyarı : Güven deposu, esasen güvendiğiniz tüm CA'ların listesidir. Güvenmediğiniz bir CA'ya ait olmayan bir sertifika koyarsanız, o varlık tarafından verilen sertifikalara sahip sitelere SSL / TLS bağlantılarının şifresi, özel anahtar mevcutsa çözülebilir.
Güncelleme # 2: JSSE izlemesinin çıktısını anlama
JVM tarafından kullanılan anahtar deposu ve güven depoları genellikle aşağıda olduğu gibi en başta listelenir:
keyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.6.0_21\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is :
Yanlış güven deposu kullanılıyorsa, sunucunun sertifikasını doğru olana yeniden aktarmanız veya sunucuyu listelenen birini kullanacak şekilde yeniden yapılandırmanız gerekir (birden fazla JVM'niz varsa ve hepsi farklı amaçlar için kullanılıyorsa önerilmez) ) ihtiyacı vardır.
Güven sertifikaları listesinin gerekli sertifikaları içerip içermediğini doğrulamak isterseniz, aynı için şu şekilde başlayan bir bölüm vardır:
adding as trusted cert:
Subject: CN=blah, O=blah, C=blah
Issuer: CN=biggerblah, O=biggerblah, C=biggerblah
Algorithm: RSA; Serial number: yadda
Valid from SomeDate until SomeDate
Sunucunun CA'sının bir konu olup olmadığını aramanız gerekir.
El sıkışma işleminin birkaç göze çarpan girişi olacaktır (bunları ayrıntılı olarak anlamak için SSL'yi bilmeniz gerekir, ancak mevcut sorunu gidermek amacıyla, genellikle ServerHello'da bir handshake_failure'un rapor edildiğini bilmek yeterli olacaktır.
1. MüşteriMerhaba
Bağlantı başlatılırken bir dizi giriş rapor edilecektir. İstemci tarafından SSL / TLS bağlantı kurulumunda gönderilen ilk mesaj ClientHello mesajıdır ve genellikle günlüklerde şu şekilde rapor edilir:
*** ClientHello, TLSv1
RandomCookie: GMT: 1291302508 bytes = { some byte array }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods: { 0 }
***
Kullanılan şifre paketlerine dikkat edin. Bu , merchant.properties dosyanızdaki girişe uymak zorunda kalabilir , çünkü aynı sözleşme bankanın kitaplığı tarafından da kullanılabilir. Kullanılan kural farklıysa, endişelenmenize gerek yoktur, çünkü ServerHello şifre paketi uyumsuzsa bunu belirtecektir.
2. ServerHello
Sunucu, bağlantı kurulumunun devam edip edemeyeceğini gösteren bir ServerHello ile yanıt verir. Günlüklere girişler genellikle aşağıdaki türdedir:
*** ServerHello, TLSv1
RandomCookie: GMT: 1291302499 bytes = { some byte array}
Cipher Suite: SSL_RSA_WITH_RC4_128_SHA
Compression Method: 0
***
Seçtiği şifre paketine dikkat edin; bu, hem sunucu hem de istemci için mevcut en iyi pakettir. Bir hata varsa genellikle şifre paketi belirtilmez. Sunucunun sertifikası (ve isteğe bağlı olarak tüm zincirin) sunucu tarafından gönderilir ve girişlerde şu şekilde bulunur:
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=server, O=server's org, L=server's location, ST =Server's state, C=Server's country
Signature Algorithm: SHA1withRSA, OID = some identifer
.... the rest of the certificate
***
Sertifikanın doğrulanması başarılı olduysa, aşağıdakine benzer bir giriş bulacaksınız:
Found trusted certificate:
[
[
Version: V1
Subject: OU=Server's CA, O="Server's CA's company name", C=CA's country
Signature Algorithm: SHA1withRSA, OID = some identifier
El sıkışma bu aşamada tipik olarak tamamlandığından (gerçekten değil, ancak el sıkışmanın sonraki aşamaları tipik olarak bir el sıkışma başarısızlığına neden olmaz) için yukarıdaki adımlardan biri başarılı olamazdı ve bu da el sıkışma başarısızlığıyla sonuçlanırdı. Hangi adımın başarısız olduğunu bulmanız ve uygun mesajı soruya bir güncelleme olarak göndermeniz gerekir (mesajı zaten anlamadıysanız ve çözmek için ne yapmanız gerektiğini bilmiyorsanız).