Discourse の証明書更新失敗

バグ
1

ここから会話を続けます。

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）です。

「いいね！」 1
2

Let’s Encryptが必要としていたエンドポイントがリダイレクトされていた時期がありました。再構築すれば修正されます。

「いいね！」 5
3

証明書はアップデート後、どのくらいの期間で更新する必要がありますか？

4

記憶が正しければ、証明書は3か月間有効であり、それまでに自動更新を試みます。

「いいね！」 1
5

はい、仕組みはわかっています。

しかし、フォーラムソフトウェアを更新してから1日以上経ちますが、証明書はまだ更新されていないようです。失効まであと5日なので、早急に更新する必要があります。

Discourse の安定版を使用していますが、それが違いを生むでしょうか？エンドポイントの修正がバックポートされていない可能性はありますか？

6

私にとっては、再構築後に証明書はすぐに更新されました

7

Web経由で再構築しましたか、それともコマンドライン経由で再構築しましたか？

「いいね！」 1
8

はい、説明はここにありました。

「いいね！」 1
9

フォーラムは、コマンドラインの再構築を行った後、ついに証明書を更新しました。

「いいね！」 3
10

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 の後から始まったのかもしれませんか？

「いいね！」 1
11

最近記憶に残る有名なルートで別のエラーが発生しました。

最後に再構築したのはいつですか？

「いいね！」 1
12

私も同じです。証明書の有効期限切れに関する警告は受け取りませんでした。サーバーに入り、再構築を実行しました。/var/discourse % ./launcher rebuild でうまくいきました。

「いいね！」 2
13

バニラ 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 が更新を機能させる理由であるかどうかを確認することはできません。

14

もしこれがDiscourseだとお考えでしたら、githubのコミットに返信する、または新しい大きなレポートを開くべきです。

「いいね！」 1
15

LetsEncryptの更新が失敗することをここに確認します。私は何年もセルフホスト型のDiscourseを運用していますが、過去数ヶ月で非常に奇妙なことに2回連続で更新に失敗しました。2回目は今朝のことで、それで調査を始めました。

以下の2つのコミットに原因があることを突き止めました。

および関連するリンクされた行：

問題は2つあると思います。

第一に、return 301 https://${DISCOURSE_HOSTNAME}$request_uri; が $request_uri なしで return 301 https://<MY SERVER NAME> に変換されてしまいます。セルフホスト型インストールと、先週セットアップされた友人のセルフホスト型インストールで確認しました。Discourseのテンプレートがどのように機能するのか理解していないため、なぜそれが削除されるのか分かりません。

第二に、@lessLostが述べたように、301リダイレクトがlocationブロックの外にあります。サーバーレベルのリダイレクトはすべてのlocationブロックを上書きすると考えています。LetsEncryptは更新にhttpを使用します。しかし、curl -I http://YOUR_DOMAIN/.well-known/acme-challenge/test で試みると、期待される動作である404（リダイレクトではなく404を期待している）の代わりに、httpsへの301が返されます。

セルフホスト型インストールでは手動で修正しましたが、更新すると私の変更が上書きされると予想しています。残念ながら、テンプレートについて十分理解していないため、プルリクエストを送信できません（@pfaffman — そうでなければそれもやります）。

追記：

これは誤解だと思います —

LetsEncryptはデフォルトでhttpを使用すると確信しています（当然ながら、証明書が期限切れの場合、更新できないため！）。しかし、301をサーバーブロックレベルに配置すると、すべてのリクエストがhttpsに301されるようになり、この更新戦略と矛盾します。

「いいね！」 1
16

最後に再構築したのはいつですか？

17

今朝、目が覚めてからおよそ10分後、フォーラムを訪れたところ、証明書がまた期限切れになっていることに気づきました。（前回期限切れになったときも再構築で更新されたはずです。およそ3ヶ月前でしたか？）

18

それ以降に彼らがこの問題を修正する変更を加えたと思いますが、確認するのに3ヶ月かかるため、まだ結論は出ていません。現在の証明書の有効期限が切れる数週間前にリマインダーを設定するとよいかもしれません。

「いいね！」 1
19

これは事実ではありません。

  1. 上記のコメントに添付したリンクは git blame からのものです。ファイルの最新バージョン（関連行へのリンク）はこちらです：discourse_docker/templates/web.ssl.template.yml at 247c71a1e45d32b0b814a8e9d5fdaa4faaf727b9 · discourse/discourse_docker · GitHub
  2. 友人の新しいサイトのインストールは1週間前に行われたものです。上記のテンプレートの37行目には return 301 https://${DISCOURSE_HOSTNAME}$request_uri; とありますが、Discourse Dockerコンテナ内では、彼女のもの（および私のもの）の /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf は return 301 https://\u003cour_discourse_site\u003e; となっています。$request_uri が削除されていることに注目してください。（何が原因かはわかりませんが）。
  3. 調査の一環として、今朝シミュレートされた強制更新を実行しました。失敗しました。その後、/etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf を変更しました。成功しました！

実際にはこれで問題ありません。Discourseを更新するたびに 20-redirect-http-to-https.conf を手動で編集するだけです。このコメントに行き当たった人のために、実行するコマンドは次のとおりです。

cat > /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf << 'EOF'
server {
  listen 80;
  listen [::]:80;

  location ~ /.well-known {
    root /var/www/discourse/public;
    allow all;
  }

  location / {
    return 301 https://\u003cYOUR_FORUM_ADDRESS\u003e$request_uri;
  }
}
EOF

この失敗の正確な原因はわかりませんが、上記のconfを変更すると修正されることはわかっています。しかし、letsencryptの更新がサイレントに失敗しなくなったように通知も変更したので、事前に警告を受けることができます。お知らせまで！

「いいね！」 4
20

ご報告ありがとうございます。これは正当なものだと思います。

（ご参考 @featheredtoast）

「いいね！」 6