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サーバーの証明書はTURKTRUSTではなくDeutsche Telekom CAによって認証されているため、上記のコマンドは失敗するはずです。

しかし、それは報告します：

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

クロスチェックを実行します。つまり、代わり--x509cafile /etc/ssl/certs/ca-certificates.crtにgnutls-cliを使用します。

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

（これも予想されます）

cas-certificates.crtのopenssl s_clientプリント：

    Verify return code: 0 (ok)

TURKTRUSTと同じ結果...

最初に私はのためのデフォルト設定を使用してOpenSSLを疑われる-CApath（つまりは/ etc / sslの/ certsの） -私はときstrace、プロセスは、私はちょうどちょうど参照openの引数のシステムコールを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は/etc/ssl/certsUbuntu 10.04のシンボリックリンクであるため、open「/ etc / ssl」をgreppingするときにstraceログの行が選択されません...

ソース

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 / 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)

現在の状況

これはUbuntuの問題です。たとえば、Fedora 20のopenssl 1.0.1eまたはFedora 29のopenssl 1.1.1では、問題を再現できないため、この回避策は必要ありません。つまり、-CAfileまたはのようなオプションを指定すると、-CApathデフォルトの証明書システムディレクトリはFedoraシステムのディレクトリ検索リストに追加されません。

openssl 1.0.2gがインストールされたUbuntu 16では、問題はまだ存在しています。

それはまた、openssl-1.0.2k-16を備えたCentOS 7にも存在します-残念ながら、上記の回避策はそこで助けにはならず、gnutls-3.3.29-8は未知の/予期しないTLSパケットタイプが原因で失敗します。