Você só pode ter um nível de curinga.
*. example.com cobrirá anything.example.com, mas não one.anything.example.com.
*. subdomain.example.com manipulará anything.subdomain.example.com.
Temos um servidor de desenvolvimento que é acessível através da Internet, mas é restrito por IP, então a segurança aqui é apenas uma maneira de nos permitir reproduzir o ambiente ao invés de tentar ser seguro. O domínio de nível superior, vamos chamá-lo de dev.com , não é usado, mas os desenvolvedores têm cada site configurado em seu próprio subdomínio específico. Então, digamos que haja site1.com , site2.com e site3.com , então os desenvolvedores george e nico teriam URLs completos como:
Eu pensava que um certificado auto-assinado curinga faria isso, mas depois descobri que o *.dev.com se aplicava apenas a something.dev.com e não a sub-sub domínios. Decidi seguir as instruções em esta resposta . Quando eu uso:
DNS.1 = www.site2.com.nico.dev.com
DNS.2 = www.site1.com.george.dev.com
tudo funciona bem, mas infelizmente há muitos desenvolvedores de muitos sites, então haveria bem mais de 100 entradas para DNS.x aqui. Eu queria saber se é possível usar curingas na seção [ alternate_names ] do meu openssl.cnf . Eu tentei o seguinte:
DNS.1 = dev.com
DNS.2 = www.site1.com.george.dev.com
DNS.3 = *.*.*.nico.dev.com
Considerando que DNS.2 funcionou, DNS.3 não, dando-me o erro NET::ERR_CERT_COMMON_NAME_INVALID no Chrome.
Existe uma maneira de fazer isso, ou terei que gerar uma lista muito longa de DNS.x entradas para cobrir todos os sites?
Ouvi dizer que, ao criar minha própria CA, isso seria possível. Segui as excelentes instruções em esta resposta . Com minha própria CA intacta, criei um certificado com DNS.1 igual ao nome comum e DNS.2 e DNS.3 com curingas assim:
DNS.1 = dev.com
DNS.2 = *.dev.com
DNS.3 = *.*.*.*.nico.dev.com
Em seguida, importei cacert.pem da primeira etapa do guia vinculado acima para o cromo como uma autoridade de certificação raiz confiável e reiniciei o navegador. Para cada configuração de domínio, defino SSLCertificateKeyFile e SSLCertificateFile para serverkey.pem e servercert.pem e testei alguns domínios:
NET::ERR_CERT_COMMON_NAME_INVALID
NET::ERR_CERT_AUTHORITY_INVALID
Então parece que o primeiro nível de curinga funcionou bem, mas abaixo disso, não funcionou. Isso é o mesmo para o Chrome e o IE (que usam os certificados do Windows) e para o Firefox (que gerencia seus próprios).
Então, a minha pergunta permanece: o uso de domínios sub-sub (-sub *) é possível desta forma?
Certs assinados públicos:
Resposta técnica
Sim. Não há nada que impeça a criação de certificados SAN de subdomínio curinga com qualquer combinação de níveis e domínios de caracteres curingas. Se você gerencia sua própria CA interna, pode criar um certificado SAN com qualquer combinação de subdomínios, curingas, etc.
Resposta prática com base nas minhas próprias experiências
Não. ou não provável ... Eu não estou ciente de qualquer CA que irá vender-lhe um destes. Eu pedi várias CAs para esta solução e cada um dos imediatamente rejeitou o pedido. Eu suspeito que eles temem perder dinheiro oferecendo tais certificados. Eles preferem que você tenha um curinga para cada zona (subdomínio ou não) ou um certificado SAN com até n número de entradas. n sendo o número que a CA em particular irá limitar você. Não consegui encontrar uma CA que vendesse um certificado SAN com uma mistura de entradas de subdomínio com curingas. Eu forneceria uma lista dos CAs que eu consultei, mas suspeito que isso possa não ser apropriado aqui.
[Atualização]
Certs autoproclamados
Eu entendi mal a intenção da pergunta. Eu acredito que um exemplo openssl.cnf foi desejado. Aqui está um exemplo . precisa substituir as entradas DNS por seus nomes de subdomínio com curingas. Há algumas postagens em security.stackexchange.com bem em torno desta configuração. Eu não testei isso, pois minhas necessidades eram em torno de URLs acessíveis publicamente e as CAs não permitiam isso como uma opção.
Tags https ssl-certificate wildcard