☰

openssl s_clientが一致しないCAファイルに対して証明書を検証するのはなぜですか？

tag-icon • tag-icon openssl certificates gnutls
openssl s_clientが一致しないCAファイルに対して証明書を検証するのはなぜですか？

次の証明書検証エラーを生成しようとしています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...

代わりにgnutls-cliを使用してもクロスチェックを行うと、次のような結果が--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 は ca-certificates.crt を出力します。

    Verify return code: 0 (ok)

TURKTRUSTと同じ結果...

まず、opensslがデフォルト設定-CApath（例：/etc/ssl/certs）を使用すると疑われました。しかし、プロセスを進めるstraceと。openCAfile

（すべてのテストはUbuntu 10.04サーバーで行われました）

修正する:TURKTRUST 証明書を Fedora 20 システムにコピーし、最初の openssl ステートメントを実行しました。そこから別の結果を得ました。

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

ベストアンサー1

openssl s_clientUbuntu 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

ディレクトリはUbuntu 10.04のシンボリックリンクなので、/usr/lib/ssl/certsgrep '/etc/ssl'.../etc/ssl/certsopen

源泉

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

現状

これは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にも存在します。残念ながら、上記の回避策はこの問題には役立ちません。不明または予期しないTLSパケットタイプが原因でgnutls-3.3.29-8が失敗します。

おすすめ記事