Baza znanja

Certificado para Endereços Internos

Desde 2015 não é mais possível a emissão de certificados para endereços ou IPs internos, e muitos administradores de sistemas ainda 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; "sectigo.com.br" e "paypal.com" são domínios registrados.

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 cadastrados em um site de registro de domínios. 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:

• looks_one

  Reconfigurar o sistema para utilizar um domínio registrado no Registro.br ou outro registar

  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.

• looks_two

  Registrar o endereço utilizado

  Transforme 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.

• looks_3

  Implantar uma autoridade certificadora própria

  Utilizar 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.

• looks_4

  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.