次の証明書検証エラーを生成しようとしています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
と。open
CAfile
(すべてのテストはUbuntu 10.04サーバーで行われました)
修正する:TURKTRUST 証明書を Fedora 20 システムにコピーし、最初の openssl ステートメントを実行しました。そこから別の結果を得ました。
Verify return code: 19 (self signed certificate in certificate chain)
答え1
openssl s_client
Ubuntu 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/certs
grep '/etc/ssl'.../etc/ssl/certs
open
源泉
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にも存在します。残念ながら、上記の回避策はこの問題には役立ちません。不明または予期しないTLSパケットタイプが原因でgnutls-3.3.29-8が失敗します。