IIS/WindowsでACMEプロトコルを示すために ngrok を使用しています。ただし、このサービスはAレコードよりもCNAMEを優先します。
相互作用のデバッグでは、ACMEはAレコードしか許可しないようです。この動作のセキュリティの根拠は何ですか?代替案はありますか?
ここのエラーメッセージ:
{
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:connection",
"detail": "DNS problem: SERVFAIL looking up A for dev.server.com",
"status": 400
},
セキュリティホールがstartencryptと呼ばれる関連のないサービスにある限り、セバスチャンニールセンの答えは間違っています。 LetsencryptがCNAMEレコードをサポートしていないという意味も正しくありません this thread と、LetsencryptのモデレーターがCNAMEレコードをサポートしていることを人々に保証する他のいくつかによって検証されています。実際、CNAMEレコードを使用して、Azure VMをポイントしたサブドメインの検証に合格しました。
Certbotが表示するエラーメッセージは、何かが間違っている場合にはかなり誤解を招くものであり、CNAMEサポートに関する公式ドキュメントには何も見つからなかったため、このような混乱を引き起こしています。
これは、CNAMEを許可した場合、所有していないサイトの証明書を生成できるためです。
「yoursite.com CNAME google.com」のような独自のCNAMEを設定して、google.comの証明書を生成できるセキュリティホールがありました。リダイレクトにも同じ問題があり、リダイレクトを設定して不正な証明書が発行される可能性があります。
ただし、CNAME /リダイレクトに遭遇した後、アドレスを再確認して実際の穴を修正する代わりに、それらは単にブロックされるため、リダイレクトとCNAMEは許可されません。