私はいくつかのレベルのサブドメインを持つWebサイトで作業しています。それらすべてをSSLで保護する必要があり、正しい証明書戦略を決定しようとしています。
セキュリティで保護する必要があるのは次のとおりです。
私の理解では、ワイルドカード証明書はサブドメインの「レベル」を1つしかカバーできません。 RFC 2818による :
名前には、単一のドメイン名コンポーネントまたはコンポーネントフラグメントと一致すると見なされるワイルドカード文字*を含めることができます。たとえば、*。a.comはfoo.a.comと一致しますが、bar.foo.a.comとは一致しません。 f * .comはfoo.comと一致しますが、bar.comとは一致しません。
私が必要とするものthink以下の証明書が必要です。
*.foo.com
。たとえば、foo.com
、www.foo.com
と一致します。 (*.a.com
自体がa.com
と一致するかどうかははっきりしませんが。)*.ny.foo.com
はnew-york.ny.foo.com
、buffalo.ny.foo.com
などに一致します。サイトを拡張してすべての州に対応したら、最終的にすべての州に一致する50の証明書が必要になります。私の質問は:
ca.foo.com
にアクセスした場合、*.foo.com
または*.ca.foo.com
の証明書を取得しますか?foo.com
にアクセスし、次にmountain-view.ca.foo.com
にアクセスした場合、それらは異なる証明書であり、警告が表示されますか?これらの証明書が同じ所有者を共有していることをブラウザに保証する方法はありますか?理論的には:
*
は正確に1つのレベルに一致します(したがって*.foo.com
は、一致します一致しませんfoo.com
)*
名前でしたがって、すべてのSSL実装が RFC 2818 に忠実に従っている場合、必要なのは次の名前の3つの証明書だけです。
foo.com
*.foo.com
*.*.foo.com
そして、実装がRFC 2818とX.509の複雑さを守るのに本当に優れている場合は、3つをリストするsingle証明書を使用することもできます。上記の件名の代替名の拡張子の文字列。
今、理論と実践は完全に一致しています...理論的には。ブラウザーが実際に行っていることに驚きがあるかもしれません。ぜひお試しください。 OpenSSL コマンドラインツールで作成できる証明書の例(たとえば、いくつかのガイドラインについては このページ を参照)。
RFC 6125はごく最近であり、誰もが実装しているわけではありませんが、これらの問題のいくつかを明確にすることを試みています。これは、RFC 2818および他のプロトコルのRFCのID仕様を収集します。できればRFC 6125に準拠することをお勧めします。ワイルドカード証明書に関連するセクションは 6.4. および 7.2 です(実際、ワイルドカード証明書の使用は推奨されません)。
単一のWebサーバーを実行するか(または、少なくともすべてを単一のIPアドレスの背後で実行できるようにするか)、またはサイトごとに証明書(したがってIPアドレス)を取得できるかどうかは、質問から明らかではありません [〜#〜] sni [〜#〜] は、一般的にサポートされていないため、サイトごとに)。
複数のサブジェクト代替名(SAN)を持つ単一の証明書を使用できます。問題は、明確に指定されていない可能性がある2つのワイルドカードラベル(*.*.foo.com
)。
二重ワイルドカードが機能する場合、3 SAN DNSエントリを含む証明書が機能するはずです。
foo.com
*.foo.com
*.*.foo.com
ただし、(クライアントの実装によっては制御できない可能性があるため)機能しない可能性があり、50の状態をリストできるため、52 SAN DNSエントリ:
foo.com
*.foo.com
*.ny.foo.com
これらのサブドメインがすべて正当に所有されているものとしてユーザーに表示されるようにするにはどうすればよいですか?たとえば、ユーザーがfoo.comにアクセスし、mountain-view.ca.foo.comにアクセスした場合、それらが異なる証明書である場合、警告が表示されますか?これらの証明書が同じ所有者を共有していることをブラウザに保証する方法はありますか?
これは、ユーザーが証明書の検証プロセスにどの程度精通しているかに依存するため、難しい問題です。緑のバーが表示される拡張検証証明書を取得できます(ただし、ワイルドカードEV証明書はおそらく許可されていないと思います)。これにより、ほとんどのブラウザで「所有権」のラベルが表示されます。その後、ブラウザのインターフェース自体が混乱する可能性があります(たとえば、Firefoxの青いバーで「(unknown)によって実行されます」とは、どちらの方法でも役に立たない)。最終的に、ユーザーは証明書にアクセスして、証明書が発行されたSANを確認できます。しかし、私は多くの人がこれを行い、それが何を意味するのかを理解することを疑います。
http://www.digicert.com/welcome/wildcard-plus.htm は言う
さらに、DigiCert WildCard ssl証明書は、1つの証明書で複数レベルのサブドメインを含む、ドメインの任意のサブドメインを保護できるという点でユニークです。たとえば、*。digicert.com comのWildCardには、サブジェクトの別名としてserver1.sub.mail.digicert.comを含めることができます。
ワイルドカード証明書を使用するか、代替ドメイン名のある証明書を使用することもできます。個人的には、StartSSLの証明書を使用しています。これにより、すべてのドメインを1つの証明書に記載できます。サーバーでホストしているサイト全体でSSLを使用できるように、10個のワイルドカードドメインと15個の他のADNがすべて同じ証明書上にあります。