Mengapa openssl s_client memverifikasi sertifikat terhadap CAfile yang tidak cocok?

Saya mencoba membuat kesalahan verifikasi sertifikat dengan openssl s_clientseperti ini:

$ 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

Sertifikat server web.de disertifikasi oleh Deutsche Telekom CA, bukan TURKTRUST, sehingga perintah di atas gagal, kan?

Tapi itu melaporkan:

    Verify return code: 0 (ok)

Mengapa?

Maksud saya perintah gnutls-cli analog gagal seperti yang diharapkan:

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

Melakukan crosscheck, yaitu menggunakan --x509cafile /etc/ssl/certs/ca-certificates.crtgnutls-cli sebagai gantinya :

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

(yang juga diharapkan)

Openssl s_client mencetak untuk ca-Certificate.crt:

    Verify return code: 0 (ok)

Hasil yang sama seperti untuk TURKTRUST ...

Pertama saya curiga openssl menggunakan pengaturan default untuk -CApath(yaitu / etc / ssl / certs) - tetapi ketika saya straceprosesnya saya hanya melihat opensyscall untuk argumen dari CAfile.

(semua tes dilakukan pada server Ubuntu 10.04)

Pembaruan: Saya telah menyalin sertifikat TURKTRUST ke sistem Fedora 20 dan menjalankan pernyataan openssl pertama - di sana saya mendapatkan hasil yang berbeda:

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

Ternyata openssl s_clientpada Ubuntu 10,04 masih menanyakan lokasi default untuk sertifikat yang dipasang sistem, bahkan jika -CApath dan -CAfile ditentukan:

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

(keluaran strace)

Dimana:

$ 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

Direktori /usr/lib/ssl/certsini adalah symlink ke /etc/ssl/certsUbuntu 10,04, sehingga opengaris dari strace log tidak dipilih ketika menerima '/ etc / ssl' ...

Sumber

Melihat openssl-0.9.8k, sumber masalah ini terletak di 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);

Di mana X509_get_default_cert_dirkembali /usr/lib/ssl/certsdan X509_get_default_cert_dir_envkembali SSL_CERT_DIR.

Penanganan masalah

Dengan demikian, seseorang dapat menggunakan solusi berikut di bawah Ubuntu 10.04 / openssl 0.9.8k untuk mendapatkan perilaku yang diharapkan:

$ 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

Dan dengan verifikasi gagal:

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

Situasi saat ini

Ini adalah masalah Ubuntu. Misalnya, dengan Fedora 20's openssl 1.0.1e atau Fedora 29's openssl 1.1.1, solusi ini tidak diperlukan, karena masalah tidak dapat direproduksi. Itu berarti ketika menentukan opsi seperti -CAfileatau -CApath, tidak ada direktori sistem sertifikat default ditambahkan ke daftar pencarian direktori pada sistem Fedora.

Di Ubuntu 16 dengan openssl 1.0.2g masalah masih ada.

Ini juga hadir pada CentOS 7 dengan openssl-1.0.2k-16 - dan sayangnya, solusi di atas tidak membantu di sana dan gnutls-3.3.29-8 gagal karena jenis paket TLS yang tidak diketahui / tidak terduga.