14 votos

Outlook alerta de seguridad - El nombre en el certificado de seguridad no es válido o no coincidir con el nombre del sitio

SBS 2008 ejecutando Exchange 2007 y IIS6.0

CompanyA tiene otras dos empresas que operen bajo el mismo techo. Para dar cabida a correo electrónico, tenemos 3 cuentas de Exchange por usuario para manejar esto. Todos los usuarios utilizar su CompanyA de cuenta para iniciar sesión en el dominio.

  • CORP\usuario user@companyA.com
  • CORP\usuario-companyb user@companyB.com <-- sólo se utiliza para el correo electrónico
  • CORP\usuario-companyc user@companyC.com <-- sólo se utiliza para el correo electrónico

El correo electrónico funciona bien internamente y a través de OWA. El problema existe cuando la configuración de Outlook para los usuarios remotos que necesitan acceso a companyB y companyC correos electrónicos, Outlook aparece el error de certificado.

El certificado SSL SAN dispone de los siguientes nombres DNS:

  • webmail.companyA.com
  • www.webmail.companyA.com
  • CORP-SBS
  • CORP-SBS.local
  • autdiscover.companyA.com

Me dijeron que por los usuarios que tienen acceso a companyC dirección de correo electrónico de forma remota que nunca antes. Esto comenzó con el CEO cambiado los proveedores de DNS en su propio y en el proceso de la original configuración de DNS se perdieron. Mencionó algo acerca de un registro SRV de ser creado que corrige este problema, pero de eso se trata.

Buscando orientación sobre cómo abordar correctamente esta.

25voto

Cosmic Ossifrage Puntos777

Este problema es más probable que sea causado por Outlook detección automática de servicio, parte de la de Outlook en cualquier Lugar de la funcionalidad. Detección automática proporciona información para el usuario final del cliente de Outlook en los diferentes servicios ofrecidos por Intercambio y donde estas puede ser localizado; éste se utiliza para una variedad de propósitos:

  • Configuración automática de los perfiles de Outlook en la primera ejecución de Outlook, que puede configurar una cuenta de Exchange utilizando sólo la dirección de correo del usuario y la contraseña, ya que el resto de la información se encuentra de forma automática y se recupera.

  • Dinámica de la ubicación de los servicios basados en la web consultado por el cliente de Outlook, incluyendo el ayudante de office, Mensajería Unificada de la funcionalidad, la ubicación del Panel de Control de Exchange (ECP), y así sucesivamente.

Este es Microsoft implementación de propiedad de RFC 6186. Por desgracia, no realmente seguir las recomendaciones de que el RFC en Outlook en cualquier Lugar del diseño, pero es tal vez a esperar, ya que el Intercambio y la RPC sobre HTTPS funcionalidad no es un tradicional IMAP/SMTP del servidor.


¿Cómo funciona la detección automática de trabajo (para exterior* usuarios)?

Detección automática se comunica con un servicio web en un Servidor de Acceso de Cliente (en este caso, todos los papeles están en el servidor SBS) en la ruta /Autodiscover/Autodiscover.xml, radicada fuera de su sitio web predeterminado. Para localizar el FQDN del servidor para comunicarse con el, se elimina la parte del usuario la dirección de correo electrónico, dejando el dominio (es decir, @companyB.com). Que intenta comunicarse con detección automática de uso de cada una de las siguientes direcciones Url:

  • https://companyB.com/Autodiscover/Autodiscover.xml
  • https://autodiscover.companyB.com/Autodiscover/Autodiscover.xml

Si estos fallan, se intentará una conexión no segura mediante la desactivación de SSL y de intentar comunicarse en el puerto 80 (HTTP), por lo general después de preguntar al usuario para confirmar que esta es una práctica aceptable (una falsa opción, en mi opinión, ya que ni idea de usuarios suelen aprobar este riesgo y el envío de credenciales a través de texto sin formato-y ni idea de los administradores de sistemas que no requieren de la comunicación segura de credenciales y de negocios de datos sensibles son un riesgo para la continuidad del negocio).

Por último, un seguimiento de verificación se realiza mediante un registro de servicio (SRV) en el DNS, el cual se encuentra en una ubicación conocida fuera de la companyB.com de espacio de nombres y puede redirigir Outlook a la dirección URL correcta en la que el servidor está a la escucha.


¿Qué puede ir mal?

Uno de los varios problemas que pueden surgir en este proceso:

No hay entradas DNS

Normalmente, la root del dominio (companyB.com) podría no resolver a un registro de host en el servidor DNS. Incorrecta configuración de DNS (o una decisión consciente de no exponer el Outlook en cualquier Lugar de servicio) puede significar autodiscover.companyB.com registro no existe.

En estos casos, no hay ningún problema importante; simplemente Outlook sigue comunicándose con Exchange utilizando la última configuración conocida, y puede ser degradado con respecto a ciertas web basado en funciones para la que se necesita para recuperar las direcciones Url a través de la detección automática (tales como el ayudante de office). Una solución es utilizar Outlook Web Access para acceder a esas funciones.

Configuración automática de cuentas de Exchange en nuevos perfiles de Outlook tampoco es automatizado y requiere la configuración manual de la RPC sobre HTTPS configuración. Sin embargo, esto no hará que el problema que usted describe.

Defectuoso certificados SSL

Es enteramente posible que la URL de Outlook utiliza para tratar de contactar con el Servidor de Exchange se resuelve en un host, que puede o no puede ser un Servidor de Acceso de Cliente. Si Outlook se puede comunicar con el servidor en el puerto 443, certificados, por supuesto, ser intercambiados para establecer un canal seguro entre Outlook y el servidor remoto. Si la dirección URL de Outlook cree que está hablando no aparece en el certificado (como el nombre común o un nombre alternativo del sujeto (SAN) -- esto va a provocar Outlook para presentar el cuadro de diálogo que usted describe en su mensaje inicial.

Esto puede suceder por varias razones, todas de cómo DNS está configurado y cómo las Url que he descrito anteriormente son revisados por Outlook:

  • Si el https://companyB.com/... URL resuelve un registro de host, y el servidor web en la dirección que escuche en el puerto 443, y tiene un certificado SSL que hace no lista companyB.com el nombre común o Nombre Alternativo del Sujeto, entonces el problema va a ocurrir. No importa si el host es un Servidor de Exchange o no; puede ser un servidor web que aloja un sitio web de la empresa que no está configurado correctamente. Corrige :

    • Deshabilitar el registro de host en la root de la companyB.com de la zona (que requiere que los visitantes de la página web o cualquier otro servicio a entrar www.companyB.com, o su equivalente; o
    • Deshabilitar el acceso a la máquina en companyB.com en el puerto 443, causando Outlook para rechazar la companyB.com dirección URL antes de que los certificados se intercambian y se mueve; o
    • Fijar el certificado en companyB.com asegurar companyB.com aparece en dicho certificado, y que los intentos para visitar https://companyB.com en un navegador estándar no fallan.

    Lo anterior se aplica independientemente de si companyB.com se resuelve en el Servidor de Exchange; si Outlook se puede comunicar con él, después de descubrir que el /Autodiscover/Autodiscover.xml ruta de los rendimientos de un error HTTP 404 (no existe) y seguir adelante.

  • Si el https://autodiscover.companyB.com/... URL resuelve el Servidor de Exchange (o cualquier otro servidor) pero, de nuevo, autodiscover.companyB.com no está en la lista como el nombre común o un nombre alternativo del sujeto, se observa este comportamiento. Puede ser fija arriba en la fijación del certificado, o como muy bien indican, puede utilizar un registro SRV para redirigir Outlook a una URL que se indica en el certificado y que Outlook puede comunicarse con.

Su probable solución a este problema

En este caso, el de revisión típico es hacer la última; crear registros SRV en el nuevo proveedor de DNS para asegurarse de Outlook se redirige a autodiscover.companyA.com, que (en cualquier otro lado) funcionará correctamente ya que aparece en el certificado como un SAN. Para que esto funcione, usted debe:

  • Configurar un _autodiscover._tcp.companyB.com registro SRV en conformidad con la documentación.
  • Borrar el autodiscover.companyB.com registro de host, si es que existe, para impedir que Outlook de la resolución de este y de intentar llegar a la detección automática de esa manera.
  • También a resolver cualquier problema con el acceso HTTPS a https://companyB.com como en el anterior, puesto que Outlook mostrará la Url derivados de la dirección de correo del usuario antes de caer sobre el registro SRV de enfoque.

*¿Cómo funciona la detección automática de trabajo (interno, del dominio de los clientes)?

Puedo añadir que esto sólo para su integridad, ya que es otra razón común para estos certificados le pide a ocurrir.

En un cliente del dominio, cuando es local en el entorno de Exchange (es decir, en el interior de la LAN), las técnicas anteriores no se utilizan. En su lugar, Outlook se comunica directamente con un Punto de Conexión de Servicio de Active Directory (enumerados en el Acceso de Cliente de Exchange configuración), que enumera las URL donde Outlook puede localizar el servicio de detección automática.

Es común que la advertencia de certificado que se producen en estas circunstancias, porque:

  • La dirección URL predeterminada configurada para este propósito se refiere a la interna de la dirección URL de Intercambio, lo cual es a menudo muy diferente de la dirección URL pública.
  • Los certificados SSL no puede mostrar la dirección URL interna en ellos. En la actualidad, el tuyo no, pero esto puede ser un problema en el futuro para los dominios de Active Directory que el uso de .local y similares no global de nombres de dominio de gTLD sufijos, ya que una decisión de ICANN prohíbe los certificados SSL para dichos dominios se emitió post-2016.
  • La dirección interna, podría no resolver al servidor adecuado.

En este caso, la cuestión se resuelve mediante la corrección de la grabación de la URL a la que se refieren a la adecuada, dirección externa (que aparece en el certificado), mediante la ejecución de la Set-ClientAccessServer cmdlet con el -AutodiscoverServiceInternalUri del interruptor. Partes hacerlo normalmente también configurar split-horizon DNS, ya sea porque esté obligado a hacerlo por su configuración de red y/o para la continuidad de la resolución en el caso de aguas arriba de resolución de/interrupción de conexión.

3voto

Russ Wheeler Puntos173

Usted necesita para crear un registro SRV en los dominios B y C que coincide con uno de los nombres en el cert (autodiscover.companyA.com). Esto le dice a Outlook que maneja la detección automática de los Dominios B y C.

Lee aquí de los registros SRV en DNS sección:

http://www.jaapwesselius.com/2011/08/28/autodiscover-redirect-and-srv-option/

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

;