はい、HTTP-01チャレンジはCloudflareと「オレンジ色の雲」モードで連携して機能します。しかし、HTTPSでは機能しません。HTTP-01チャレンジはポート80でのみ機能し、次のようになります。
Cloudflareを実行している多くの人が、CloudflareをHTTPからHTTPSへの自動リダイレクトに設定しており、それによりオリジンサーバーのポート80が利用できなくなり、それによりHTTP-01チャレンジが機能しなくなります。
したがって、これらのリダイレクトを有効にしない場合、機能します。
したがって、厳密に言えばこれは真実ではありません。
Cloudflareがオリジンサーバーに到達する前にポート80のトラフィックをリダイレクトするように設定されている場合、Let’s Encryptは失敗します。
同意しますが、ITセキュリティがこれまで以上に重要になり、人々がZero Trust製品をより多く利用するようになるにつれて、CF Tunnelもその一部であるため、この種のテクノロジーの利用が増加すると予想され、それゆえに私が提起しました。
LE の HTTP-01 チャレンジがどのように機能するかを誤解されていると思います。
LE クライアントの certbot またはその他のバリアントが、ほとんどの場合、ウェブサーバーの .well-known サブフォルダーに配置したトークンを探します。
しかし、ポート 80 でリクエストを開始するようにハードコーディングされているわけではなく、HTTP コードのリダイレクトを無視し、トークンが見つからない場合は outright に失敗します。
HTTP-01 チャレンジは HTTP リダイレクト (301 および 302) をフォローできるため、443 および HTTPS を介して .well-known フォルダーを読み取ることができます。
Cloudflare Universal SSL WITH Redirect (および Cloudflare Tunnel) で機能する理由は、Cloudflare がポート 80 でウェブサーバーの代わりにリクエストに応答し、リクエストを 443 にリダイレクトし、そこで LE がトークンを読み取ることができ、CA が証明書を発行できるためです。
フローのハイレベル図:
Certbot が HTTP-01 を開始
→ CA に証明書リクエストを POST し、トークンを .well-known に配置
→ CA が FQDN ポート 80 でトークンの GET を開始
→ CF がポート 443 にリダイレクトし、Universal SSL 証明書でリクエストを保護
→ リクエストはウェブサーバー自体に転送されます (CF Tunnel または直接経由)
→ CA はポート 443 が HTTP およびポート 80 と同じ方法でトークンを提示できるため、.well-known でトークンを取得できます
→ CA が RAW 証明書データを POST し、Certbot がファイルを生成します
Cloudflare の実装方法に関する最新の詳細情報やガイドを探して、3 月に トピック を開始しました。
まだ探しています 
CDN として Cloudfront を使用していますが、Cloudflare が提供する DDoS 保護を追加したいと考えています。私たちはかなりの攻撃を受けています 
かなりよく理解していると思います。おっしゃる通りHTTPSにリダイレクトすることは可能ですが、オリジンサーバーに有効な証明書がないため、Cloudflareの設定やウェブサーバーの設定によってそれが機能するかどうかが決まります。
はい、別のポートにリダイレクトすることは可能ですが、HTTP-01チャレンジは常にポート80で開始する必要があります。
Challenge Types - Let's Encrypt を参照してください。
HTTP-01チャレンジはポート80でのみ実行できます。クライアントが任意のポートを指定できるようにすると、チャレンジのセキュリティが低下するため、ACME標準では許可されていません。
同意します。私は単に、それが絶対に機能しないというあなたの不正確さを指摘しただけです。
ここで引用された私の文章は、議論の状況を誤解させ、別の意味合いを暗示させる、非常に悪意のあるものです。私の完全な文章は以下の通りです。
そして、私の文章の重要な部分は、「ポート80でリクエストを開始するようにハードコードされている」ことと、「HTTPリダイレクトはすべて無視する」ことと、「outright に失敗する」ことの組み合わせでした。なぜなら、あなたは次のように言ったからです。
そして、これはHTTP-01チャレンジが失敗する理由がリダイレクトだけであると示唆していますが、それは真実ではありません。
また、厳密に言えば、リダイレクトはポート80を「無効」にするわけではありません。
悪意や意図はありません。
ホスト名に向けられたすべてのトラフィックに対して、オリジンサーバーのポート80を利用不可にします。
このトピックでの現在の会話のトーンは好きではないので、ウォッチを解除します。
Discourseと組み合わせたCloudflareに関する私の意見は、「多くの人が正しく設定できないため、一般的には有効にしないことをお勧めします。DDoS保護のために使用したい場合は、非常に特定のНастройкиのみで有効にすることをお勧めします。」と要約できます。
明確なご意見ありがとうございます。
これはまたくだらない質問かもしれませんが、フィンランドのオーディエンスのみを対象としているため、Cloudflareを使用する理由がありません。そのため、評判でしか知りません。
しかし、その唯一の利点がDDoS攻撃の停止である場合、そしてDDoS攻撃は主に次のような多数の呼び出しを意味します。
それなら、Discourseの前にNginxを配置して、既知のユーザーエージェントをそこで停止するのはなぜですか？ Fail2banと組み合わせると、負荷が約90％削減されます（もちろん、これは推測の統計ですが、それでもかなりの量です）。
この議論は非常に価値があります。中国のウェブサイト管理者にとって、Flare は中国のユーザーが外部と正常にデータを交換できることを意味するのでしょうか。私はしばらく前にテストを行いました。Orange Cloud を使用せず、中国から他の国のサーバーにアクセスすると、ネットワークのジッターが非常に深刻になります。悪質なのは、中国でフォーラムを運営することは厳格な検閲の対象となることです。政治的ではないフォーラムを運営していても、私は苦しみました。ウェブサイトのサーバーは中国国外にあると仮定する必要があります。したがって、Discourse を使用してフォーラムを作成する場合、Cloud Flare を使用できるかどうかを検討する必要があります。