Se acerca el 1 de noviembre: ¿está listo su servidor Exchange?

1 de noviembre de 2015: nuevas reglas entran en vigencia

A tus amigos de SSL.com les gustaría comunicarte ese comienzo Noviembre 1, 2015, algunos cambios muy importantes con respecto a lo que se puede cubrir en Certificados SSL están tomando efecto:

• Los nuevos certificados que contienen nombres internos ya no serán emitidos por ninguna autoridad certificadora siguiendo las pautas de CA / Browser Forum (es decir, todos los de buena reputación)
  
  Tenga en cuenta que desde hace algún tiempo SSL.com no ha emitido certificados de intranet a nombres internos con fechas de vencimiento posteriores al 1 de noviembre de 2015 y, por lo tanto, los clientes de SSL.com no deberían encontrar ningún problema inmediato; sin embargo, le recomendamos encarecidamente que vuelva a verificar sus certificados. para conocer las posibles formas en que estos fallos pueden afectarlo.
• Los certificados existentes que contengan nombres internos no se volverán a emitir después del 1 de noviembre de 2015.
  
  Nuevamente, SSL.com ha trabajado para asegurarse de que no tenga problemas debido a esto; sin embargo, presentamos el peor de los casos para su edificación a continuación.
• Los certificados existentes que contengan nombres internos serán AUTOMÁTICAMENTE REVOCADOS el 1 de noviembre de 2016.
  
  Esta es una política general, ya que algunas arquitecturas de seguridad pueden tener certificados heredados de larga data que no cumplen con estas reglas.

Estos cambios significan que el correo electrónico, la primera y aún más útil herramienta de Internet, puede verse afectada negativamente por los cambios, especialmente si está utilizando Exchange Server de Microsoft (que según las investigaciones de mercado es el 63 por ciento de todos ustedes). Por lo tanto, su arquitectura de seguridad podría comenzar a verse afectada a partir del próximo Día de Todos los Santos.

¿Listo para iniciar?

¿Qué quiere decir cuando dice "nombres internos"?

La definición más simple de un nombre interno es cualquier identificador de red que parte de una red privada y no se puede acceder usando un nombre usando un dominio de nivel superior (TLD) o una dirección IP única. Por implicación, cualquier ID de red que esté registrada públicamente con una autoridad central como ICAAN se podrá utilizar en los certificados.

En los primeros días más simples de Internet, una arquitectura de DNS interna solo tenía que preocuparse por evitar un conjunto limitado de TLD; por lo tanto, la intranet de AwfulBigCo.com no solo podía admitir ABC.nyc y ABC.londres pero 1600. Pennsylvania.ave, mail y Gandalf Además, algunos rangos de direcciones IPv4 e IPv6 se reservan para uso puramente local: estos rangos reservados incluyen “192.168. *. *” para enrutamiento y 10. *. *. * para redes locales. Asegurar las intranets con certificados SSL es, por supuesto, una buena idea y, hasta la nueva regla, cualquier administrador de red podría solicitar y recibir un certificado que incluya cualquiera de estos.

A partir del 1 de noviembre de 2015, este ya no será el caso, ya no se emitirán certificados. o, crucialmente, emitido RE - que contienen nombres internos. Estas nuevas reglas están diseñadas para mejorar la seguridad y permitir el uso adecuado de los nuevos nombres de dominio de nivel superior (por ejemplo, tanto .london como .nyc son TLD públicos ahora). Sin embargo, sí requieren que cualquier usuario de Exchange examine detenidamente su configuración de red y seguridad y realice cambios para reconocer estas nuevas reglas. Dado que muchos diseños de seguridad de Exchange han utilizado históricamente nombres internos, esto puede causar serios problemas con su servicio de correo cuando sus certificados vencen, ya que no se pueden emitir nuevos certificados con nombres internos para reemplazar los existentes; peor aún, cualquier certificado multidominio que contenga incluso un nombre interno fallará en la renovación, exponiendo potencialmente su tráfico de correo a exploits maliciosos.

No hacerlo puede afectar negativamente su tráfico de correo, su negocio y / o su reputación.

Suena Dire.

Muy bien podría ser, realmente depende de lo preparado que esté. Este podría ser un problema muy fácil de pasar por alto y las consecuencias podrían ser absolutamente fatales para su negocio: if no actúas antes de tiempo.

Vea, el proveedor de certificados de AwfulBigCo ejecutó su solicitud más allá de sus robots, detectó esos nombres internos y (según las reglas del Foro CA / B) rechazó la renovación.

Esto es un problema. La UCC NO se renovará y no solo los servicios que utilizan los nombres internos de diallowed (es decir, todo el correo corporativo y las copias de seguridad de FTP) ya no estarán protegidos, ni ningún OTRO dominio incluido en la UCC, como el primario y .co. uk dominios para AwfulBigCo.

Claro, este es el peor de los casos extremos, pero realmente creemos que la seguridad total depende de prepararse exactamente para eso.

Bien, tengo miedo legítimo, ¿qué hago ahora?

Si está utilizando nombres internos en sus certificados SSL, necesitará tomar medidas para solucionar esto, y cuanto antes, mejor.

Básicamente, hay algunas opciones que puede elegir:

1. Reconfigure el sistema para usar solo nombres de dominio registrados públicamente.
   Esta es probablemente la mejor solución: hace que el problema del nombre interno sea discutible y, en general, será más simple de mantener y extender en el futuro. Desafortunadamente, esta opción probablemente requerirá un trabajo considerable por adelantado, pero los servidores de Microsoft Exchange se pueden configurar utilizar nombres de dominio público totalmente calificados (y este CA / Foro de navegadores detalles de la moneda brinda más información sobre la implementación de FQDN en redes de Active Directory). La administración después del cambio será casi con certeza tan simple o más simple que antes (una gran ventaja para Bob) y, en el futuro, AwfulBigCo podrá usar certificados de confianza pública para proteger todo el tráfico tanto interno como externo. Un posible inconveniente de este método es que puede permitir que se descubra información sobre la infraestructura interna de una empresa a través de DNS, pero la configuración inteligente de las zonas DNS puede ayudar a abordar esto, por ejemplo, utilizando subdominios como "internos" o nombres de dominio separados y limitando la resolución. de estos fuera de las redes de la empresa.
2. Registre nombres internos como FQDN.
   Desafortunadamente, no es una opción para esa dirección IP reservada, y "Mail" y "Gandalf", por supuesto, son correctos. (Asumiremos, por el bien de la cordura de Bob, que los dominios .com y .co.uk ya están registrados de forma segura, ya que su día ya es bastante duro).
   Además, incluso si abc.intercambio está disponible, y recuerde que .exchange es uno de los nuevos dominios de nivel superior cuya introducción está ayudando a impulsar este cambio de reglas; bien podría estar ocupado y solo disponible por un precio exorbitante; es probable que haya alternativas más fáciles y económicas disponibles.
3. Configurar una CA empresarial
   Este es un método ya empleado por entidades verdaderamente grandes que necesitan proteger principalmente las comunicaciones internas. Una CA empresarial sirve como una autoridad certificadora corporativa; básicamente, en lugar de que la cadena de confianza se ejecute hasta una CA externa, todos los certificados están finalmente protegidos por un certificado raíz generado internamente. Si bien esto brinda una mayor personalización (y permitiría a Bob mantener la estructura de nomenclatura heredada que AwfulBigCo tiene en su lugar) hay serios problemas de seguridad a considerar: un pirateo al estilo de Sony podría exponer el certificado raíz de la empresa y / o la clave privada, permitiendo una explotación casi ilimitada de la red. Además, los certificados emitidos internamente NO serán confiables en otros lugares; este es un método que protege las comunicaciones internas pero no puede extender la confianza más allá de las paredes de su red comercial. Por último, configurar una CA empresarial no es de ninguna manera una solución de la noche a la mañana y podría ser mucho más difícil que las otras opciones enumeradas aquí y, por lo tanto, solo viable para redes muy grandes (o en crecimiento).
   
   SSL.com se complace en ofrecer servicios de consultoría y administración para ayudarlo a negociar el camino para configurar su propia CA empresarial; simplemente envíe un mensaje a empresaca@ssl.com y uno de nuestros administradores superiores se comunicará con usted pronto.
4. Use certificados autofirmados
   Esta opción tiene inconvenientes similares a los de la CA empresarial, pero no se escala bien: dado que cada certificado autofirmado no tiene una cadena de confianza más allá de sí mismo, cada certificado individual tendría que instalarse en todos y cada uno de los clientes para evitar mensajes de error. . La administración a través de una red amplia también crearía una nueva serie de dolores de cabeza para el pobre Bob: algo tan simple como las actualizaciones automáticas del navegador podría causar estragos a menos que se mantenga una vigilancia continua en todos los dispositivos.

Como siempre, contáctenos en SSL.com si tiene alguna pregunta. Recuerde: una Internet más segura es una Internet mejor.