ここから会話を続けます。
Redsiftから証明書が1週間後に失効するというリマインダーを受け取ったのは今回が初めてです。通常、Discourseは証明書を時間前に更新します。今回はそうではありませんでした。再構築を開始する前に（これにより問題が解決するはずです）、@Falco、証明書が更新されなかった根本原因を特定するために、確認してここに投稿してほしいことはありますか？
ルート証明書はISRGX1で、失効する証明書の情報は次のとおりです。
| 共通名 (CN) | E6 |
|---|---|
| 組織 (O) | Let’s Encrypt |
| 組織単位 (OU) | 証明書に含まれていません |
| 発行日 | 2025年7月16日水曜日 午後7時36分45秒 |
| 失効日 | 2025年10月14日火曜日 午後7時36分44秒 |
現在のビルドは3.6.0.beta1-dev（7ee52c8f85）です。
Let’s Encryptが必要としていたエンドポイントがリダイレクトされていた時期がありました。再構築すれば修正されます。
証明書はアップデート後、どのくらいの期間で更新する必要がありますか？
記憶が正しければ、証明書は3か月間有効であり、それまでに自動更新を試みます。
はい、仕組みはわかっています。
しかし、フォーラムソフトウェアを更新してから1日以上経ちますが、証明書はまだ更新されていないようです。失効まであと5日なので、早急に更新する必要があります。
Discourse の安定版を使用していますが、それが違いを生むでしょうか？エンドポイントの修正がバックポートされていない可能性はありますか？
私にとっては、再構築後に証明書はすぐに更新されました
Web経由で再構築しましたか、それともコマンドライン経由で再構築しましたか？
はい、説明はここにありました。
フォーラムは、コマンドラインの再構築を行った後、ついに証明書を更新しました。
SSLの更新がされないという同じ経験をしました。
web.ssl.templateがdiscourse-dockerで正しく動作しているか、誰かに再確認していただけると幸いです。Let’s Encryptが使用する /.well-known/ URLにポート80が実際にサービスを提供しておらず、/var/www/discourse/public/.well-known/ に手動で配置したテストファイルを含むすべてのURLがSSLにリダイレクトされているように見えました。アプリコンテナ内で直接 /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf を編集する必要がありました。
これは、discourse-dockerのコミット ae4887a の後から始まったのかもしれませんか？
最近記憶に残る有名なルートで別のエラーが発生しました。
最後に再構築したのはいつですか？
私も同じです。証明書の有効期限切れに関する警告は受け取りませんでした。サーバーに入り、再構築を実行しました。/var/discourse % ./launcher rebuild でうまくいきました。
バニラ nginx インストール (1.18.0 ですが、1.26.3 でも同じだと思います) でのテストでは、location の外にある nginx 設定行 return 301 https://thehostname$request_uri; は、キャッチオールとして機能するのではなく、それより前の任意の location ブロックを完全にオーバーライドします。/.well-known/ は、サーバーブロックの最後に / のような別の location のための 301 リダイレクトが具体的に指定されていない限り、ポート 80 では提供されない可能性があります。これは、この Stack Overflow の投稿 と同じ問題かもしれません。
rebuild が機能するのは嬉しいですが、証明書はすでに更新されていたため、証明書が期限切れになった場合に rebuild が Let’s Encrypt の検証サーバーがそこに到達できるようにするかどうかを確認できませんでした。おそらく、rebuild は、テンプレート行が配置される前、または同様の理由で証明書の更新を開始するのではなく、テンプレートを修正するのではなく、rebuild が更新を機能させる理由であるかどうかを確認することはできません。
もしこれがDiscourseだとお考えでしたら、githubのコミットに返信する、または新しい大きなレポートを開くべきです。