Tại sao openssl s_client xác minh một chứng chỉ chống lại CAfile không khớp?

Tôi đang cố gắng đưa ra một lỗi xác minh chứng chỉ openssl s_clientnhư thế này:

$ 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

Chứng chỉ của máy chủ web.de được chứng nhận bởi Deutsche Telekom CA, không phải TURKTRUST, do đó lệnh trên sẽ thất bại, phải không?

Nhưng nó báo cáo:

    Verify return code: 0 (ok)

Tại sao?

Tôi có nghĩa là một lệnh gnutls-cli tương tự thất bại như mong đợi:

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

Thực hiện kiểm tra chéo, tức là sử dụng thay vì --x509cafile /etc/ssl/certs/ca-certificates.crtbằng gnutls-cli tôi nhận được:

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

(cũng được dự kiến)

In Openssl s_client cho ca-cert.crt:

    Verify return code: 0 (ok)

Kết quả tương tự như đối với TURKTRUST ...

Đầu tiên tôi nghi ngờ openssl bằng cách sử dụng cài đặt mặc định cho -CApath(tức là / etc / ssl / certs) - nhưng khi tôi stracexử lý, tôi chỉ thấy tòa opennhà của đối số CAfile.

(tất cả các thử nghiệm được thực hiện trên máy chủ Ubuntu 10.04)

Cập nhật: Tôi đã sao chép chứng chỉ TURKTRUST sang hệ thống Fedora 20 và thực hiện câu lệnh openssl đầu tiên - ở đó tôi nhận được một kết quả khác:

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

Hóa ra, openssl s_clienttrên Ubuntu 10.04 vẫn truy vấn vị trí mặc định cho các chứng chỉ được cài đặt hệ thống, ngay cả khi -CApath và -CAfile được chỉ định:

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

(đầu ra strace)

Ở đâu:

$ 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

Thư mục /usr/lib/ssl/certslà một liên kết tượng trưng đến /etc/ssl/certstrên Ubuntu 10.04, do đó, opendòng từ nhật ký strace không được chọn khi grepping cho '/ etc / ssl' ...

Nguồn

Nhìn vào openssl-0.9.8k, nguồn gốc của vấn đề này nằm ở 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);

Nơi X509_get_default_cert_dirtrả lại /usr/lib/ssl/certsvà X509_get_default_cert_dir_envtrả lại SSL_CERT_DIR.

Giải pháp thay thế

Do đó, người ta có thể sử dụng cách giải quyết sau trong Ubuntu 10.04 / openssl 0.9.8k để có được hành vi mong đợi:

$ 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

Và với việc xác minh thất bại:

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

Tình hình hiện tại

Đây là một vấn đề Ubuntu. Ví dụ: với openssl 1.0.1e của Fedora 20 hoặc openssl 1.1.1 của Fedora 29, cách giải quyết này là không cần thiết, vì vấn đề không thể được sao chép. Điều đó có nghĩa là khi chỉ định một tùy chọn như -CAfilehoặc -CApath, không có thư mục hệ thống chứng chỉ mặc định nào được thêm vào danh sách tìm kiếm thư mục trên các hệ thống Fedora.

Trên Ubuntu 16 với openssl 1.0.2g, vấn đề vẫn còn.

Nó cũng có mặt trên CentOS 7 với openssl-1.0.2k-16 - và thật không may, cách giải quyết ở trên không giúp được gì ở đó và gnutls-3.3.29-8 không thành công do các loại gói TLS không xác định / không mong muốn.