Discourse のインストールまたは再構築時に、有効な Let’s Encrypt 証明書が以下のエラーで拒否される場合があります。
C=US, O=Let's Encrypt, CN=YR2
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
私は RSA 発行が成功した直後にこれを再現しました。このチェックの失敗により、不要な --force リクエストがトリガーされ、HTTP 429 / rateLimited / “too many certificates” を引き起こす可能性があります。私の環境では、その後 ECDSA 発行がブロックされ、HTTPS が起動しませんでした。
影響を受けるチェーンの場合、証明書がまだ有効であっても、再構築やコンテナの再起動ごとに RSA と ECDSA 証明書の不要な強制再発行がトリガーされる可能性があります。再発行の成功は Let’s Encrypt のクォータを消費するため、繰り返される再構築や再起動により、レート制限に素早く到達する可能性があります。
すでにインストール済みの証明書で HTTPS が動作し続ける間、これは気づかれにくいことがあります。同じホスト名でインスタンスを削除して再インストールしても、そのクォータはリセットされません。新しいインストールに必要な証明書が欠けている場合、レート制限された発行により HTTPS の起動が妨げられる可能性があります。
修正方法
templates/web.letsencrypt.ssl.template.yml の cert_exists() 内で、以下を置き換えます：
- openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer
+ openssl verify -untrusted ca.cer fullchain.cer
関数の残りの部分は変更しないでください。修正されたテンプレートは、/usr/local/bin/letsencrypt を更新するために、次のコンテナ再構築に含める必要があります。
すでにレート制限に達している場合、このパッチはクォータをリセットしません。修正を適用し、さらに発行を試みる前に retry after の時間を遵守してください。
チェーン検証の問題の確認
コンテナ内の影響を受ける証明書ディレクトリ（/shared/letsencrypt/<hostname> または <hostname>_ecc）から、以下を比較してください：
openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer
openssl verify -untrusted ca.cer fullchain.cer
再現されたケースでは、最初のコマンドはエラー 2 で失敗し、2 つ目のコマンドは以下を返します：
fullchain.cer: OK
原因と検証
openssl x509 -in ca.cer は、発行者バンドルから最初の証明書のみを読み取ります。観察された YR2 チェーンでは、ISRG Root X1 に到達するために必要なクロス署名された Root YR が欠落します。
-untrusted ca.cer は、信頼アンカーをシステムストアに保ちつつ、完全な発行者バンドルを供給するため、2021 年の修正 (#576) の意図を維持します。
私はコンテナ内で実際の RSA と ECDSA チェーンを検証しました。パッチを適用した完全な再構築では、既存の両方の証明書が再利用されました：2 つの Skip メッセージ、両方のチェーンがインストールされ、nginx -t がパスしました。
