web-dev-qa-db-ja.com

ssl-cert-checkがLetsEncrypt証明書の正しい有効期限を取得していません

ドメイン証明書のリストを追跡するためにssl-cert-checkを使用しています。

Crontabで、静かに実行し、期限切れのドメインをメールで送信するように設定しましたが、デバッグに使用しているコマンドは次のとおりです。

ssl-cert-check -f ssldomains.txt -x 21 -i

ファイルを正しく読み取り、リスト全体の証明書を取得していますが、LetsEncrypt.orgによって発行された証明書の正しい有効期限を取得していないようです。

他の証明書プロバイダーは、この問題の影響を受けていないようです。

たとえば、ブラウザで検査したときに2017年3月24日に有効期限が切れる証明書は、2017年1月15日に有効期限が切れると報告されています。

私はnginxでサービスを提供しています。

CLIツールが間違った有効期限を取得するのはなぜですか？これを修正するにはどうすればよいですか？

nginxssl-certificatelets-encryptssl-certificate-renewal
2
Andy

これは [〜＃〜] sni [〜＃〜] の問題のようです。同じIPで複数のSSL証明書を提供する場合、クライアントは最初の要求とと​​もにホスト名を送信するため、サーバーは正しい証明書を提供できます。古いバージョンのssl-cert-checkはそれを行いません。この機能は、バージョン3.27で導入されました。

Ubuntuバージョン14.04と16.04はどちらもバージョン3.27を出荷していますが、このバージョンでは機能にバグがあるようです。関連するコードは基本的に2行あります。

TLSSERVERNAME="FALSE"

そして：

if [ "${TLSSERVERNAME}" = "TRUE" ]
then
     TLSFLAG="${TLSFLAG} -servername $1"
fi

ご覧のとおり、変数はFALSEに設定され、後でTRUEがチェックされますが、変更されることはありません。

GitHub （3.30）の現在のバージョンには、追加のコードブロックがあります。

if ${OPENSSL} s_client -h 2>&1 | grep '-servername' > /dev/null
then
    TLSSERVERNAME="TRUE"
else
    TLSSERVERNAME="FALSE"
fi

これにより、インストールされているopensslバージョンでサーバー名のサポートが確認されます。このブロックをローカルのUbuntuインストールのスクリプトに追加すると、結果は問題ありません。ブロックがないと、あなたと同じように間違った証明書を取得します。

したがって、これは作成者によって修正されたバグですが、Ubuntuリポジトリへの道はまだ見つかっていません。自分で修正して、次の更新後にリポジトリに修正バージョンが含まれることを期待するか、代わりにgithubのスクリプトを使用することができます。

2
Gerald Schneider