ทำไม openssl s_client ตรวจสอบใบรับรองกับ CAfile ที่ไม่ตรงกัน?

ฉันพยายามที่จะให้ข้อผิดพลาดการตรวจสอบใบรับรองด้วย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 ได้รับการรับรองโดย Deutsche Telekom CA ไม่ใช่ TURKTRUST ดังนั้นคำสั่งดังกล่าวควรล้มเหลวใช่ไหม

แต่รายงาน:

    Verify return code: 0 (ok)

ทำไม?

ฉันหมายถึงคำสั่งอะนาล็อก gnutls-cli ล้มเหลวตามที่คาดไว้:

$ { 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...

ทำ crosscheck เช่นใช้แทน--x509cafile /etc/ssl/certs/ca-certificates.crtgnutls-cli ฉันได้รับ:

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

(ซึ่งคาดว่ายัง)

Openssl s_client พิมพ์สำหรับ ca-certificate.crt:

    Verify return code: 0 (ok)

ผลลัพธ์เดียวกันสำหรับ TURKTRUST ...

ครั้งแรกที่ฉันสงสัยว่า OpenSSL ใช้การตั้งค่าเริ่มต้นสำหรับ-CApath(เช่น / etc / SSL / ใบรับรอง) - แต่เมื่อฉันstraceกระบวนการฉันเพียงแค่เห็นเพียงopensyscall CAfileสำหรับอาร์กิวเมนต์ของ

(การทดสอบทั้งหมดทำบนเซิร์ฟเวอร์ Ubuntu 10.04)

อัปเดต:ฉันได้คัดลอกใบรับรอง TURKTRUST ไปยังระบบ Fedora 20 และดำเนินการคำสั่ง openssl แรกแล้ว - ฉันได้รับผลลัพธ์ที่แตกต่าง:

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

ปรากฎว่าopenssl s_clientบน Ubuntu 10.04 ยังคงค้นหาตำแหน่งเริ่มต้นสำหรับใบรับรองที่ติดตั้งระบบแม้ว่า-CApath และ -CAfileจะมีการระบุ:

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

(เอาต์พุตแบบ strace)

ที่ไหน:

$ 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

ไดเรกทอรี/usr/lib/ssl/certsเป็น symlink ไปยัง/etc/ssl/certsบน Ubuntu 10.04 ดังนั้นopenสายจากบันทึก strace จะไม่ถูกเลือกเมื่อ grepping สำหรับ '/ etc / ssl' ...

แหล่ง

กำลังมองหาที่ 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_envSSL_CERT_DIR

วิธีแก้ปัญหา

ดังนั้นหนึ่งสามารถใช้วิธีแก้ปัญหาต่อไปนี้ภายใต้ Ubuntu 10.04 / openssl 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)

สถานการณ์ปัจจุบัน

นี่เป็นปัญหาของอูบุนตู ตัวอย่างเช่นด้วย openssl 1.0.1e ของ Fedora 20 หรือ openssl 1.1 ของ Fedora 29 การแก้ไขปัญหานี้ไม่จำเป็นเนื่องจากปัญหาไม่สามารถทำซ้ำได้ ซึ่งหมายความว่าเมื่อระบุตัวเลือกเช่น-CAfileหรือ-CApathไม่มีการเพิ่มไดเรกทอรีระบบใบรับรองเริ่มต้นลงในรายการค้นหาไดเรกทอรีในระบบ Fedora

ใน Ubuntu 16 ที่มี openssl 1.0.2g ปัญหายังคงมีอยู่

มันยังมีอยู่บน CentOS 7 ด้วย openssl-1.0.2k-16 - และน่าเสียดายที่วิธีแก้ปัญหาด้านบนไม่ได้ช่วยและ gnutls-3.3.29-8 ล้มเหลวเนื่องจาก TLS แพ็คเก็ต TLS ที่ไม่รู้จัก / ไม่คาดหมาย