verify error:num=10:certificate has expired

s_client は「verify error:num=10:certificate has expired」に続けて「notAfter=…」を出力し、openssl verify は「error 10 at <depth> depth lookup: certificate has expired」と出力します。有効期間の開始前の証明書では、エラー 9「certificate is not yet valid」になります。

OpenSSL CLI (openssl s_client / openssl verify) — X509_V_ERR_CERT_HAS_EXPIRED

このエラーの意味

OpenSSL のエラー 10（X509_V_ERR_CERT_HAS_EXPIRED）は、チェーン内のある証明書の notAfter の日時が、検証時刻から見て過去であることを示します。検証時刻は、-attime を指定しない限りローカルの時計の時刻です。エラーと一緒に出力される depth の行から、どの証明書かがわかります。0 はサーバー自身の証明書、それより大きい数字は中間証明書です。

発生する理由

• サーバーの証明書が期限切れになっている（depth 0）

  よくある

  更新に失敗したか、更新した証明書がサーバーやロードバランサーに読み込まれていないかのどちらかです。

• 返されるチェーン内の中間証明書が期限切れになっている

  ときどき

  CA が新しいものに移行した後も古いチェーンファイルを使い続けていると、期限切れの中間証明書やクロス署名の証明書が送信され続けます。チェーンを CA の現在のものに置き換えてください。

• 検証するマシンの時計が進んでいる

  ときどき

  時計が未来の時刻を指していると、有効な証明書が期限切れに見えます。-attime を使うと、時計の問題と実際の期限切れを切り分けやすくなります。

修正方法

1. 1.

   期限切れの証明書を特定する

   depth と notAfter の行を確認してください。-checkend を使うと、証明書ファイルが指定した秒数以内に期限切れになるかどうかがわかるため、監視に便利です。

   # The depth printed with the error identifies the certificate; s_client also prints notAfter
   echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>&1 | grep -E '^depth|verify error|notAfter'
   # Check a file, and whether it expires within 30 days (exit 1 = yes)
   openssl x509 -in server.pem -noout -enddate -checkend 2592000

2. 2.

   指定した時刻で検証する

   openssl verify -attime <unix time> を使うと、その時点でチェーンが有効だったかどうかがわかり、期限切れとほかのエラーを切り分けられます。

   # Would the chain verify at another moment? (useful to separate clock problems)
   openssl verify -attime "$(date -d '2025-02-01' +%s)" -CAfile root.pem server.pem

3. 3.

   更新してリロードする

   証明書を更新し、TLS を終端しているプロセスや機器をすべてリロードしてから、ネットワーク側から新しい有効期限を確認してください。

   sudo certbot renew && sudo systemctl reload nginx
   echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null | openssl x509 -noout -enddate

← 署名エラーデータベースをすべて見る