Certificados Wildcard - Certificado Corporativa
ICPEdu - Infraestrutura de Chaves Públicas para Ensino e Pesquisa
Primeiramente, o que é um certificado Wildcard?
A grande maioria dos certificados digitais são emitidos para proteger um único nome de domínio. Com certificados Wildcard podemos proteger todos os subdomínios de um determinado domínio com um único certificado.
Utilizando apenas um certificado digital wildcard emitido para o domínio *.rnp.br você protege o seu domínio principal (Ex. rnp.br) e todos os seus subdomínios (Ex. mail.rnp.br, mconf.rnp.br, etc).
Como o Certificado Wildcard SSL funciona?
Todo certificado standard são emitidos para um CN (Common Name) único, certificados wildcard também são emitidos para um CN único, mas com um formato levemente diferente, o CN de um certificado wildcard deve conter obrigatoriamente um asterisco (*) que transforma aquele CN em "coringa"simbolizando a área variável do domínio.
O asterisco (*) permite que o certificado proteja um número ilimitado de possíveis subdomínios, ele simboliza qual parte do subdomínio é variável. Um certificado wildcard emitido para *.rnp.br, por exemplo, é capaz de proteger vários subdomínios como: primeiro.rnp.br, www.rnp.br, www2.rnp.br, mconf.rnp.br, mail.rnp.br e todos possíveis subdomínios de primeiro nível do domínio rnp.br.
Vale lembrar que os certificados wildcard protegem apenas subdomínios de primeiro nível, algo como primeiro.rnp.br. Subdomínios de segundo, terceiro ou mais níveis como segundo.primeiro.rnp.br e terceiro.segundo.primeiro.rnp.br, respectivamente, não são protegidos pelo certificado wildcard emitido para *.rnp.br.
Em resumo, o certificado wildcard emitido para *.seudominio.edu.br, protege qualquer subdomínio inserido no local do asterisco (*) - desde que não seja inserido um ponto (.) neste subdomínio.
Quando usar certificados Wildcard?
Ao utilizar o Apache, por exemplo, precisamos de um conjunto de endereço IP e porta distintos para cada site com SSL no servidor, isso porque não se pode utilizar VirtualHosts baseados em nome.
Essa limitação não é do apache, mas sim do modo como as conexões SSL ocorrem visto que este tipo de VirtualHost depende de informação presente no pedido HTTP, mas o cabeçalho que carrega este pedido está encriptado e precisamos da informação que está dentro dele para desencriptar o próprio cabeçalho, gerando uma dependência mútua.
Para isso, temos 4 possíveis soluções:
- Criar VirtualHosts com portas diferentes da padrão (443): É uma solução simples de ser implementada, mas trabalhosa de ser utilizada pois todos usuários teriam que acrescentar ao final da URL a porta configurada no VirtualHost "https://teste.rnp.br:ZZZ". Firewalls e aumentar a dificuldade para o usuário final são os principais ofensores desta solução.
- Configurar vários IPs para a placa de rede do servidor: Esta solução dependerá principalmente do seu sistema operacional e da sua disponibilidade de IPs, pode também não ser uma solução viável. Disponibilidade de endereços IP e aumento da complexidade da infra são os principais ofensores desta solução.
- Usar certificados Wildcard: Desta forma teremos um único certificado para vários sites SSL, sem a necessidade de criarmos vários VirtualHosts - pois todos apontariam para o mesmo certificado -, assim eliminando os problemas citados nas duas primeiras soluções, porém, criando alguns novos que serão abordados a seguir.
- Usar certificados com SAN: Entenda o que são Subject Altenative Names (SAN's) e como utilizar, clicando aqui.
- Usar certificados Wildcard: Desta forma teremos um único certificado para vários sites SSL, sem a necessidade de criarmos vários VirtualHosts - pois todos apontariam para o mesmo certificado -, assim eliminando os problemas citados nas duas primeiras soluções, porém, criando alguns novos que serão abordados a seguir.
Porque não usar certificados WildCard?
Como bem sabemos, certificados wildcard são uma solução rápida, prática e facilita a configuração e administração dos servidores, porém, cria novos pontos de vulnerabilidade.
Certificados wildcards são comumente utilizados para vários sites e instalados em vários servidores diferentes, aumentando a probabilidade de comprometimento da chave. Imagine que alguém consiga acesso a um destes servidores, este poderá copiar o certificado e a chave e instalá-los fora dos domínios da empresa, se passando pelo site verdadeiro da organização.
O atacante poderia também capturar o tráfego encriptado dos sites que utilizam aquele certificado e de posse da chave desencriptar estes dados, tendo acesso a informações consideradas sigilosas entre cliente e servidor.
Em resumo, certificados wildcard são uma solução, porém, devem ser evitados sempre que possível, clique aqui e conheça uma alternativa .
Dúvidas, críticas ou sugestões
Tem dúvidas sobre o a modalidade e AC SSL Corporativa? Clique aqui e acesse nosso FAQ.
Quer aderir a modalidade AC SSL Corporativa? Clique aqui e entenda o processo de adesão.
Quer entender como operar o portal web da modalidade AC SSL Corporativa? Clique aqui e acesso nossos manuais e instruções de uso.
Quer aprender mais sobre certificados com Subject Alternative Names (SAN's)? Clique aqui.
Acesso o site oficial do serviço clicando aqui.
atendimento@icp.edu.br
Service Desk RNP
Telefones: +55 (61) 3243-4330
Fone@RNP: (61) 1030-3001 e (61) 1030-3002
E-mail: sd@rnp.br
O horário de atendimento do Service Desk é das 08:00 as 22:00 todos os dias.