हैंडशेक की विफलता विभिन्न कारणों से हो सकती है:
- क्लाइंट और सर्वर द्वारा उपयोग में असंगत साइफर सूट करता है। इसके लिए क्लाइंट को सर्वर द्वारा समर्थित साइफर सूट का उपयोग (या सक्षम) करना होगा।
- उपयोग में SSL के असंगत संस्करण (सर्वर केवल TLS v1 को स्वीकार कर सकता है, जबकि क्लाइंट केवल SSL v3 का उपयोग करने में सक्षम है)। फिर से, क्लाइंट को यह सुनिश्चित करना होगा कि वह एसएसएल / टीएलएस प्रोटोकॉल के संगत संस्करण का उपयोग करता है।
- सर्वर प्रमाणपत्र के लिए अधूरा विश्वास पथ; सर्वर का प्रमाण पत्र शायद ग्राहक द्वारा भरोसा नहीं किया जाता है। यह आमतौर पर एक अधिक क्रिया त्रुटि में परिणाम होगा, लेकिन यह बहुत संभव है। आमतौर पर फिक्स क्लाइंट के ट्रस्ट स्टोर में सर्वर के CA प्रमाणपत्र को आयात करना है।
- एक अलग डोमेन के लिए प्रमाणपत्र जारी किया जाता है। फिर से, यह एक और अधिक क्रियात्मक संदेश के रूप में होता है, लेकिन अगर यह कारण है तो मैं यहां तय करूंगा। इस मामले में रिज़ॉल्यूशन को सही प्रमाणपत्र का उपयोग करने के लिए सर्वर (यह आपका नहीं लगता है) मिलेगा।
चूंकि, अंतर्निहित विफलता को इंगित नहीं किया जा सकता है, इसलिए -Djavax.net.debug=allस्थापित एसएसएल कनेक्शन के डिबगिंग को सक्षम करने के लिए ध्वज पर स्विच करना बेहतर है । डिबग को चालू करने के साथ, आप यह इंगित कर सकते हैं कि हैंडशेक में कौन सी गतिविधि विफल हो गई है।
अपडेट करें
अब उपलब्ध विवरणों के आधार पर, यह प्रतीत होता है कि समस्या सर्वर को जारी किए गए प्रमाण पत्र और रूट सीए के बीच एक अपूर्ण प्रमाणपत्र ट्रस्ट पथ के कारण है। ज्यादातर मामलों में, यह इसलिए है क्योंकि रूट CA का प्रमाणपत्र ट्रस्ट स्टोर में अनुपस्थित है, इस स्थिति के लिए जहां प्रमाणपत्र ट्रस्ट पथ मौजूद नहीं हो सकता है; प्रमाणपत्र ग्राहक द्वारा अनिवार्य रूप से अविश्वसनीय है। ब्राउज़र एक चेतावनी प्रस्तुत कर सकते हैं ताकि उपयोगकर्ता इसे अनदेखा कर सकें, लेकिन SSL क्लाइंट (जैसे HttpsURLConnection वर्ग, या Apache HttpCompords Client जैसे किसी HTTP क्लाइंट लाइब्रेरी ) के लिए ऐसा नहीं है।
अधिकांश ग्राहक वर्ग / पुस्तकालय प्रमाणपत्र सत्यापन के लिए जेवीएम द्वारा उपयोग किए जाने वाले ट्रस्ट स्टोर पर भरोसा करेंगे। ज्यादातर मामलों में, यह cacertsJRE_HOME / lib / सुरक्षा निर्देशिका में फ़ाइल होगी । यदि ट्रस्ट स्टोर का स्थान जेवीएम सिस्टम संपत्ति का उपयोग करके निर्दिष्ट किया गया है javax.net.ssl.trustStore, तो उस पथ में स्टोर आमतौर पर क्लाइंट लाइब्रेरी द्वारा उपयोग किया जाता है। यदि आप संदेह में हैं, तो अपनी Merchantकक्षा पर एक नज़र डालें , और संबंध बनाने के लिए उपयोग की जाने वाली कक्षा / लाइब्रेरी का पता लगाएँ।
इस ट्रस्ट स्टोर में सीए जारी करने वाले सर्वर के प्रमाण पत्र को जोड़ने से समस्या का समाधान होना चाहिए। आप इस उद्देश्य के लिए उपकरण प्राप्त करने से संबंधित प्रश्न पर मेरे उत्तर का उल्लेख कर सकते हैं , लेकिन इस उद्देश्य के लिए जावा कीटूल उपयोगिता पर्याप्त है।
चेतावनी : ट्रस्ट स्टोर अनिवार्य रूप से उन सभी सीए की सूची है, जिन पर आप भरोसा करते हैं। यदि आप एक ऐसे प्रमाणपत्र में डालते हैं जो उस सीए से संबंधित नहीं है जिस पर आप भरोसा नहीं करते हैं, तो एसएसएल / टीएलएस उन साइटों से जुड़ता है जिनके पास उस संस्था द्वारा जारी किए गए प्रमाण पत्र हैं, अगर निजी कुंजी उपलब्ध है तो उसे डिक्रिप्ट किया जा सकता है।
# 2 अद्यतन करें: JSSE ट्रेस के आउटपुट को समझना
जेवीएम द्वारा उपयोग किए जाने वाले कीस्टोर और ट्रस्टस्टोर्स आमतौर पर बहुत शुरुआत में सूचीबद्ध होते हैं, कुछ इस तरह से:
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 :
यदि गलत ट्रस्टस्टोर का उपयोग किया जाता है, तो आपको सर्वर के प्रमाणपत्र को दाईं ओर फिर से आयात करना होगा, या सूचीबद्ध एक का उपयोग करने के लिए सर्वर को फिर से कॉन्फ़िगर करना होगा (अनुशंसित नहीं है यदि आपके पास कई जेवीएम हैं, और उन सभी को अलग-अलग उपयोग किया जाता है। की जरूरत है)।
यदि आप यह सत्यापित करना चाहते हैं कि ट्रस्ट सीट्स की सूची में आवश्यक सीट्स हैं, तो उसी के लिए एक सेक्शन है, जो निम्नानुसार है:
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
आपको यह देखने की आवश्यकता होगी कि क्या सर्वर का सीए एक विषय है।
हैंडशेक प्रक्रिया में कुछ मुख्य प्रविष्टियाँ होंगी (आपको उन्हें विस्तार से समझने के लिए SSL की आवश्यकता होगी, लेकिन वर्तमान समस्या को डीबग करने के उद्देश्य से, यह जानना पर्याप्त होगा कि एक हैंडशेक_फैल्योर आमतौर पर Serverio में रिपोर्ट किया जाता है।
1. ClientHello
प्रविष्टियों की एक श्रृंखला की सूचना दी जाएगी जब कनेक्शन को प्रारंभ किया जा रहा है। SSL / TLS कनेक्शन सेटअप में क्लाइंट द्वारा भेजा गया पहला संदेश ClientHello संदेश है, जिसे आमतौर पर लॉग में रिपोर्ट किया जाता है:
*** 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 }
***
उपयोग किए गए सिफर स्वीट्स पर ध्यान दें। इसके लिए आपको अपनी मर्चेंट.प्रॉफर्टी फाइल में एंट्री से सहमत होना पड़ सकता है, क्योंकि उसी कन्वेंशन को बैंक की लाइब्रेरी द्वारा नियोजित किया जा सकता है। यदि उपयोग किया गया कन्वेंशन अलग है, तो चिंता का कोई कारण नहीं है, क्योंकि सर्वरहेल ऐसा बताएगा, यदि सिफर सूट अतुलनीय है।
2. सर्वरहेलो
सर्वर एक सर्वरहेलो के साथ प्रतिक्रिया करता है, जो इंगित करेगा कि क्या कनेक्शन सेटअप आगे बढ़ सकता है। लॉग में प्रविष्टियाँ आमतौर पर निम्न प्रकार की होती हैं:
*** ServerHello, TLSv1
RandomCookie: GMT: 1291302499 bytes = { some byte array}
Cipher Suite: SSL_RSA_WITH_RC4_128_SHA
Compression Method: 0
***
उस सिफर सूट पर ध्यान दें, जिसे उसने चुना है; यह सर्वर और क्लाइंट दोनों के लिए सबसे अच्छा सूट है। यदि कोई त्रुटि होती है तो आमतौर पर सिफर सूट निर्दिष्ट नहीं किया जाता है। सर्वर का प्रमाण पत्र (और वैकल्पिक रूप से पूरी श्रृंखला) सर्वर द्वारा भेजा जाता है, और प्रविष्टियों में पाया जाएगा:
*** 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
***
यदि प्रमाणपत्र का सत्यापन सफल हो गया है, तो आपको निम्न के समान प्रविष्टि मिलेगी:
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
उपरोक्त चरणों में से एक भी सफल नहीं हुआ, जिसके परिणामस्वरूप हैंडशेक_फेल्योर, हैंडशेक के लिए आम तौर पर इस चरण में पूरा होता है (वास्तव में नहीं, लेकिन हैंडशेक के बाद के चरण आमतौर पर हैंडशेक विफलता का कारण नहीं होते हैं)। आपको यह पता लगाने की आवश्यकता होगी कि कौन सा चरण विफल रहा है, और उचित संदेश को प्रश्न के अपडेट के रूप में पोस्ट करें (जब तक कि आप संदेश को पहले से ही समझ नहीं चुके हैं, और आप जानते हैं कि इसे हल करने के लिए क्या करना है)।