
答え1
*.domain.com は実際には RFC に違反しているように思います (ただし、lynx だけが違反を訴えていると思います :)
CN として domain.com を使用し、subjectAltName:dNSName
名前フィールドに *.domain.com を使用して証明書を作成します。これで機能します。
openssl の場合は、拡張機能に以下を追加します。
subjectAltName = DNS:*.domain.com
答え2
残念ながら、これはできません。サブドメインでワイルドカードを処理するルールは、サブドメインの 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
*.domain.com
これを処理するには、 用と 用の2 つの証明書を取得する必要がありますdomain.com
。これらのドメインを個別に処理するには、2 つの別個の IP アドレスと vhost を使用する必要があります。
答え3
最近のワイルドカードでは、サブジェクト別名フィールド (SAN) に *.domain.com と domain.com が含まれます。たとえば、quora.com のワイルドカード SSL 証明書を見てみましょう。
あなたは見るでしょう
件名の別名: *.quora.com、quora.com
答え4
いいえ、それらは完全に異なる名前空間であるためです。TLD をリダイレクトすることもオプションではありません。SSL はトランスポート暗号化であるため、たとえば Apache がリダイレクトする要求ホストを確認する前に SSL をデコードする必要があります。
また、補足として、foo.bar.domain.com もワイルドカード証明書には有効ではありません (記憶の限りでは、これを許可するのは Firefox だけです)。