* .domain.comとdomain.comに同じワイルドカード認証を使用できますか

* .domain.comを名前として使用して、SSL証明書を作成できます。

しかし、残念ながら、これはhttps://domain.comをカバーしていません

これに対する修正はありますか？

私は、*。domain.comが実際にRFCに違反していることを思い出すようです（ただし、lynxだけが文句を言うと思います:)

CNとしてdomain.comを使用し、subjectAltName:dNSName名前フィールドに* .domain.comを使用して証明書を作成します-これは機能します。

opensslの場合、これを拡張機能に追加します。

subjectAltName          = DNS:*.domain.com

残念ながら、これはできません。サブドメインでワイルドカードを処理するためのルールは、サブドメインのCookieに関するルールに似ています。

www.domain.com       matches    *.domain.com
secure.domain.com    matches    *.domain.com
domain.com      does not match  *.domain.com
www.domain.com  does not match  domain.com

これに対処するには、2つの証明書、のための1つ取得する必要があります*.domain.comし、他のためにdomain.com。2つの個別のIPアドレスを使用する必要があり、2つの仮想ホストがこれらのドメインを個別に処理します。

最近のワイルドカードでは、サブジェクトの別名フィールド（SAN）に* .domain.comとdomain.comが含まれます。たとえば、quora.comのワイルドカードSSL証明書を見てください

表示されます

サブジェクトの別名：* .quora.com、quora.com

おそらくあなたが探している答えではないかもしれませんが、私には99％の方法があると確信しています。http://domain.com/をhttps://www.domain.com/にリダイレクトし、*。domain.comをSSL証明書として使用します。完璧とはほど遠いですが、あなたが興味を持っているほとんどのケースをカバーすることを望みます。他の唯一の選択肢は、domain.comとwww.domain.comに異なるIPアドレスを使用することです。その後、IPごとに異なる証明書を使用できます。

いいえ、名前空間がまったく異なるためです。SSLはトランスポート暗号化であり、たとえばApacheがリダイレクトするリクエストホストを確認する前にSSLをデコードする必要があるため、TLDのリダイレクトもオプションではありません。

また、サイドノートとして：foo.bar.domain.comはワイルドカード証明書には無効です（メモリからのfirefoxのみがそれを許可します）。