Opensl s_client एक बेमेल CAfile के खिलाफ एक प्रमाणपत्र की पुष्टि क्यों करता है?

Question

मैं openssl s_clientइस तरह से एक प्रमाणपत्र सत्यापन त्रुटि प्राप्त करने की कोशिश कर रहा हूं :

$ openssl s_client -crlf -verify 9 \
  -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem \
  -starttls smtp -host mx-ha03.web.de -port 25

Web.de सर्वर का प्रमाण पत्र ड्यूश टेलीकॉम CA द्वारा प्रमाणित है, न कि TURKTRUST, इस प्रकार उपरोक्त कमांड विफल होना चाहिए, है ना?

लेकिन यह रिपोर्ट करता है:

    Verify return code: 0 (ok)

क्यों?

मेरा मतलब है कि एक एनालॉग गटरल्स-सीएलआई कमांड उम्मीद के मुताबिक विफल है:

$ { echo -e 'ehlo example.org\nstarttls' ; sleep 1 } | \
   gnutls-cli --starttls --crlf \
   --x509cafile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem \
   --port 25 mx-ha03.web.de
[..]
*** Verifying server certificate failed...

एक --x509cafile /etc/ssl/certs/ca-certificates.crtक्रॉसचेक कर रहा है, यानी कि मुझे मिल जाने वाले गिटर-क्ली के बजाय का उपयोग कर रहा है:

[..]
- The hostname in the certificate matches 'mx-ha03.web.de'.
- Peer's certificate is trusted

(जो अपेक्षित भी है)

ऑप-सर्टिफिकेट के लिए Openssl s_client प्रिंट।

    Verify return code: 0 (ok)

TURKTRUST के समान परिणाम ...

पहले मुझे शक है कि -CApath(यानी / etc / ssl / certs) के लिए एक डिफ़ॉल्ट सेटिंग का उपयोग करके - लेकिन जब मैं straceइस प्रक्रिया को सिर्फ openतर्क के लिए सिर्फ syscall देखता हूं CAfile।

(सभी परीक्षण Ubuntu 10.04 सर्वर पर किए गए)

अद्यतन: मैंने एक Fedora 20 सिस्टम के लिए TURKTRUST प्रमाणपत्र की प्रतिलिपि बनाई है और पहले खुलने वाले कथन को निष्पादित किया है - वहां मुझे एक अलग परिणाम मिलता है:

Verify return code: 19 (self signed certificate in certificate chain)

Answer 1

यह पता चला है कि openssl s_clientउबंटू 10.04 पर अभी भी सिस्टम इंस्टॉल किए गए प्रमाणपत्रों के लिए एक डिफ़ॉल्ट स्थान पर प्रश्न हैं, भले ही -CApath और -CAfile निर्दिष्ट किए गए हों:

8466  open("/usr/lib/ssl/certs/4e18c148.0", O_RDONLY) = 4

(स्ट्रेस आउटपुट)

कहाँ पे:

$ ls -l /usr/lib/ssl/certs/4e18c148.0
lrwxrwxrwx 1 root root 30 2014-04-11 21:50 /usr/lib/ssl/certs/4e18c148.0 ->
    Deutsche_Telekom_Root_CA_2.pem

निर्देशिका उबंटू 10.04 पर /usr/lib/ssl/certsएक सहानुभूति है /etc/ssl/certs, इस प्रकार openस्ट्रेस लॉग से लाइन का चयन नहीं किया जाता है जब '/ etc / ssl' के लिए grepping ...

स्रोत

Openssl-0.9.8k को देखते हुए, इस मुद्दे में स्थित है स्रोत crypto/x509/by_dir.c, dir_ctrl():

dir=(char *)Getenv(X509_get_default_cert_dir_env());
if (dir)
    ret=add_cert_dir(ld,dir,X509_FILETYPE_PEM);
else
    ret=add_cert_dir(ld,X509_get_default_cert_dir(),
                     X509_FILETYPE_PEM);

जहां X509_get_default_cert_dirलौटता है /usr/lib/ssl/certsऔर X509_get_default_cert_dir_envलौटता है SSL_CERT_DIR।

वैकल्पिक हल

इस प्रकार, कोई व्यक्ति अपेक्षित व्यवहार प्राप्त करने के लिए Ubuntu 10.04 / खुलने वाले 0.9.8k के तहत निम्नलिखित वर्कअराउंड का उपयोग कर सकता है:

$ SSL_CERT_DIR="" openssl s_client -crlf -verify 9 \
    -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.crt \
    -starttls smtp -host mx-ha03.web.de -port 25

और सत्यापन विफल होने के साथ:

Verify return code: 19 (self signed certificate in certificate chain)

वर्तमान स्थिति

यह एक उबंटू मुद्दा है। उदाहरण के लिए, फेडोरा 20 के ओपनएसएल 1.0.1 या फेडोरा 29 के ओपनएसएल 1.1.1 के साथ, यह वर्कअराउंड आवश्यक नहीं है, क्योंकि समस्या को पुन: प्रस्तुत नहीं किया जा सकता है। इसका मतलब यह है कि जैसे विकल्प को निर्दिष्ट करते समय -CAfileया -CApath, कोई डिफ़ॉल्ट प्रमाणपत्र प्रणाली निर्देशिका फेडोरा सिस्टम पर निर्देशिका खोज सूची में नहीं जोड़ा जाता है।

Opensl 1.0.2g के साथ Ubuntu 16 पर समस्या अभी भी मौजूद है।

यह CentOS 7 पर भी Opensl-1.0.2k-16 के साथ मौजूद है - और दुर्भाग्य से, उपरोक्त वर्कअराउंड में मदद नहीं करता है और अनजान / अप्रत्याशित TLS पैकेट प्रकारों के कारण gnutls-3.3.29-8 विफल रहता है।

Comments

मेरे पास 1.0.2g संस्करण है और इसमें अभी भी यह बग है। चीजों को बदतर बनाने के लिए, -verify_return_error ध्वज का कोई प्रभाव नहीं पड़ता है और प्रमाणपत्र गलत होने पर भी TLS कनेक्शन आगे बढ़ता है।

— तोकुमार

@takumar, मैंने इसे Ubuntu 16 के तहत ओपनस्ले 1.0.2g-1ubuntu4.14 के साथ पुन: परीक्षण किया और मैं पुष्टि कर सकता हूं, वर्कअराउंड के बिना यह ओपनसेल परीक्षण अभी भी विफल रहता है। लेकिन कम से कम वर्कअराउंड के साथ मुझे अपेक्षित त्रुटि संदेश मिलता है - और वर्कअराउंड के साथ और -verify_return_errorकमांड निकास स्थिति के साथ समाप्त हो जाता है। फेडोरा 29 के साथ और खुलता है। 1.1.1-3.fc29.x86_64 सब कुछ अभी भी अपेक्षित रूप से काम करता है, अर्थात वर्कअराउंड। जरूरी नहीं है।

— मैक्सक्लेपजिग

2019 में, यह अभी भी macOS पर लगता है। इसके अलावा, कुछ सिस्टम सपोर्ट कर सकते हैं -no-CAfile( भरोसेमंद सीए सर्टिफिकेट्स को डिफॉल्ट फाइल लोकेशन से लोड न करें ) और -no-CApath( डिफॉल्ट डायरेक्टरी लोकेशन से भरोसेमंद सीए सर्टिफिकेट्स को लोड न करें ), लेकिन मेरा सिस्टम ऐसा नहीं करता है, इसलिए मैंने उन लोगों को टेस्ट नहीं किया है।

— अर्जन