web-dev-qa-db-ja.com

ワイルドカードを使用した自己署名SSL証明書-サブドメインでは機能しますが、メインドメインでは失敗します

開発目的で、CN = *.example.comの自己署名SSL証明書を作成しました。

証明書をインストールした後、サブドメインhttps://sub.example.comを参照すると、すべてが正常であることを示す素敵な緑色のロックが表示されますが、https://example.comを参照すると、引き続きエラーが発生します。ブラウザには、「サーバーの証明書がURLと一致しません」と表示されます

この問題を解決して、すべてのサブドメインとメインドメインの両方で有効な1つの証明書を取得するにはどうすればよいですか。

subdomainhttpssecurity-certificatecertificate-generation
2
fudge

名前の検証は、 RFC 2818 Section 3.1 、より具体的にはワイルドカードに基づいています：

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

ここでは、「ドメイン名コンポーネント」はドットで区切られており、それらは含まれていません。

これは RFC 6125 でも明確にされています（これはワイルドカード証明書の使用も推奨しませんが、それは別の問題です）。

ホスト名をサブジェクトDNの共通名RDNに入れる代わりに、同じ証明書に2つのサブジェクト代替名エントリを含めることができます。1つは*.example.com用、もう1つはexample.com用です。 CNは、 とにかくフォールバックソリューション であることのみを目的としています。

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.
3
Bruno

https://www.example.comで動作しますか？その場合、メインドメイン用に別の証明書を作成する必要があります。

0
Anagio