Certbot: スタンドアロンでは、代替ポートをバインドできるようにする必要があります（ただし、認証はできません）。

クライアントはすでに必要な機能を備えていると思いますが、主にテストに使用されているため、あまりユーザーフレンドリーな方法で表示されていません。 クライアントには次のフラグがあります。

  --tls-sni-01-port TLS_SNI_01_PORT
                        Port number to perform tls-sni-01 challenge. Boulder
                        in testing mode defaults to 5001. (default: 443)
  --http-01-port HTTP01_PORT
                        Port used in the SimpleHttp challenge. (default: 80)

これらのフラグを使用すると、クライアントがドメイン検証の課題を設定するポートを指定できます。 一般に、 --tls-sni-01は、着信ポート443トラフィックをルーティングしたポートであり、 --http-01-portは、着信ポート80トラフィックをルーティングしたポートである必要があります。

両方のフラグを使用する必要はありませんが、スタンドアロンはデフォルトで443を超えるチャレンジを実行します。次のフラグを使用してこの動作を制御できます。

  --standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
                        Supported challenges. Preferred in the order they are
                        listed. (default: tls-sni-01,http-01)

これがお役に立てば幸いです。

ありがとう、明日やってみます。

これが機能する場合は、実際に例として使用する必要があります。 サーバーを再起動してプロキシパスを有効/無効にする方が、すべてをオフラインにして検証プロセスを処理するよりもはるかに簡単です。

2016年3月22日午後3時16分、 bmwnotifications @github.comは次のように書いています。

クライアントはすでに必要な機能を備えていると思いますが、主にテストに使用されているため、あまりユーザーフレンドリーな方法で表示されていません。 クライアントには次のフラグがあります。

--tls-sni-01-ポートTLS_SNI_01_PORT
tls-sni-01チャレンジを実行するためのポート番号。 ボルダー
テストモードでは、デフォルトは5001です。（デフォルト：443）
--http-01-ポートHTTP01_PORT
SimpleHttpチャレンジで使用されるポート。 （デフォルト：80）
これらのフラグを使用すると、クライアントがドメイン検証の課題を設定するポートを指定できます。 一般に、-tls-sni-01は、着信ポート443トラフィックをルーティングしたポートであり、-http-01-portは、着信ポート80トラフィックをルーティングしたポートである必要があります。

両方のフラグを使用する必要はありませんが、スタンドアロンはデフォルトで443を超えるチャレンジを実行します。次のフラグを使用してこの動作を制御できます。

--standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
サポートされている課題。 優先される順序
リストされています。 （デフォルト：tls-sni-01、http-01）
これがお役に立てば幸いです。

—
スレッドを作成したため、これを受け取っています。
このメールに直接返信するか、GitHubで表示してください

@jvanascoほとんどの人はそのユースケースにwebrootプラグインを使用しますが、そうです、プロキシパスnginxの例が良いかもしれません。 ドキュメントに追加するPRを自由に作成してください。 これは十分に特殊化されたユースケースであるため、おそらくこのファイルの下部に新しいセクションを取得する必要があります。

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst

ただし、既存のスタンドアロンセクションからリンクすることができます。

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst#standalone

これについての返信はなかったので、この問題を閉じます。 再開したい場合は、私に怒鳴ってコメントしてください。

これはうまくいかないようです。 @BMW

/usr/local/bin/certbot-auto certonly --http-01-port 8484 --config-dir /etc/letsencrypt --work-dir /var/lib/letsencrypt --logs-dir /var/log/letsencrypt --standalone --standalone-supported-challenges http-01 --email [email protected] --domains example.com --agree-tos --non-interactive

tcp        0      0 0.0.0.0:8484                0.0.0.0:*                   LISTEN      7270/python2

認証はポート80で行われるようですが、python2サーバーは8484で起動しました。

ポート80のNginx

66.133.109.36 - - [25/Aug/2016:12:41:15 +0100] "GET /.well-known/acme-challenge/xxxxxxxx HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

編集：
--tls-sni-01-port 5001 --http-01-port 5002の両方が必要だと思います！

編集：
スタンドアロンでサーバーを起動して認証する方法については、まだ賢明ではありません。

--tls-sni-01-portが無視されるという問題もあります。

# certbot certonly --noninteractive --email "matt.hanley@****" --domain **** --agree-tos --tls-sni-01-port 40443 --http-01-port 4080 --standalone  
Failed authorization procedure. ****** (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 2af2853170e5be7e86cdff79d0ca****.febd4f14bb130b15910f30587cf4****.acme.invalid from 185.***.***.***:443. Received certificate containing '*****'

リクエストが実際に:443に送信されたことに注意してください。 別の証明書を提供する:443で実行されているHTTPSサービスがすでにあります。 ただし、これはrenewでは機能します。

--tls-sni-01-portにも問題があります：

certbot certonly -n -d example.com --agree-tos --email "[email protected]" --standalone --tls-sni-01-port 8443 --http-01-port 8080

Failed to connect to 1.2.3.4:443 for TLS-SNI-01

--http-01-port / --tls-sni-01-portでは、Let'sEncryptがサーバーに接続するポートを指定できません。 常にそれぞれ80/443を使用します。 これらのフラグを使用すると、Certbotがスタンドアロンなどのプラグインをリッスンするポートを制御できます。 これは、たとえば、すべてのポート80トラフィックをポート8080にルーティングする場合に役立ちます。

ええ、あなたは基本的にパブリックIPアドレスでポート80にアクセスできるようにする必要があります。

ドキュメントに非常に欠けているものは、Let's Encryptが80の着信トラフィックを制御できない少数派（おそらく中国/特定のISP、Corpファイアウォール）の目的に適していないことも意味します

私はこれに関する複数の投稿を読みましたが、80をリッスンする機能は、Nixボックスの特権ポートであるため、セキュリティの向上/信頼性の手段と見なされているようです。

暗号化して、Webサーバー以外の証明書の使用を認識しないようにしましょう。たとえば、電子メールサーバーなどですが、ノードアプリのポート7722ですばやく起動して認証を処理し、シャットダウンする必要がある場合があります。 t Webサーバーを実行します。しかし、図を見てください。

また、たとえばChefのような自動化を使用する場合、構成にSSLが含まれている場合、nginxを起動できるように自己署名証明書を構成する必要があり、少なくとも有効な証明書が必要です。

ただし、SSLのみを実行する場合の別のオプションは、別のWebサーバーに80を提供させることです。これにより、nginxが起動を試みる前に証明書が確実にダウンロードされるようになります。 （迷惑な設定）

私のシェフのデプロイメントは、次のように実行されます。

1. 自己署名証明書をインストールします。
2. nginxを起動します（自己証明書付き）
3. 証明書を実行する
4. 私の場所へのシンボリックリンク証明書
5. nginxをリロードします

私のiPhoneから送信された

2016年9月15日23:18、 BradWarrennotifications @github.comは次のように書いています。

--http-01-port /--tls-sni-01-portでは、Let'sEncryptがサーバーに接続するポートを指定できません。 常にそれぞれ80/443を使用します。 これらのフラグを使用すると、Certbotがスタンドアロンなどのプラグインをリッスンするポートを制御できます。 これは、たとえば、すべてのポート80トラフィックをポート8080にルーティングする場合に役立ちます。

—
コメントしたのでこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

私のWebサーバーはSSL接続を1つのポートでのみリッスンしますが、これはデフォルトの443ではありません。これはWebサーバーがポート転送を許可するVPNサービスの背後にあるが、ポート80または443へのポート転送を許可しないためです。

このサーバーでLet'sEncryptを構成しようとしていますが、ログにacmeクライアントがポート80（アクセスできない）で接続しようとして失敗することがわかります。

私が得るエラーは「接続できませんでした」ステータス400です。

「addressesResolved」の値は正しいです。「port」の値が80であり、すべてのURLが正しくないのは、カスタムポート（subdomain.domainなど）を指定する必要があるためです。 tld：1234ここで、1234は私のカスタムポートです。

私のセットアップでそれを動作させる方法はありますか？

@gsdevmeから、ポート80を公的にアクセス可能にする必要があるという印象を受けました...

_ACMEサーバーが検証するためにポート80にパブリックにアクセスできるようにする必要があります。_

_このソリューションは、サーバーを代替ポートで内部的に実行し、PORT80から代替ポートにプロキシする場合にのみ使用されます。_

_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_
_PORT80にアクセスできない場合は、DNS検証を使用する必要があります。_

返信@jvanascoをありがとう。 残念ながら、カスタムポートを指定できません。 私のダイナミックDNSプロバイダーhttp://freedns.afraid.org/には、TXTレコードを自動的に変更するためのインターフェイスがないため、DNS検証はオプションではありません。

@jvanascoあなたの返事は完全に正しいと思いますが、答える前に少し落ち着いていただければ幸いです：D

これがいつ構成可能になるかについての時間の見積もりはありますか？ カスタムポートでWebサーバーを実行している人はたくさんいると思います。

設計上の選択によって構成することはできません

私のiPhoneから送信された

2017年2月14日16:16、 nvaert1986notifications @github.comは次のように書いています。

これがいつ構成可能になるかについての時間の見積もりはありますか？ カスタムポートでWebサーバーを実行している人はたくさんいると思います。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

ここでも同じ問題ですが、Dockerを目的としています。

問題 ：
非本番環境では常に失敗するため、certbotコマンドをwebserverstartコマンドと一緒にパッケージ化したくありません。
だから私はcertbotを含む特定のイメージを構築したいと思います：

• 証明書を要求する
• Webサーバーと共有されているボリューム内に証明書を配置します

ただし、このソリューションは、ポート80と443に既にバインドされているWebサーバーのコンテナーを停止した場合にのみ機能します。

解決 ：
certbotポートを変更する機能があります。 これにより、certbotとwebserverコンテナの両方を並行して実行できるようになります。

DNS検証を使用すると、ユースケースが解決する場合があります。

私のiPhoneから送信された

2017年2月26日23:32、 NilsRenaudnotifications @github.comは次のように書いています。

ここでも同じ問題ですが、Dockerを目的としています。

問題 ：
非本番環境では常に失敗するため、certbotコマンドをwebserverstartコマンドと一緒にパッケージ化したくありません。
だから私はcertbotを含む特定のイメージを構築したいと思います：

証明書を要求する
Webサーバーと共有されているボリューム内に証明書を配置します
ただし、このソリューションは、ポート80と443に既にバインドされているWebサーバーのコンテナーを停止した場合にのみ機能します。

解決 ：
certbotポートを変更する機能があります。 これにより、certbotとwebserverコンテナの両方を並行して実行できるようになります。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

それは可能ですが、この検証モードはスタンドアロンモードでは不可能です：/
（from：https://certbot.eff.org/docs/using.html#plugins）

セキュリティを損なうことなく賢明な中間点のように思われるのは、DNSSRVレコードを介したポートの検出を許可することです。 Letsencryptは次のようなレコードをクエリできます

_letsencrypt._tcp IN SRV 0 0 8080 10.10.10.10

ドメイン上で検証要求を結果のアドレス/ポートの組み合わせに転送します。 これにはDNS検証と同じ利点がありますが、動的な更新が必要になるという欠点はありません。

これは、ユーザーが中央の証明書サーバーを参照することで、必要に応じて証明書の管理を簡単に一元化できることも意味します。

代替ポートを許可すると、セキュリティがどのように損なわれますか？

このFOSSユーティリティは、TCP / 443ポートがビジーであるか、TCP/443ポートが転送されていないホストへのACME証明書の直接および間接インストールを自動化するのに役立ちます。

https://www.actiu.net/sesele/

SeSeLeがどのように機能して使用できるようにするかについてのドキュメントはどこにありますか
443とは異なるポート？

2017年10月26日午後1時21分、「NarcisGarcia」 [email protected]は次のように書いています。

このFOSSユーティリティは、の直接および間接インストールを自動化するのに役立ちます。
TCP / 443ポートがビジーである、またはTCP/443を使用していないホストへのACME証明書
それらに転送されたポート：

https://www.actiu.net/sesele/

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/certbot/certbot/issues/2697#issuecomment-339754606 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAOGHuxKLiYjM4-cME-0GBu9Ujoe0NB_ks5swM20gaJpZM4H1uae
。

SeSeLeフォーラムの問題にアクセスして、ドキュメントの調整を改善してください。 （回答は現在SeSeLeのドキュメントに記載されています）

おそらく、この問題を再検討することができますか？ 根本的な問題に対する解決策はまだありません。 はい、スタンドアロンで別のポートにバインドできますが、athorityは引き続き80/443に接続するため、これは役に立ちません。

サーバーがすでに80/443で稼働している場合、おそらく本番環境では、これらのポートを解放する余裕がないことがあります。 チャレンジファイルを手動で配置することも問題になる可能性があります（サーバーはDockerで実行されています）。

ここでの実際の解決策は、権限がフォールバックなどとして接続を試みる、上位（10000以上）のポートのセットを指定することです。 おそらく、専門家ではなく、セキュリティへの影響があります。

LEがポート80/443にのみ接続する動機は何ですか？ これは
正式に文書化された制限？

誰かが私に正しい文書を教えてもらえますか？

2017年11月30日午前6時31分、「cen1」 [email protected]は次のように書いています。

おそらく、この問題を再検討することができますか？ 解決策はまだありません
根本的な問題。 はい、スタンドアロンで別のポートにバインドできますが、
athorityはまだ80/443に接続するため、役に立たない。

おそらく本番環境で80/443ですでにサーバーを実行している場合は、
これらのポートを解放する余裕がない場合もあります。 手動で配置
チャレンジファイルも問題になる可能性があります（サーバーはDockerで実行されています）。

ここでの実際の解決策は、上位のポートのセットを指定することです（10
000+）当局がフォールバックまたは何かとして接続しようとする場所
そのように。 おそらく、専門家ではなく、セキュリティへの影響があります。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/certbot/certbot/issues/2697#issuecomment-348162321 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAOGHqWG9XZyTVDdAbm3t5xQ-AD6Y_OQks5s7pIDgaJpZM4H1uae
。

LEがポート80/443にのみ接続する動機は何ですか？
これは正式に文書化された制限ですか？

誰かが私に正しい文書を教えてもらえますか？

これは、ここで説明されている現在のCA/Bフォーラムの要件です。
https://cabforum.org/2017/09/19/ballot-190-revised-validation-requirements/

そして、ここでより詳細に説明されています： https ://community.letsencrypt.org/t/support-for-ports-other-than-80-and-443/3419/100

私の貧弱な英語で理解しているように、CA /ブラウザフォーラムでは、2017年9月にTCPポート25、115、22の追加の可能性について議論しました。
提案は承認されたようで、今年の11月に発効するはずです。

誰かがGoogleからここに来た場合の将来のメモ（私のように）：

2018-08-29 13:43:33,495: WARNING:certbot.plugins.standalone: 
The standalone specific supported challenges flag is deprecated. 
Please use the --preferred-challenges flag instead.

nginxを使用している場合は、nginxモジュールをcertbot certonly --nginxで使用でき、構成なしで既存のnginxサーバーを利用します。

フラグ--http-01-portは実際には直感的ではありません。また、コマンドのヘルプでそれを見つけることができず、フラグ--http-01-portをグーグルで検索する必要がありました。 ヘルプにフラグが記載されていると便利です。