LetsEncrypt は www なしで動作するが、www ありでは動作しない

サポート
1

どなたかアドバイスをいただければ幸いです。状況をご説明します。

私は以前、ドメイン hostballs[.]com に Discourse を複数回セットアップしました。その際、www[.]hostballs[.]com を訪問すると hostballs[.]com に適切にリダイレクトされていました。これは、Let’s Encrypt の証明書が www あり・なしの両方をカバーしているためです。Discourse の Let’s Encrypt 実装におけるデフォルトの標準的な動作として、私はこのように理解しています。

しかし、現在の新しい Discourse インストールでは、設定された URL（www なし）に対して SSL が設定されていますが、www はカバーされていません。そのため、www[.]hostballs[.]com を訪問するとリダイレクトされず、SSL エラーが表示されてしまいます。デフォルトの動作がこれと異なることを知っており、Discourse のインストールは非常に管理されているため、certbot に飛びついて手動で全てやり直すことはしたくありません（そうすれば定期的な更新が楽しくなるでしょうか）。そのため、最適な次の一手がわかりません。

この問題を解決しようとして、app.yml から ssl と Let’s Encrypt のテンプレート、および Let’s Encrypt のメールアドレスをコメントアウトしました。その後、/shared/standalone から letsencrypt と ssl ディレクトリを削除しました。SSL なしでサイトを再構築し、その後 app.yml でそれらのオプションを再度有効にして再構築し、新しい SSL 証明書と設定を生成しました。これは成功しましたが、www の問題は依然として解決されませんでした。

同様の状況に直面し、解決策を見つけた方はいますか？

2

もちろん！少し手間がかかりますが、基本的で非常に一般的なユースケースです。以下をご覧ください：

次にこちら：

3

上記のアドバイスが難しすぎる場合は、簡単な DNS リダイレクトを設定することもできます。ほとんどのレジストラでこの機能を提供しています。

Discourse は複数の URL で公開することはできません。ルートレコード（www ありなし）と www の ‘A’ レコードは別々のアドレスです。サイトに FQDN を指定すると、追加のアドレスはすべてリダイレクトで処理する必要があります。

4

すでに提供されている提案のいずれも気に入らない場合は、www.example.com を使用し、http://forcewww.com/ を使って www サイトにリダイレクトさせることができます。

5

みなさん、ありがとうございます。将来他の誰かの助けになるかもしれないいくつかの詳細を説明させていただきます。

この問題は、あるユーザーから「www を訪れると動作せず、証明書エラーが表示される」と報告されたことに端を発しました。報告スレッドで提供された https リンクを直接訪れてみると、私も同じエラーに遭遇しました。以前は www を使用して問題なくルートドメインにリダイレクトされていましたが、今回はそうなりませんでした。このことから、最近の移行後にインストールが何らかの形で破損し、新しい Discourse インストールのデフォルトの動作に従っていないと結論づけました。

そこで、www がデフォルトで動作することを実証するために、新しいドメインに Discourse の新規インストールを行いました。まずドメインにアクセスし、アドレスバーの URL を編集して先頭に「www.」を追加しました。すると、予想通り問題なくルートドメインにリダイレクトされました。次に、もう一つ試してみようと思い、手動で「https://」を先頭に追加してアクセスしました。すると、同じ証明書エラーが発生しました。

つまり、Discourse の Let’s Encrypt 実装において www の署名がデフォルトの動作であると私が誤解していたのは、ブラウザがデフォルトでポート 80 を使用し、アドレスバーで URL を書き換える際に http/https の部分が表示されなくなっていたことが原因だった可能性があります。

これが現時点での私の最善の判断です。

6

はい、サーバーの IP アドレスのポート 80 にアクセスするすべてのトラフィックは、実際の FQDN へ HTTPS 経由でリダイレクトされます。www は特別なケースではありません。

7

ルートドメインを使用しており、別の Web サーバーでリダイレクトを管理したり、複雑化したりすることなく、www を LE で署名して適切な https リダイレクトを実現したい場合の最も簡単な解決策は以下の通りです。

これを:

issue_cert() {
LE_WORKING_DIR=“${LETSENCRYPT_DIR}” $$ENV_LETSENCRYPT_DIR/acme.sh --issue $2 -d $$ENV_DISCOURSE_HOSTNAME --keylength $1 -w /var/www/discourse/public
}

これに変更します:

issue_cert() {
LE_WORKING_DIR=“${LETSENCRYPT_DIR}” $$ENV_LETSENCRYPT_DIR/acme.sh --issue $2 -d $$ENV_DISCOURSE_HOSTNAME -d www.$$ENV_DISCOURSE_HOSTNAME --keylength $1 -w /var/www/discourse/public
}

ファイル:
/var/discourse/templates/web.letsencrypt.ssl.template.yml

その後、もちろん:

./var/discourse/launcher rebuild app

8

それは解決策ではありません。テンプレートが更新されるたびに変更が消去されてしまうため、それだけで推奨されません。

コンテナ内のファイルを変更したい場合は、app.yml のフックを使用してください。

9

ああ、アップデートで壊れる可能性を避けつつそれを実現する方法は見当たらないな。これは、コミュニティ用に独自ドメインを使い、不要なサブドメインを避けたい人々の苦境だ。もちろん、別の場所で別のウェブサーバーを動かす場合を除いては。

10

検索機能を利用している場合、証明書登録の修正に関するガイドが既に存在します。

11

さて、すでにファイルの変更によって中断された試みを一つ確認しました。その結果、app.yml でファイルを変更する設定が壊れてしまいました：

ファイルを直接編集するか、app.yml を介して後から編集するかに関わらず、更新によってそのファイルが変更され、編集方法が破綻する可能性があります。

12

私の言いたいのは、そのテンプレートに変更を加えると、再び壊れてしまうということです。ここ数年、PUPS/hooks 方式を破綻させた変更は 1 つだけで、それは ECC サポートの導入でした。