Lua-resty-auto-ssl: ワイルドカード証明書

私はレポメンテナーではありませんが、これを追加するのは簡単ではないと言わざるを得ません。 LEワイルドカード証明書にはDNS検証が必要であり、現在lua-resty-auto-sslはhttp検証を使用しています。

ワイルドカードを考慮しなくても、DNS検証があれば便利です。 いくつかの考え：

• 最初にACMEv2サポートを取得するには、脱水状態になるまで待つ必要があります：脱水状態＃420
• dehydratedはすでに（ACMEv1）dns-01チャレンジをサポートしています。 現在のACMEv2ドラフトのdns-01チャレンジは、私と同じかほぼ同じように見えます。
• 脱水状態のdeploy_challengeフックは、TXTレコードに書き込まれるドメインとトークンを提供します。
• ユーザーがDNSレコードをどのように管理しているかわからないため、この部分は一般的である必要があります。
  
  
  
  1. 一般的なDNSAPIをサポートします。 少なくとも、PowerDNS、CloudFlare、さらにはnsupdateによって提供されるような「標準」APIをサポートするインフラストラクチャを追加する必要があります。 この場合、設定に必要なのはある種の認証トークンだけです。
  
  
  2. ユーザーは、プロプライエタリAPIと通信したり、ダーティシェルスクリプトを呼び出したりするなど、これらのレコードを設定するためのカスタムソリューションが必要になります。 これらの場合に一般的なフックを提供する必要があります。
     
     -- Define a function to store the validation tokens for DNS verification -- by let's encrypt in your DNS setup. auto_ssl:set("deploy_dns_challenge", function(domain, token) -- talk to your DNS-API to create a new TXT record _acme-challenge.$domain with value $token end)
  
  
• ストレージレイヤーは現在、証明書を取得するためのキーとしてフルドメインを使用できると想定しています。 これはもはや当てはまりません。 私の最初のアイデアは、ワイルドカードをparentdomain.com:wildcard:latestとして保存し、具体的な証明書が見つからない場合はストレージレイヤーにそのキーをチェックさせることです。

質問：

1. 通常の証明書とワイルドカード証明書のどちらを生成するかをどのように知ることができますか？ 新しいユーザー定義関数is_wildcard_domain ？ 既存のallow_domainの新しい戻り値？
2. DNS（ワイルドカードの場合）とHTTP（通常の証明書の場合）の検証を同時にサポートしますか、それとも両方のDNSのみをサポートしますか？ すべての可動部分を制御するため、HTTPの方がはるかに高速である可能性があることに注意してください。

参考： ACMEv2ステージングエンドポイントが利用可能になりました。 :)

現在のACMEv2ドラフトのdns-01チャレンジは、私と同じかほぼ同じように見えます。

その通りです:-) V1APIとV2APIの間のDNS-01チャレンジでは何も変更されていません。

参考：少なくともdehydratedの開発バージョンは、ワイルドカード証明書だけでなくACMEv2もサポートするようになりました。 誰かがこれに取り組み始めたい場合は、今がチャンスです;）

DNS検証を行うresty-auto-sslは完全に範囲外だと思います。
ただし、resty-auto-sslを「帯域外」で構成されたワイルドカード証明書にフォールバックさせることは可能です。
たとえば、bind9とcertbotを使用してサービスを設定し、ドメインのワイルドカード証明書を作成します。 今のところ、ワイルドカード証明書を生成する代わりに、そのワイルドカード証明書を使用するようにresty-auto-sslに指示することはできないと思います。

編集：まあ、それは範囲外ではありません。 カスタムDNSAPIにフックするように手動スクリプトで脱水を構成できることを知りませんでした...

手動で生成されたワイルドカードLE証明書をRedisに保存して、resty-auto-sslが使用できるようにする方法はありますか？

私がコードから理解していることから、これは不可能です。 sub.domain.tldごとに、ストレージインターフェイスに次のチェックを簡単に追加できます。

• sub.domain.tld:latest —現在
• *.domain.tld:latest
• *.sub.domain.tld:latest

このようにして、今のところ以前に生成された証明書のみをサポートする、ワイルドカードへの第一歩を踏み出すことができます。 そうしたら、ワイルドカード証明書の生成をサポートするための優れた方法を決定することができます。

編集：上記の実装をスクラッチできれば幸いです。

@akalipetis設定するかどうかを確認しようとしましたか

ssl_options.fullchain_der
ssl_options.privkey_der

allow_domainで動作しますか？
可能であれば、allow_domainでredisリクエストを実行し、それらを設定できます。

この問題が発生したばかりの記録では、 lua-resty-auto-sslを使用して、監視サービスのカスタムドメインステータスページの証明書を生成します。ほとんどの人は、 xxxx.status.updown.ioのような独自のドメインを使用します。ワイルドカード証明書を使用します。

これは、 allow_domainラムダを使用して*status.updown.ioの証明書生成をスキップすることで実現しました。

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

次に、デフォルトのフォールバック証明書としてワイルドカードを提供しました。

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

DNSチャレンジを使用して手動で証明書を生成しました。

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

DNSの課題が複雑に見えるため、これを自動化することに時間を費やす価値があるかどうかはわかりません。 ローテクですが、期待どおりに機能します:)

これは優れた回避策であり、多くのユースケースに当てはまります。
ただし、DNSチャレンジはhttps://github.com/AnalogJ/lexiconで非常に簡単になっていることに注意してください。
それはうまく機能し、多くのプロバイダーをサポートします。 私もそれらの1つを追加しました、そしてプロセスは途方もなく簡単です。

@kapouer lexiconについてのヒントをありがとう、自動化したい場合はそれを覚えておいてください;）

この問題が発生したばかりの記録では、 lua-resty-auto-sslを使用して、監視サービスのカスタムドメインステータスページの証明書を生成します。ほとんどの人は、 xxxx.status.updown.ioのような独自のドメインを使用します。ワイルドカード証明書を使用します。

これは、 allow_domainラムダを使用して*status.updown.ioの証明書生成をスキップすることで実現しました。

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

次に、デフォルトのフォールバック証明書としてワイルドカードを提供しました。

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

DNSチャレンジを使用して手動で証明書を生成しました。

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

DNSの課題が複雑に見えるため、これを自動化することに時間を費やす価値があるかどうかはわかりません。 ローテクですが、期待どおりに機能します:)

私はまた、私たちのアプリに対して同じタイプのドメインチェックを行っています。 ユーザーのポータルホストに「独自の」ドメインの1つが含まれている場合は、静的CAからのワイルドカード証明書の使用に戻ります。 ただし、LEを引き続き使用し、ワイルドカードを手動で生成するというあなたのアイデアは気に入っています。

これをテストします。

アップデート
さて、これは本当に私が望むことを行うソリューションです。 cloudflareプラグイン。 ドキュメントはかなり良いです。 私はそれを1、2時間以内に動かしました。

https://certbot-dns-cloudflare.readthedocs.io/en/stable/

@jarthodこれを自動化する他の回避策はありますか？ 3か月ごとにワイルドカードを更新することを忘れないでください。

@jarthodこれを自動化する他の回避策はありますか？ 3か月ごとにワイルドカードを更新することを忘れないでください。

私の側ではありませんが、私はまだこれを使用しており、3か月ごとに手動で更新しています。 サービス（updown.io）を使用してエンドポイントを監視しているので、覚えていても問題はありません。証明書の有効期限が近づくとアラートが表示されます。

私もあなたのサービスのユーザーです。 とにかく私は先に進み、従来の1年間のワイルドカードSSLを取得しました。

今、あなたのサービスには来年私に思い出させる仕事があります😄

2020年10月3日午後10時30分、Adrien [email protected]は次のように書いています。

。
@jarthodこれを自動化する他の回避策はありますか？ 3か月ごとにワイルドカードを更新することを忘れないでください。

私の側ではありませんが、私はまだこれを使用しており、3か月ごとに手動で更新しています。 サービス（updown.io）を使用してエンドポイントを監視しているので、覚えていても問題はありません。証明書の有効期限が近づくとアラートが表示されます。

—
コメントしたのでこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、登録を解除してください。