1º de novembro está chegando - seu Exchange Server está pronto?

1 de novembro de 2015: novas regras entrando em vigor

Seus amigos em SSL.com gostariam de informá-lo sobre o começo Novembro 1st, 2015, alguns mudanças muito importantes sobre o que pode ser coberto em certificados SSL estão entrando em vigor:

• Novos certificados contendo nomes internos não serão mais emitidos por nenhuma autoridade de certificação seguindo as diretrizes CA / Fórum do navegador (ou seja, todos os respeitáveis)
  
  Observe que há algum tempo SSL.com não tem emitido certificados de intranet para nomes internos com datas de expiração após 1º de novembro de 2015 e, portanto, os clientes SSL.com não devem encontrar nenhum problema imediato - no entanto, recomendamos que você verifique novamente seus certificados para saber como essas decisões podem impactar você.
• Os certificados existentes contendo nomes internos não serão emitidos novamente após 1º de novembro de 2015.
  
  Novamente, SSL.com trabalhou para garantir que você não tivesse problemas devido a isso - no entanto, apresentamos um cenário de pior caso para sua edificação abaixo.
• Os certificados existentes contendo nomes internos serão REVOGADOS AUTOMATICAMENTE em 1º de novembro de 2016.
  
  Essa é uma política abrangente, pois algumas arquiteturas de segurança podem ter certificados herdados existentes há muito tempo que não seguem essas regras.

Essas mudanças significam que o e-mail - a primeira e ainda mais útil ferramenta da Internet - pode ser afetado negativamente pelas mudanças, principalmente se você estiver usando o Microsoft Exchange Server (que a pesquisa de mercado sugere que é 63% de vocês). Assim, sua arquitetura de segurança pode começar a ser afetada a partir do próximo Dia de Todos os Santos.

Está pronto para começar?

O que você quer dizer quando diz “nomes internos”?

A definição mais simples de um nome interno é qualquer identificador de rede que parte de uma rede privada e inacessível usando um nome usando um domínio de nível superior (TLD) ou endereço IP exclusivo. Por implicação, qualquer ID de rede registrado publicamente com uma autoridade central como ICAAN será utilizável em certificados

No início, os dias mais simples da Internet, uma arquitetura DNS interna precisava se preocupar apenas em evitar um conjunto limitado de TLDs - assim, a intranet de AwfulBigCo.com podia oferecer suporte não apenas ABC.nyc e ABC.londres mas a 1600.pensilvânia.ave, enviar e Gandalf. Além disso, alguns intervalos de endereços IPv4 e IPv6 são reservados para uso puramente local - esses intervalos reservados incluem “192.168. *. *” para roteamento e 10. *. *. * para redes locais. Proteger intranets com certificados SSL é, obviamente, uma boa ideia e, até a nova regra, qualquer administrador de rede poderia solicitar e receber um certificado que incluísse qualquer um deles.

A partir de 1º de novembro de 2015, esse não será mais o caso - os certificados não serão mais emitidos - ou, crucialmente, emitido pela RE - que contém nomes internos. Essas novas regras foram criadas para melhorar a segurança e permitir o uso adequado de novos nomes de domínio de primeiro nível (por exemplo, .london e .nyc agora são TLDs públicos). No entanto, eles exigem que qualquer usuário do Exchange examine cuidadosamente sua rede e configuração de segurança e faça alterações para reconhecer essas novas regras. Uma vez que muitos projetos de segurança do Exchange utilizaram historicamente nomes internos, isso pode causar sérios problemas com seu serviço de e-mail quando e à medida que seus certificados expiram, uma vez que novos certificados com nomes internos não podem ser emitidos para substituir os existentes - pior ainda, qualquer certificado de vários domínios contendo até mesmo um nome interno falhará na renovação, potencialmente expondo seu tráfego de e-mail a explorações maliciosas.

Não fazer isso pode afetar negativamente o tráfego de mensagens, seus negócios e / ou sua reputação.

Parece terrível.

Poderia muito bem ser - realmente depende de como você está preparado. Este pode ser um problema muito fácil de ignorar e as consequências podem ser absolutamente fatais para o seu negócio - if você falha em agir antes do tempo.

Veja, o provedor de certificado do AwfulBigCo executou sua solicitação em seus robôs, detectou esses nomes internos e (de acordo com as regras do Fórum CA / B) recusou a renovação.

Isto é um problema. O UCC NÃO será renovado e não apenas os serviços que usam nomes internos discados (ou seja, todos os emails corporativos e backups de FTP) não serão mais protegidos - nem quaisquer OUTROS domínios incluídos no UCC, como o principal e .co. domínios do Reino Unido para AwfulBigCo.

Claro, este é um cenário de pior caso extremo - mas realmente acreditamos que a segurança total depende da preparação exatamente para isso.

Ok, estou com medo legítimo - O que eu faço agora?

Se estiver usando nomes internos em seus certificados SSL, você PRECISARÁ tomar medidas para resolver isso e, quanto antes, melhor.

Basicamente, existem algumas opções que você pode escolher:

1. Reconfigure o sistema para usar apenas nomes de domínio registrados publicamente.
   Esta é provavelmente a melhor solução - torna a questão do nome interno discutível e será mais simples de manter e estender no futuro. Infelizmente, essa opção provavelmente exigirá um trabalho inicial considerável, mas os servidores Microsoft Exchange podem ser configurados usar nomes de domínio público totalmente qualificados (e este fórum CA / navegador artigo: informa mais sobre a implementação de FQDNs em redes do Active Directory). A administração após a mudança quase certamente será tão simples ou mais simples do que antes (uma grande vantagem para Bob) e, no futuro, AwfulBigCo será capaz de usar certificados de confiança pública para proteger todo o tráfego interna e externamente. Uma possível desvantagem desse método é que ele pode permitir que informações sobre a infraestrutura interna de uma empresa sejam descobertas via DNS, mas a configuração inteligente de zonas DNS pode ajudar a resolver isso - por exemplo, usando subdomínios como nomes de domínio "internos" ou separados e resolução limitada destes fora das redes da empresa.
2. Registre nomes internos como FQDNs.
   Infelizmente, não é uma opção para esse endereço IP reservado, e “Mail” e “Gandalf”, claro, estão fora de questão. (Vamos presumir, para o bem da sanidade de Bob, que os domínios .com e .co.uk já estão registrados com segurança - seu dia já está difícil do jeito que está.)
   Além disso, mesmo se abc.troca está disponível - e lembre-se de que .exchange é um dos novos TLDs cuja introdução está ajudando a impulsionar essa mudança de regra - poderia muito bem ser invadido e disponível apenas por um preço exorbitante - alternativas mais fáceis e mais baratas provavelmente estão disponíveis.
3. Configurar uma autoridade de certificação corporativa
   Este é um método já empregado por entidades verdadeiramente grandes que precisam proteger principalmente as comunicações internas. Uma CA corporativa atua como uma autoridade de certificação corporativa - essencialmente, em vez da cadeia de confiança correndo para uma CA externa, todos os certificados são protegidos por um certificado raiz gerado internamente. Embora isso dê maior personalização (e permitiria a Bob manter a estrutura de nomenclatura legada que AwfulBigCo possui), há sérios problemas de segurança a serem considerados - um hack no estilo Sony poderia expor o certificado raiz corporativo e / ou a chave privada, permitindo a exploração quase ilimitada da rede. Além disso, os certificados emitidos internamente NÃO serão confiáveis ​​em nenhum outro lugar - este é um método que protege as comunicações internas, mas não pode estender a confiança além das paredes da rede da sua empresa. Finalmente, configurar uma CA corporativa não é de forma alguma uma solução da noite para o dia e pode ser muito mais difícil do que as outras opções listadas aqui e, portanto, apenas viável para redes muito grandes (ou em crescimento).
   
   SSL.com tem o prazer de oferecer serviços de consultoria e gerenciamento para ajudá-lo a negociar o caminho para configurar sua própria CA corporativa - basta enviar uma mensagem para empresaca@ssl.com e um de nossos administradores seniores entrará em contato com você em breve.
4. Use certificados autoassinados
   Esta opção tem desvantagens semelhantes àquela da CA corporativa, mas não se adapta bem - uma vez que cada certificado autoassinado não tem nenhuma cadeia de confiança além de si mesmo, cada certificado individual teria que ser instalado em cada cliente para evitar mensagens de erro . O gerenciamento em uma rede ampla também criaria uma nova onda de dores de cabeça para o pobre Bob - algo tão simples como atualizações automáticas do navegador poderia causar estragos, a menos que a vigilância contínua seja mantida em cada dispositivo.

Como sempre, Contacte-nos em SSL.com se você tiver alguma dúvida. Lembre-se: uma Internet mais segura é uma Internet melhor.