いいえ、追加のインストールは不要です。
また、追加する必要があったブロックは以下の通りです：
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d mywebsite.org --keylength"
（HTTP から HTTPS へのリダイレクトは、nginx を含む他の 2 つの replace ブロックなしでも正常に動作しているようです）
ついに「複数のドメインで Let’s Encrypt を設定する」と「単一/複数のドメインを Discourse インスタンスにリダイレクトする」というガイドを読み終える時間が見つかりました。
あなたのものよりも containers/app.yml ファイルに多くの設定を追加しましたが、ほぼすべてが正しく動作しています。
私の Discourse は www. サブドメインでホストされており、目的は apex ドメインからの http および https 要求を www サブドメインにリダイレクトすることでした。これは現在機能していますが、https://mydomain.com にアクセスするとリダイレクトは行われるものの、Chrome のコンソールに以下の警告が表示されます。
Redirecting navigation example.com -> www.example.com because the server presented a certificate valid for www.example.com but not for example.com. To disable such redirects launch Chrome with the following flag: --disable-features=SSLCommonNameMismatchHandling
私の app.yml の追加設定は以下の通りです。
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /return 301 https.+/
to: |
return 301 https://$host$request_uri;
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /gzip on;[^\}]+\}/m
to: |
gzip on;
add_header Strict-Transport-Security 'max-age=31536000'; # remember the certificate for a year and automatically connect to HTTPS for this domain
after_web_config:
- replace:
filename: /etc/nginx/nginx.conf
from: /sendfile.+on;/
to: |
server_names_hash_bucket_size 64;
sendfile on;
- file:
path: /etc/nginx/conf.d/discourse_redirect_1.conf
contents: |
server {
listen 80;
listen 443 ssl;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
これは正しいでしょうか？もし正しい場合、証明書の名前不一致の問題に対する解決策はありますか？
編集：www サブドメイン用の A レコードと、@ を使用して apex ドメインへのすべての要求を捕捉するもう一つの A レコードの 2 つを持っています。どちらも Digital Ocean のドロップレットの IP を指しています。これも正しいと想定してよいでしょうか？
ありがとうございます。
Cloudflareがレジストラでなくても、無料で実装可能です。HTTPSに対応しており、Discourseのインストールに追加の複雑さは一切ありません。
ありがとうございます。現在 Cloudflare は使用していないため、それらにはまだ出会っていませんでした。別の方法を取り、上記のガイドに従って、問題の大部分を解決することができました。私が上記の返信を投稿したまさにその瞬間に、あなたの投稿がありました。
このウェブサイト をご確認ください。必要なすべてのリダイレクトが設定されていますか？これは上記の replace ブロック 1 つと、この DNS 設定（メールの TXT レコードのみ伏字にしています）で実現されています：
コンソールには警告は表示されません。
はい、Let’s Encrypt の設定が変更された際に問題が発生する可能性があることを想定しておいてください。
Let’s Encrypt が楕円曲線暗号のサポートを追加した際、上記の手法は数週間機能しませんでした。
唯一の違いは、私の DNS に CAA レコードがないことです。それと同じ値を使って追加します。
あなたの Discourse ホスト名が www.example.com であると仮定して、https://example.com にアクセスしたときに警告が表示されないことは確かでしょうか？
この警告は、Android 版 Chrome ではさらに深刻で、サイトへのアクセスを完全にブロックし、リダイレクトも行いません。
今はついていけていません 
何に注意すべきか、あるいは修正の準備が必要でしょうか？
その通りです。
はい、確実です。コンソールには警告は表示されません。
問題が見つかったと思います。私は以下のようにしていました：
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
しかし、本来こうあるべきでした：
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com --keylength"
最後の行に注目してください。私は example.com と www.example.com の両方を指定してしまっていました。
また、return 301 https://$host$request_uri; を return 301 $scheme://$host$request_uri; に変更し、再ビルドを行ったところ、どうやら正常に動作しているようです。
ただ、@Stephen さんが指摘されていたように、Let’s Encrypt の設定変更時に問題が発生する可能性が気になります。
昨年9月9日の変更が、現在採用しているアプローチを無効化しました。実装が標準的なインストール手順の範囲外だったため、解決策が公開されたのは10月31日までかかりました。参照されているトピックとウィキの編集履歴を確認いただければ、その経緯は明確に記録されています。
追加設定に深く立ち入る必要がある作業ではないため、その方法はお勧めしません。他方、Let’s Encrypt が変更され影響を受けた場合は、このトピックを再度参照いただくよう案内できます。