Comodo Brasil - Certificados SSL - www.comodobr.com
Alguma dúvida?
DuvidaSaiba como falar
com os nossos
atendentes
.
SetaSaiba mais
Perdeu o seu Duvidacertificado?
Solicite aqui a sua reposição gratuita.
SetaClique aqui
Renove seu Certificado
RenovaçãoSaiba como renovar o seu certificado.
SetaSaiba mais

O que fazer se você precisa de Endereços Internos no seu certificado TLS/SSL

O prazo definido pelo CA/Browser Forum para o uso de Endereços Internos está se aproximando rapidamente, e muitos administradores de sistemas precisam entender como melhor se adaptar à mudança. Ao mesmo tempo, centenas de novos domínios de primeiro nível estão sendo disponibilizados, redefinindo o que constitui um Endereço Interno. Neste artigo, explicaremos quais são as mudanças, por que elas estão acontecendo e como você pode atualizar seus sistemas para se adequar.

Endereços Internos e DPNs Genéricos

Por definição, um endereço interno é: “Uma string de caracteres (não um IP) no campo Common Name ou Nome Alternativo (Subject Alternative Name) de um Certificado que não pode ser verificado como globalmente único no DNS público no momento da emissão do certificado por não terminar com um Domínio de Primeiro Nível registrado no Banco de Dados da Zona de Raiz da IANA.” Por exemplo: “mail” e “exchange.local” são Endereços Internos; “casecurity.org” e “paypal.com” são domínios registrados.

Sob as regras adotadas pelo CA/Browser Forum em 2011, As Autoridades Certificadoras (CAs) não poderão emitir certificados que contenham endereços internos com expiração após 1º de novembro de 2015. Como a maioria das CAs comercializam certificados por períodos de 1 ano ou múltiplos, na prática, isso significa que as certificadoras, parceiras e revendas não aceitarão pedidos de certificados contendo endereços internos após 1º de novembro de 2014. Além disso, as CAs revogarão todos os certificados que contenham endereços internos até 1º de outubro de 2016.

Isso se deve ao lançamento de novos DPNs pela ICANN. Em resumo, o CA/Browser Forum também adotou regras que exigem que as CAs parem de tratar os novos domínios de primeiro nível, tais como ‘.mail’, como endereços internos no prazo de 30 dias e revoguem todos os certificados existentes que contenham esses endereços dentro de 120 dias de assinado o contrato com a ICANN. Com a assinatura do contrato para '.exchange' em 6 de março de 2014, esse que era um dos Endereços Internos mais comuns já passou do prazo de 120 dias. As CAs já devem tratá-lo como um domínio de primeiro nível registrado e revogar todos os certificados existentes que contenham endereços que terminem em '.exchange'.

Por quê?

O motivo para todas essas regras é bastante simples e é explicado em maiores detalhes neste white paper do CA/Browser Forum. Endereços internos, por natureza, não são únicos, pois não são registrados em um registrar. Qualquer pessoa pode ter um servidor em https://mail/, por exemplo e, antes dessas regras, qualquer pessoa podia obter um certificado para ‘MAIL’. Isso possibilitava que um terceiro mal-intencionado adquirisse facilmente um certificado e lançasse um ataque man-in-the-middle (MITM). Redes Wi-Fi empresariais abertas ("guest") são um alvo particularmente interessante para este tipo de ataque, devido à probabilidade de a rede estar configurada para reconhecer qualquer endereço interno utilizado pela empresa.

No caso dos novos domínios de primeiro nível, existe um risco semelhante, já que o certificado pode ter sido emitido anteriormente para um endereço que passou a ser de um domínio registrado para outra empresa.

Soluções

Em alguns casos, não há solução fácil para os problemas criados pela dependência em endereços internos, mas existem algumas opções:

  1. Reconfigurar o sistema para utilizar um domínio registrado no Registro.br ou outro registrar;
  2. Registrar o endereço utilizado;
  3. Implantar uma autoridade certificadora própria;
  4. Utilizar certificados autoassinados.

A primeira opção – migrar os serviços para um domínio registrado – costuma ser a melhor solução para acabar com a dependência em endereços internos nos certificados TLS/SSL. Como costuma ser o caso, esta opção pode exigir um esforço inicial significativo, mas é quase sempre realizável. Contrário ao que alguns acreditam, o Microsoft Exchange pode ser reconfigurado para utilizar domínios registrados, assim como as redes Active Directory. A vantagem dessa abordagem é que não haverá qualquer ônus administrativo após a mudança – você poderá continuar a utilizar certificados de raiz confiável como já fazia antes. Uma preocupação que surge com essa abordagem é a quanto à possibilidade de expor publicamente informações sobre a infraestrutura interna da empresa via DNS. Esse risco pode ser mitigado utilizando um subdomínio como "interno" ou um domínio separado, e configurando o DNS para que essas zonas não possam ser resolvidas fora das redes da empresa.

A segunda opção é transformar os endereços internos que você utiliza atualmente em domínios registrados. Em teoria, endereços como 'ford.exchange' poderão ser registrados assim que o novo domínio de primeiro nível estiver disponível para registro. Na prática, isso demora mais do que os 120 dias de prazo das regras atuais, então, você terá que implementar uma solução diferente até conseguir registrar o domínio. Além disso, alguns novos DPNs não serão disponibilizados ao público geral para registro.

A terceira opção, "uma autoridade certificadora própria", é um software que age como uma Autoridade Certificadora confiável mas é operado pela e para a própria empresa. Tais sistemas podem emitir certificados que contenham endereços internos, porém os certificados não terão uma raiz pública confiável. Isso significa que a autoridade certificadora própria não pode ser configurada para assinar certificados sob as raízes confiáveis da Autoridade Certificadora, e os certificados emitidos pela autoridade certificadora própria farão com que os navegadores exibam avisos de confiabilidade para os usuários. Para contornar tais mensagens de erro, a solução é instalar as raízes da autoridade certificadora no cliente. Infelizmente, esse processo é complexo em qualquer ambiente heterogêneo que utilize vários navegadores (Firefox, Chrome, Internet Explorer), sistemas operacionais (Windows, OS X, Linux) e dispositivos (iOS, Android). Outro risco no caso de uma autoridade certificadora própria é que o comprometimento do sistema deixará a empresa vulnerável a um ataque MITM, por isso fortes medidas de segurança devem ser implementadas para proteger as chaves privadas e aplicações que possam ser usadas para emitir certificados.

A última opção é utilizar certificados autoassinados. Essa opção tem ressalvas semelhantes à da autoridade certificadora própria, mas não é boa em grande escala porque cada certificado deve ser instalado em todos os dispositivos cliente para evitar as mensagens de erro dos navegadores.

Além de implementar segurança às comunicações via navegador, sua empresa também pode utilizar certificados TLS/SSL para a segurança de comunicações entre servidores. Verifique se os servidores utilizam certificados com endereços internos atualmente. Caso utilizem, você deverá optar por uma das soluções acima, que não necessariamente será a mesma escolhida para o tráfego entre navegadores e servidores.

Fonte: CA Security Council

Atenção


A partir de 1º de julho de 2012, o uso de certificados que contenham um IP interno ou nome de máquina está condenado pelo CA/Browser Forum e será abolido até outubro de 2016. Também a partir de 1º de julho de 2012, a Comodo não emitirá com data de validade posterior a 31 de outubro de 2015 certificados com SANs ou Common Name (CN) contendo um IP interno ou nome de máquina. A partir de 1º de outubro de 2016, a Comodo revogará todos os certificados ainda não vencidos cujos campos SAN ou CN contenham um IP interno ou nome de máquina.

Se você utiliza um domínio de primeiro nível (TLD) que não seja atualmente um domínio de primeiro nível válido, como os listados acima, ou outros que porventura venhamos a permitir para seu uso interno neste pedido de certificado, informamos que, no caso de o domínio ser reconhecido pela IANA/ICANN como um domínio de primeiro nível válido, o certificado será revogado sem novo aviso. Para reemitir o certificado, será necessário comprovar a titularidade do domínio.

Entre em contato com nosso suporte para tirar dúvidas técnicas ou de instalação:

Atendimento online
Utilize os links no topo desta página

Email
suporte@comodobr.com

Telefones:

(21) 3527-0171  /  (11) 3136-0536  / (11) 4063-7724 /  (31) 4062-7422  /  (41) 4063-8177

Política de Reposição:
Se houver algum erro no seu CSR ou na instalação do seu certificado, clique aqui para solicitar a reposição do seu certificado ou entre envie um e-mail com a CSR nova e o número do pedido para validacao@comodobr.com. Lembre-se de que apenas fazemos o reembolso de certificados até 30 dias após a emissão.

WebTrust WebTrust EVSite Seguro