Lua-resty-auto-ssl: 証明書を発行するときにIPアドレスを無視する

私はちょうどそのためのチェックを書きましたが、それがすでにかなり早い段階で失敗していることを知るために、次のようになりました。

ssl_certificate（）：auto-ssl：リクエストのドメインを特定できませんでした（SNIはサポートされていませんか？）-フォールバックを使用します-

ブラウザがIPアドレスにリクエストを送信すると、SNIヘッダーが送信されないため、「ドメイン」も設定されません。

なぜ私のものが暗号化を許可するリクエストを送信していたのかわかりませんが、SSL証明書をIPに登録することについてエラーを送信していました：S

@discobean ：これを見たときに発生する特定のエラーメッセージはありますか？

@GUI同じエラーが発生することがあります。 私の推測では、これはクライアント（おそらくスキャナーボット）がターゲットIPアドレスに等しいホストヘッダーを送信しているためです。例：

2018/02/20 02:10:44 [warn] 490#490: *2723 [lua] init_by_lua:11: allow_domain(): auto-ssl: debug allow_domain domain XXX.XXX.XX.XX, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=XXXXX HOOK_SERVER_PORT=8999 /usr/local/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain XXX.XXX.XX.XX --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing XXX.XXX.XX.XX
 + Signing domains...
 + Creating new directory /etc/resty-auto-ssl/letsencrypt/certs/XXX.XXX.XX.XX ...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for XXX.XXX.XX.XX...
 err:   + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 400)

Details:
{
  "type": "urn:acme:error:malformed",
  "detail": "Error creating new authz :: Issuance for IP addresses not supported",
  "status": 400
}

, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for XXX.XXX.XX.XX - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443

ここで、 XXX.XXX.XX.XXは実際のサーバーのIPアドレスです

私はすべてコードでこれをブロックしていますが、ええと：allow_domain（）は、「これらではない」（ブラックリストアプローチ）ではなく、（ホワイトリストアプローチ）で証明書を生成するFQDNを許可する必要があります。

allow_domain（）で単に「trueを返す」ことは絶対にしないでください。 それはあなたのシステムに負担をかけ、LEに向かって失敗を蓄積します。

ただし、さらに一歩進んでいます。 すべてのウェブホスティング顧客のリストをディスク上のLuaテーブルファイルにエクスポートし、それを読み取ってnginx内のSHMキー/値ストアに保存するため、証明書を生成する必要があるホストを簡単に確認できます。

管理ホスト名に複数のワイルドカード証明書があるため、対応するSSL証明書が含まれるSSLチェーンを置き換えて早期に終了します。 IPアドレスとローカルホストで早期終了します。 そして最後に、DNSをチェックし、その名前がシステムに構成されているドメインのリストに実際に含まれているかどうかを確認します。

これらのチェックのほとんどは時間内に勝つだけですが、実際には必要ありません。 要点：ブラックリストの代わりにホワイトリストを使用してください。 これも一般的なコード慣行です。 転ばぬ先の杖。

また、非常に動的な環境の場合は特に、オーバーエンジニアリングしてさまざまなチェックをスキップしない方がよい場合もあります。これは、さらに別の障害点になる可能性があります。

これをlua-resty-auto-sslでブロックする必要があると言っているのではなく、他の誰かがこの問題に遭遇したかどうかをテストしているときに見つけたものを共有するだけです。

allow_domainのクイックハック：

          local ip_chunks = {domain:match("(%d+)%.(%d+)%.(%d+)%.(%d+)")}
          if (#ip_chunks == 4) then
            return false
          end

ホワイトリストは過剰に設計されているのではなく、正しく実行されています。 開発者がホワイトリストの代わりにブラックリストを使用しているため、世界中で非常に多くのセキュリティインシデントが発生しています。これは、リモートでさえ面白くありません。

チェックもIPv6アドレスをスキップし、実際には過剰に設計されています。

if string.match(domain, "(%d+).(%d+).(%d+).(%d+)") or string.find(domain, ":", 1, true) then
    return false
end

あなたは私たちの状況を知りませんが、あなたはすぐに判断します。 取られたポイント。

おそらく、PRを作成し、README.mdのallow_domainを、 trueを返すよりも賢明なものに変更して、全員の安全を確保することができます。