Tenho um consultor de segurança que está me dizendo que não podemos usar certificados SSL curinga por motivos de segurança. Para ser claro, prefiro usar certificados únicos ou certificados de vários domínios (SAN). No entanto, precisamos que o servidor (plesk) atenda centenas de subdomínios.
Com base em minha pesquisa, o principal motivo pelo qual as pessoas não usam curinga é o seguinte, que parece vir da Verisign:
- Segurança: Se um servidor ou subdomínio for comprometido, todos os subdomínios poderão ser comprometidos.
- Gerenciamento: Se o certificado curinga precisar ser revogado, todos os subdomínios precisarão de um novo certificado.
- Compatibilidade: Os certificados curinga podem não funcionar perfeitamente com
configurações de servidor-cliente mais antigas. - Proteção: Os certificados SSL Wildcard da VeriSign não são protegidos pela garantia estendida da NetSure.
Como a chave privada, o certificado e o subdomínio existirão no mesmo servidor... a substituição seria tão simples quanto substituir este certificado e afetaria a mesma quantidade de usuários. Portanto, há outro motivo para não usar um certificado curinga?
Responder1
A única outra 'pegadinha' que conheço é queOs certificados de validação estendida não podem ser emitidos com um curinga, portanto, não é uma opção se você deseja obter um certificado EV.
Em termos de segurança, você acertou em cheio - uma única chave privada protege todos os domínios que estão sob o curinga. Portanto, por exemplo, se você tivesse um certificado SAN de vários domínios que fosse coberto www.example.come something.example.comcomprometido, apenas esses dois domínios correm risco de ataque com a chave comprometida.
No entanto, se esse mesmo sistema estivesse executando um *.example.comcertificado para lidar com o tráfego SSL wwwe somethingsubdomínios e fosse comprometido, tudo coberto por esse curinga estaria potencialmente em risco, mesmo os serviços não hospedados diretamente nesse servidor - digamos, webmail.example.com.
Responder2
Segurança: Se um servidor ou subdomínio for comprometido, todos os subdomínios poderão ser comprometidos.
Se você estiver usando um único servidor web para centenas de hosts virtuais, todas as chaves privadas precisarão ser legíveis por esse processo do servidor web. Se uma pessoa pode comprometer o sistema a ponto de poder ler uma chave/certificado, provavelmente já comprometeu o sistema a um ponto em que pode obter todas as chaves/certificados privados usados por esse servidor web.
As chaves geralmente são armazenadas no sistema de arquivos com privilégios que permitirão apenas que o root as acesse. Portanto, se o seu sistema estiver enraizado, provavelmente você perdeu tudo. Realmente não importa se você tem um único certificado ou muitos.
Gerenciamento: Se o certificado curinga precisar ser revogado, todos os subdomínios precisarão de um novo certificado.
Se você estiver usando um curinga para *.example.org, precisará substituir apenas um único certificado. Se você tiver um certificado para one.example.org, two.example.org e three.example.org, será necessário substituir 3 certificados. Portanto, o certificado curinga dá menos trabalho. Então, sim, esse certificado seria revogado e substituído, mas como você só precisa substituir um em vez de centenas, deve ser muito fácil.
Compatibilidade: Os certificados curinga podem não funcionar perfeitamente com configurações de servidor-cliente mais antigas.
Esses sistemas quase certamente precisam ser atualizados. É quase certo que eles têm muitas outras vulnerabilidades.