क्लाइंट प्रमाणपत्र

Question

का उपयोग करने का प्रयास करते समय sslv3 अलर्ट हैंडशेक विफलता को हल करना मैं एक ऐसी सेवा से कनेक्ट करने का प्रयास कर रहा हूं जिसके लिए प्राधिकरण के लिए प्रमाण पत्र की आवश्यकता है। प्रक्रिया यह है कि मैं सेवा को एक सीएसआर फ़ाइल भेजता हूं। सेवा सीएसआर पर हस्ताक्षर करती है और मुझे एक प्रमाण पत्र भेजती है जिसका उपयोग मैं कनेक्शन के लिए करता हूं।

1. मैं निम्न आदेश लाइन द्वारा सीएसआर उत्पन्न:

   openssl req -new -nodes -newkey rsa:2048 -keyout cert.key -out cert.csr 
   

2. मैं cert.csr की सामग्री ले गए और उन्हें करने के लिए भेजा। वे क्लाइंट प्रमाण पत्र उत्पन्न करते हैं और मुझे पीईएम फ़ाइल वापस मिल गई है।

3. अब मैं कर्नेल() के लिए SSLCERT में अपनी प्रमाणपत्र फ़ाइल का उपयोग करके कनेक्ट करने का प्रयास करता हूं और cert.key से निजी कुंजी प्रदान करता हूं CURLOPT_SSLKEY - (जो मुझे चरण 1 पर मिला है)। error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

क्या मैं इस प्रक्रिया में गलत कर रहा हूँ:

साथ विफल?

यह काम करता है जब मैं सेवा से एक निजी कुंजी (स्वयं हस्ताक्षरित प्रमाणपत्र) सहित एक परीक्षण प्रमाण पत्र प्राप्त करने का प्रयास करता हूं। लेकिन जब मैं अपने सीएसआर से उत्पन्न प्रमाणपत्र का उपयोग करता हूं और फिर अपनी निजी कुंजी को कुंजी के रूप में उपयोग करता हूं, तो यह हैंडशेक विफलता के साथ त्रुटियों।

तो मुझे पता है कि इसमें ओपनएसएल/कर्ल वी 3/टीएलएस इत्यादि का समर्थन नहीं करता है, जो कि समाधान के लिए शोध करते समय दूसरों को उनकी समस्या का पता चला था।

curl -i -v --request POST https://service.com/ --cert clientcert.pem --key private_key.pem --cert-type pem --tlsv1.1 --insecure 
* Connected to service.com (1xx.xxx.xxx.xx) port 443 (#0) 
* successfully set certificate verify locations: 
* CAfile: none 
    CApath: /etc/ssl/certs 
* SSLv3, TLS handshake, Client hello (1): 
* SSLv3, TLS handshake, Server hello (2): 
* SSLv3, TLS handshake, CERT (11): 
* SSLv3, TLS handshake, Server key exchange (12): 
* SSLv3, TLS handshake, Request CERT (13): 
* SSLv3, TLS handshake, Server finished (14): 
* SSLv3, TLS handshake, CERT (11): 
* SSLv3, TLS handshake, Client key exchange (16): 
* SSLv3, TLS handshake, CERT verify (15): 
* SSLv3, TLS change cipher, Client hello (1): 
* SSLv3, TLS handshake, Finished (20): 
* SSLv3, TLS alert, Server hello (2): 
* error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure 
* Closing connection 0 

रनिंग निम्नलिखित संस्करणों:

यहाँ मैं क्या चलाने है कर्ल 7.35.0 (x86_64-पीसी-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn /1.28 librtmp/2,3

Answer 1

नहीं एक निश्चित जवाब लेकिन बहुत टिप्पणी में फिट करने के लिए बहुत:

मैं परिकल्पना वे तुम्हें एक प्रमाणपत्र है कि या तो एक गलत जारीकर्ता है दे दी है (हालांकि उनके सर्वर उस के लिए एक अधिक विशिष्ट चेतावनी कोड इस्तेमाल कर सकते हैं) या एक गलत विषय हम जानते हैं कि प्रमाणपत्र आपकी निजीकी से मेल खाता है - क्योंकि curl और openssl client दोनों ने उन्हें मेल नहीं खाए बिना उन्हें जोड़ा; लेकिन हम वास्तव में नहीं जानते कि यह उनके वांछित सीए (ओं) से मेल खाता है - क्योंकि आपका कर्ल openssl का उपयोग करता है और openssl SSL क्लाइंट यह लागू नहीं करता है कि एक कॉन्फ़िगर किया गया क्लाइंट प्रमाणपत्र certreq.CAs से मेल खाता है।

openssl x509 <clientcert.pem -noout -subject -issuer और परीक्षण पी 12 से प्रमाण पत्र पर वही काम करता है जो काम करता है। openssl s_client करें (या आपने जो किया है उसकी जांच करें) और Acceptable client certificate CA names के अंतर्गत देखें; वहां का नाम या उनमें से एक को आपके कर्ट के जारीकर्ता (बिल्कुल) मिलना चाहिए (बिल्कुल!)। यदि नहीं, तो यह आपकी समस्या की सबसे अधिक संभावना है और आपको उनसे जांच करने की आवश्यकता है कि आपने अपना सीएसआर सही स्थान पर और सही तरीके से सबमिट किया है। शायद उनके पास विभिन्न क्षेत्रों, या व्यापार लाइनों, या सक्रिय बनाम लंबित, आदि

यदि आपके प्रमाण पत्र जारीकर्ता वांछित सीए से मेल खाता है, तो इसके विषय की तुलना (परीक्षण-पी 12) से करें, एक: क्या वे समान प्रारूप में हैं? क्या आपके काम में मौजूद कोई भी घटक नहीं है? यदि वे इसे अनुमति देते हैं, तो एक विषय नाम के साथ एक नया सीएसआर उत्पन्न करने और परीक्षण करने की कोशिश करें, जैसा कि आप प्राप्त कर सकते हैं, और देखें कि क्या यह एक प्रमाणपत्र उत्पन्न करता है जो बेहतर काम करता है। (ऐसा करने के लिए आपको एक नया कुंजी उत्पन्न करने की आवश्यकता नहीं है, लेकिन यदि आप चुनते हैं, तो ट्रैक करें कि कौन से कर्ट मेल खाते हैं ताकि आप उन्हें मिश्रित न करें।) यदि यह देखने में मदद नहीं करता है openssl x509 <cert -noout -text के साथ प्रमाणपत्र एक्सटेंशन जो कि किसी भी अंतर (ओं) के लिए उचित रूप से विषय प्राधिकरण से संबंधित हो सकते हैं, जैसे कि KeyUsage, ExtendedKeyUsage, शायद नीति, शायद बाधाएं, यहां तक ​​कि कुछ गैर मानक भी हो सकता है।

यदि अन्य सभी विफल हो जाते हैं, तो सर्वर ऑपरेटर से पूछें कि उनके लॉग समस्या के बारे में क्या कहते हैं, या यदि आपके पास लॉग को स्वयं देखने की सुविधा है।

Answer 2

What SSL private key should be sent along with the client certificate?

उनमें से कोई भी :)

क्लाइंट प्रमाण पत्र के बारे में आकर्षक चीजें, गूंगा बातें नहीं करता है एक गुप्त (पासवर्ड) की तरह संचारित तरह से एक, मैदान में एक सर्वर पर पाठ (HTTP basic_auth)। पासवर्ड अभी भी क्लाइंट प्रमाणपत्र के लिए कुंजी अनलॉक करने के लिए उपयोग किया जाता है, इसका उपयोग सीधे एक्सचेंज के दौरान नहीं किया जाता है या टीपी क्लाइंट को प्रमाणित करता है।

इसके बजाय, ग्राहक उस सत्र के लिए एक अस्थायी, यादृच्छिक कुंजी चुनता है। ग्राहक उसके प्रमाण के साथ अस्थायी, यादृच्छिक कुंजी पर हस्ताक्षर करता है और उसे सर्वर (कुछ हाथ छोड़ने) भेजता है। यदि कोई बुरा आदमी कुछ भी रोकता है, तो यह यादृच्छिक है कि इसका भविष्य में उपयोग नहीं किया जा सकता है। इसका उपयोग सर्वर के साथ प्रोटोकॉल के दूसरे भाग के लिए भी नहीं किया जा सकता है क्योंकि सर्वर एक नया, यादृच्छिक मान भी चुनता है।

---

Fails with: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

TLS 1.0 उपयोग करें और इसके बाद के संस्करण; और Server Name Indication का उपयोग करें।

आपने कोई कोड प्रदान नहीं किया है, इसलिए यह आपको स्पष्ट नहीं करता कि आपको क्या करना है।इसके बजाय, यहाँ यह परीक्षण करने के लिए OpenSSL कमांड लाइन है:

openssl s_client -connect www.example.com:443 -tls1 -servername www.example.com \ 
    -cert mycert.pem -key mykey.pem -CAfile <certificate-authority-for-service>.pem 

तुम भी -CAfile का उपयोग "सत्यापित त्रुटि: num = 20" से बचने के लिए कर सकते हैं। उदाहरण के लिए, “verify error:num=20” when connecting to gateway.sandbox.push.apple.com देखें।