Eu pareço lembrar que * .domain.com na verdade viola a RFC de qualquer maneira (eu acho que apenas o lince reclama:)
Crie um certificado com domain.com como CN e * .domain.com no campo subjectAltName:dNSName names - que funciona.
Para o openssl, adicione isso às extensões:
subjectAltName = DNS:*.domain.com
Infelizmente você não pode fazer isso. As regras para lidar com curingas em subdomínios são semelhantes às regras sobre cookies para subdomínios.
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
Para lidar com isso, você precisará obter dois certificados, um para *.domain.com e outro para domain.com . Você precisará usar dois endereços IP separados e vhosts dois lidarão com esses domínios separadamente.
Os curingas nos dias de hoje terão * .domínio.com e domínio.com no campo de nome alternativo de assunto (SAN). Por exemplo, dê uma olhada no certificado SSL curinga do quora.com
Você verá
Nomes alternativos de assunto: * .quora.com, quora.com
Provavelmente não é a resposta que você está procurando, mas tenho 99% de certeza de que não há uma maneira. Redirecione o link para o link e apenas use o *. domain.com como o certificado SSL. Está longe de ser perfeito, mas deve cobrir a maioria dos casos em que você está interessado. A única outra alternativa é usar endereços IP diferentes para domain.com e www.domain.com. Então você pode usar certificados diferentes para cada IP.
Não, porque eles são um espaço de nome completamente diferente. redirecionar o tld não é uma opção porque SSL é uma criptografia de transporte que precisa decodificar o ssl antes que o apache, por exemplo, possa até mesmo ver o host de solicitação para redirecioná-lo.
Também como uma observação: foo.bar.domain.com também não é válido para um certificado curinga (o firefox da memória é o único que permitirá isso.
Tags ssl openssl certificate wildcard