en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

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.

Ejemplo: Robert Dobbs es un administrador de sistemas senior de AwfuBigCo. Entre otros trabajos, administra (teóricamente) los certificados de seguridad de la corporación. Sin embargo, se han configurado para renovarse automáticamente cada 2 de noviembre, lo que ha estado sucediendo como un reloj desde mucho antes de que Bob llegara aquí, y ni siquiera ve la factura. En algún lugar antes del álbum de regreso de Dre, la arquitectura de red de AwfulBigCo se configuró para incluir cuatro servidores Exchange llamados "Abc.exchange""Correo", "Mail2" y "Gandalf", además de una dirección IP interna (10.10.10.10) configurada para copias de seguridad FTP seguras y dos servidores utilizados para los equipos de desarrollo de Londres y Nueva York. Han estado protegiendo sus servidores Exchange Y sus otros dominios con una Certificado UCC que contiene las siguientes entradas:

* .awfulbigco.com
* .awfulbigco.co.uk
awfulbigco.londres
awfulbigco.nyc
abc.intercambio

Gandalf
Mande Por Correo
Correo2
10.10.10.10

2 de noviembre de 2015. Bob recibe una llamada telefónica de Elaine en International Fulfillment: tiene problemas con Outlook. Mientras le dice que revise su configuración, recibe un mensaje de texto de Nathan en la sucursal del Reino Unido: algunas de las imágenes en el sitio web están rotas y el formulario de pedido se agota. Luego, otro mensaje de texto de un vicepresidente de marketing que quiere saber por qué su demostración en Singapur acaba de fracasar frente a una sala de juntas de posibles inversores ... Y lo crea o no, el día de Bob va a ser mucho, mucho más peor antes de que mejore.

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.

Tenga en cuenta que nuestro equipo en SSL.com definitivamente habría marcado la configuración de AwfulBigCo en su última renovación para ayudar a Bob a evitar estos problemas exactos. De hecho, cualquier CA de buena reputación tomaría medidas para ayudar a sus clientes antes de la fecha límite del 1 de noviembre, si se le pregunta y si Bob supiera qué preguntas hacer, es por eso que presentamos este artículo.

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áctanos en SSL.com si tiene alguna pregunta. Recuerde: una Internet más segura es una Internet mejor.

Artículos Relacionados

Suscríbase al boletín de SSL.com

Que es SSL /TLS?

Reproducir vídeo

Suscríbase al boletín de SSL.com

No te pierdas los nuevos artículos y actualizaciones de SSL.com