これはDiscourseインスタンスを停止させているようです。「Oops…」という高負荷のメッセージを越えられません。
Create new order error. Le_OrderFinalize not found. {
"type": "urn:ietf:params:acme:error:rateLimited",
"detail": "too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after ....
理由はどうあれ、他の人もこれに遭遇しているようですが、解決策はありますか？
数時間待ってから再試行するだけで済むと思います。記憶が正しければ、レートリミットは1時間ごとにリセットされます。また、ドメインに www プレフィックスをリクエストして新しい証明書を取得し、カウントをリセットすることもできます。
そのヒントをありがとうございます。数時間経っているので、今から再構築を試してみます。
@Ed_S のこちらの投稿によると、待機期間は7日間のようです！
再構築（Rebuild）では解決しませんでした。
www を追加して新しい証明書を取得するためにウィザードセットアップを再実行しました。一見するとうまくいったように見えますが、443 がアクセスできないというエラーを回避するために、@pfaffman の提案に従って接続チェックを無効にする必要がありました。
しかし、現在は証明書の読み込みに失敗しています。ログには以下が出力されています：
...PEM_read_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expecting: TRUSTED CERTIFICATE)
これは 443/80 ポートがクローズされている問題に関連している可能性があります。これは私が確認している別の一般的な問題でもあります。
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 72556/docker-proxy
tcp6 0 0 :::443 :::* LISTEN 72564/docker-proxy
外部のチェッカーでポートをスキャンすると、クローズ状態と表示されます 
OK、復元されたDBバージョンを備えた別のサーバーに戻しました。そのサーバーではポート80/443が開いていました。続行する前に、外部のポートスキャナーで確認しました。
./launcher discourse-setup を実行すると、ポート443がアクセスできないというエラーが発生しました。
そこでサーバーを再スキャンし、ポート80と443を確認したところ、今度は閉じていると表示されました。
ウィザードを実行する行為自体がポートを閉じてしまうようです?!
ウィザードは複数のドメイン名をサポートしていないと思いますが、最後に使ったのがかなり前なので確実ではありません。
おそらくこれが問題の原因です。DNS が設定されていないか、受信トラフィックがブロックされている可能性があります。
こんにちは、ありがとうございます。はい、別のトピックで見つけたアドバイスに従って「grey clouds」を元に戻したことで、上記の PEM_red… エラーを解決することができました。
ウィザードを実行した際、www. 付きのドメインを入力しただけですが、これが間違いでしょうか？ これはレートリミットを回避するためにそうしました。
いずれにせよ、その PEM エラーを過ぎると、次はこれにぶつかりました：
fail: nginx: runsv not running
[Wed Sep .... UTC 2026] Reload error for :
C=US, O=Let's Encrypt, CN=YR1
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
C=US, O=Let's Encrypt, CN=YE2
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
しかし、これは軽度のエラーのように見えます。なぜなら、ログには以前「grey clouds」を設定する前には発生しなかった証明書更新の成功メッセージが連続して出力されているからです。
また、ポート 80 と 443 はオープン状態を示しています。
さらに、ログの末尾に以下が複数回出力されているのを見かけます：
X-Accel-Mapping header missing
もう少し文脈を補足しますと、インスタンスはドメインに解決され、ログインを許可しています。ログイン画面（ログインのみに設定）が表示され、認証情報と2要素認証を受け入れますが、成功するとまた「Oops…」画面、つまり「またか」という状態に戻ります。
つまり、私は最初の出発点に戻ってしまいました。
元のサーバーインスタンスでは何も変更されていませんでした。突然、数日間パフォーマンスが低下する状態が続きました。この間、メトリクスは異常なレベルを超える奇妙な周期的なサーバー負荷を示していました。まるでアクセルを踏んでいるのに進まないような状態でした。最終的に、恒久的な「Opps」状態に陥ってしまいました。
そこで対処を開始しました。一つの解決策は、バックアップをとり、新しい Discourse にリストアすることでした。これが現在の状況です。つまり、ログインは可能ですが、また「Opps」に戻っている状態です。
また、過去の経緯として、以前は Full または Full (strict) で問題がありました。Full (strict) は常に動作せず、Full に戻す必要がありました。これは余談ですが。
あちゃ 
はい、成功を確認しました。以前使っていた非管理者ユーザーでログインできました。
どうやらこれがずっと問題の原因だったのに、ずいぶん回り道をしてしまいました！
ログ内で YR1 / YE2 の発行者エラーに遭遇して、このトピックにたどり着いた方のために:
別の Let’s Encrypt に関する問題を調査していた際、特定の証明書検証の失敗を再現しました。cert_exists() は現在、ca.cer からの最初の証明書のみを保持しており、チェーンの構築に必要な証明書を破棄してしまう可能性があります。
以下を使用することで、私がテストしたケースでは検証が修正されました:
openssl verify -untrusted ca.cer fullchain.cer
実際の RSA および ECDSA チェーンを検証し、既存の両方の証明書を再利用して、強制再発行をトリガーせずに再構築を完了しました。
この問題と修正提案を以下に文書化しました:
報告: Let’s Encrypt の cert_exists() が CA チェーンを切り詰め、強制再発行とレート制限の失敗を引き起こす
PR: FIX: cert_exists で Let’s Encrypt の発行者チェーンを保持する - Pull Request #1136
これは上記に表示された証明書の発行者検証エラーのみに関わるものであり、このトピックで最終的に解決された別個のアプリケーションの問題を説明することを意図したものではありません。