web-dev-qa-db-ja.com

単一のサブドメインにワイルドカードSSLが必要ですか？

一般的なSSL証明書は、ドメインの共通名（domain.com）に基づいている場合もあります（www.domain.com）。

ワイルドカード証明書が（* .domain.com）に使用されていることを理解しており、そのドメインのすべてのサブドメインを検証する必要があります。

単一のサブドメインをSSL証明書（mail.domain.com）でカバーしたい場合、ワイルドカード証明書はのみオプションですか？または、その単一のサブドメインに対して発行された標準のSSL証明書を使用することは可能ですか？

私はベストプラクティスや、「ワイルドカード証明書を使用する必要がある」理由を求めていません。技術的な観点から、ワイルドカードではないSSLドメイン検証済み証明書を使用して単一のサブドメインを保護できるかどうかを尋ねています。

apache-2.2sslsubdomainshared-hosting
4
PenguinCoder

Mail.domain.com専用に発行されたSSL証明書を問題なく使用できます。ワイルドカード証明書の最大の利点は、「すべてを統治するための証明書が1つ」しかないことです。つまり、数十の証明書を管理する必要がありません。

7
Ondra Sniper Flidr

「domain.com」を所有している場合は、「mail.domain.com」の証明書をリクエストすることもできます。ルートドメインの所有権を証明する必要があります。

1
dtoubelis

はい、特定のサブドメインのみをカバーする証明書を持つことができます。ワイルドカードを使用せずに、複数のサブドメインをカバーする証明書を作成することもできます。

SSL/TLSは従来、IP /ポートの組み合わせごとに1つの証明書しか許可していなかったことに注意してください。これを修正するSNIと呼ばれる拡張機能がありますが、それをサポートしていない古いクライアントがまだいくつかあります（Windows XPの最も有名なInternetExplorer）。

0
Peter Green

証明書は一般的に1つの主題のみを提供すると考えられているため、最初はこの質問について少し混乱しました。 ワイルドカード ではないSSLドメイン検証済み証明書で単一のDNSレコード（/サブドメイン、セクション3を参照）を保護していませんウェブサイト？

簡単に言えば、サブドメインmail.domain.comがそれ自体のリソースの接続文字列である場合、単一の非ワイルドカード証明書で保護することができ、保護する必要がありますが、このサブドメインのレコードがによってカバーされることを期待するべきではありません。同じ証明書も。

現在受け入れられている回答 は、一般的なケースに対して適切で簡潔な回答を提供しますが、ワイルドカード証明書を推奨するときに予期しない警告を提示する可能性があります。したがって、さまざまなタイプの end-entity 証明書で実行できることと実行できないことについて、潜在的に危険な誤解を防ぐために、もう少し深みがあり、3つのセクションに分かれています。

  1. ワイルドカード/非ワイルドカードの選択
  2. 証明書の名前が提示できるものとどのように関連しているか
  3. 質問のコンテキストでサブドメインが何を意味するか。

セクション1：ワイルドカードと非ワイルドカード

  • 価格：これは私が言及したい最初のものです。商用CAの料金は、標準の証明書と比較して、ワイルドカード証明書の約3〜5倍です。たとえば、執筆時点では、 Symantec （以前はVeriSign）からの1年間の標準の安全なサイト証明書のコストは399ドルです。 1年間のワイルドカード証明書の費用は$ 1,999（〜x5標準）です。 Symantecセキュアサイト証明書（より安価なオプション） はサブジェクト代替名 （SAN）で使用できます。つまり、公に知っている限り、使用していて来年使用する予定のDNS名に直面している場合、複数のWebサイトや安全な接続ポイントであってもワイルドカード証明書は必要ありません。

  • 潜在的なエクスポージャーの範囲：上記のコメントで述べたように、秘密鍵が漏洩した場合、さまざまなレベルのエクスポージャーがあります。単一のWebサーバーの証明書を使用すると、攻撃者はそのサーバーにのみなりすますことができます。単一のWebサイトの場合、Webサイト名が解決されるサーバーのみ（セクション2-サブジェクト名の一致を参照）。上記の1つのSAN証明書のアイデアで、すべて公開されている名前を使用すると、公開されているすべてのWebサイトになりすますことができます。ワイルドカード証明書を使用すると、何でも偽装して、それがドメイン。ワイルドカード証明書 に対するセキュリティ引数は、RFC に示されています。

  • 名前の一致：非ワイルドカード証明書は、正確なサブジェクト名（具体的には、ほとんどの証明書のサブジェクト名の共通名またはCNコンポーネント）のみに一致します。したがって、mail.domain.comに関連付けられた証明書の解決は、CNAMESまたは複数のIPアドレスへの解決が含まれている場合でも機能しますが、たとえば、 smtp.mail.domain.com（またはより一般的な使用法では[email protected]）は、SANとして構成されていない限り、どちらも機能しません。この場合、ワイルドカード証明書* .mail.domain.comはsmtp.mail.domain.comで機能します（そして、両方の id-pkix 3 4 そしてあなた は手動でワイルドカードS/MIME ）を設定します。

  • 将来の保証：これは、ワイルドカードのみを使用するための推奨事項のほとんどが由来する場所です。プライマリDNSドメイン「domain.com」のワイルドカード証明書を使用すると、domain.comの下にある任意の数のWebサイトをホストできます。これは、証明書を要求したときに必要であるとは知らなかったサイトでも同様です。提示された証明書が常に一致するため、提示された証明書がWebサイト名と一致することを確認する必要はありません。

  • 計画：将来の保証に関するポイントについて、マルチSAN証明書を使用すると、現在および計画中の将来のWebサイトをすべて含めている限り、管理のしやすさは同じであることに注意してください。使用できる名前は数十あるので、使用する予定はないが組織で使用される可能性があると思われるDNS名を追加することもできます。今年の半ばに計画していなかった名前が必要になったとしても、別のマルチSAN証明書を購入すると、おそらくワイルドカード証明書の半分以下の費用しかかかりません。

  • ワイルドカードの制限：価格差の大きさを考えると、数十から数百の公開DNS名を持つ大規模な組織でない限り、ワイルドカードを使用しないための小さな管理オーバーヘッドがワイルドカード証明書のコストに見合うかどうかはわかりません。安全です。また、ワイルドカードは、domain.comの下のDNS階層の1つのレベルにのみ一致することに注意してください。したがって、www。*。domain.comが必要な場合は、www。[specificsubdomain] .domain.com専用の新しい証明書、または*。*のワイルドカード証明書のSAN）が必要になります。 .domain.comまたはwww。*。domain.com。CAは、ワイルドカード証明書へのSANの追加に消極的/拒否することが多いことに注意してください。

セクション2：サブジェクト名のマッチング

覚えておくべきことの1つは、検証は、証明書で要求されているものと一致するクライアントの件名文字列に基づくことです。 Webブラウザーの場合、これはページにアクセスするためにアドレスバーに入力されるデータです。電子メールクライアントの場合、 は送信元の電子メールアドレス を表し、さまざまなクライアントタイプと証明書の使用法などに対応します。

したがって、Webサーバー証明書の場合、DNSにこれがある場合：

www.otherdomain.org A 172.16.254.1

しかし、これは特定のマシンのhostsファイルにあります。

172.16.254.1 mail.domain.org

その特定のマシンは、サーバー172.16.254.1でmail.domain.orgの証明書を提示するサーバーとサブジェクト名が一致しますが、www.otherdomain.orgへのDNSルックアップを介して172.16.254.1に到達するクライアントは、同じ証明書。次に、このCNAMEをDNSに追加すると、次のようになります。

mail.domain.org CNAME www.otherdomain.org

そして、すべてのクライアントにwww.otherdomain.orgではなくブラウザでmail.domain.orgにアクセスするように依頼すると、証明書はこれらのクライアントに証明書名の不一致を表示しなくなります。これは、DNS解決がブラウザに対して不透明であるためです。

セクション3：DNSの用語

この用語は少し混乱する可能性があることも指摘したいと思います。「サブドメイン」と言えば、私の結論は、プライマリネームサーバーが置かれている親ゾーン/ドメインの下にあるフルオンゾーンであり、このサブドメインには独自のサブドメインがある可能性があります。ネームサーバーとその下の下位レコード。

（もちろん、DNS階層では、技術的にはルート以外のすべてがサブドメインですが、概念的には「サブ」を満たすため、階層内に従属がないレコードを「サブドメインではない」と見なす傾向がありますが、必ずしもすべての側面を満たしているとは限りません適切な ' domain 'の場合。たとえば、後でネームサーバーを追加できたとしても、通常、Aレコードを管理上の自律性があるとは見なしません。その下のルックアップを記録して入力します。この傾向が必ずしも技術的な現実と一致するとは限らないことを認識しています。）

単一の「リソース」（ウェブサイト、サーバー、ワークステーション）に解決されるレコードの場合、通常は「ウェブサイト/サーバー/ワークステーション」、一般的な「DNSレコード」、「ホスト（A）レコード」のみを使用するか、 CNAME、F5ウィザードなどの可能性、少なくとも '[ウェブサイト/サーバー/非サブドメインリソースタイプ] 完全修飾ドメイン名 '（FQDN ）

0
Bruno