Selección de certificados TLS anónimos salientes

  • Artículo

 

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2009-12-07

En este tema, se describe el proceso de selección de certificados de Seguridad de la capa de transporte (TLS) anónimos salientes en Microsoft Exchange Server 2010. La selección de un certificado TLS anónimo saliente ocurre en las siguientes situaciones:

  • Sesiones SMTP entre servidores de transporte perimetral y servidores de transporte de concentradores para autenticación

  • Sesiones SMTP entre servidores de transporte de concentradores para cifrado únicamente mediante claves públicas

En la comunicación entre servidores de transporte de concentradores se utilizan TLS anónimos y las claves públicas de los certificados para cifrar la sesión. Cuando se establece una sesión SMTP, el servidor receptor inicia un proceso de selección de certificado para determinar el certificado que se utilizará en la negociación TLS. El servidor de recepción realiza también un proceso de selección de certificado. Para obtener más información acerca del proceso, consulte Selección de certificados anónimos de entrada TLS.

Envío desde un servidor de transporte de concentradores o un servidor de transporte perimetral

Todos los pasos de selección de un certificado TLS saliente anónimo se realizan en el servidor de envío. La siguiente figura muestra los pasos de este proceso.

Selección de un certificado TLS anónimo saliente

Selección de un certificado TLS anónimo saliente

  1. Cuando se establece la sesión SMTP desde un servidor de transporte de concentradores o un servidor de transporte perimetral, Microsoft Exchange inicia un proceso para cargar los certificados.

    Nota

    Durante la carga inicial del certificado, el proceso de selección de certificado saliente es diferente para la función del servidor Transporte perimetral y la función del servidor Transporte de concentradores. La siguiente figura muestra el punto de inicio de cada rol del servidor.

  2. El proceso de carga de certificados depende de si la sesión SMTP se inicia en un servidor de transporte de concentradores o en un servidor de transporte perimetral.

    En un servidor de transporte de concentradores     Se realizan las siguientes comprobaciones:

    1. Se comprueba el conector de envío al que está conectada la sesión para ver si la propiedad SmartHostAuthMechanism está configurada para ExchangeServer. Puede establecer la propiedad SmartHostAuthMechanism del conector de envío utilizando el cmdlet Set-SendConnector. También puede establecer la propiedad SmartHostAuthMechanism para ExchangeServer seleccionando Autenticación de Exchange Server en la página Configurar los valores de autenticación de hosts inteligentes de un conector de envío específico. Para abrir la página Configuración de autenticación de host inteligente, haga clic en Cambiar en la ficha Red de la página de propiedades del conector de envío.

    2. Se comprueba la propiedad DeliveryType del mensaje para determinar si está establecida en un valor de SmtpRelayWithinAdSitetoEdge. Puede ver la propiedad DeliveryType ejecutando el cmdlet Get-Queue con el argumento de lista de formato ( | Format-List).

      Deben cumplirse las siguientes dos condiciones. Si no se ha habilitado ExchangeServer como mecanismo de autenticación o si la propiedad DeliveryType no se ha establecido en SmtpRelayWithinAdSitetoEdge, el servidor de transporte de concentradores de envío no utiliza el TLS anónimo y no se carga ningún certificado. Si se cumplen ambas condiciones, el proceso de selección de certificado continúa en el paso 3.

    En un servidor de transporte perimetral     Se realizan las siguientes comprobaciones:

    1. Se comprueba el conector de envío al que está conectada la sesión para ver si la propiedad SmartHostAuthMechanism está configurada para ExchangeServer. Como se indicó anteriormente en este tema, usted puede establecer la propiedad SmartHostAuthMechanism del conector de envío utilizando el cmdlet Set-SendConnector. También puede establecer la propiedad SmartHostAuthMechanism para ExchangeServer seleccionando Autenticación de Exchange Server en la página Configurar los valores de autenticación de hosts inteligentes de un conector de envío específico. Para abrir la página Configurar los valores de autenticación de hosts inteligentes, haga clic en Cambiar en la ficha Red de la página de propiedades del conector de envío.

    2. Se comprueba el conector de envío al que está conectada la sesión para determinar si la propiedad de espacio de direcciones SmartHost incluye "- -".

      Deben cumplirse las siguientes dos condiciones. Si no se ha habilitado ExchangeServer como mecanismo de autenticación o si el espacio de direcciones no incluye "- -", el servidor de transporte perimetral de envío no utiliza el TLS anónimo y no se carga ningún certificado. Si se cumplen ambas condiciones, el proceso de selección de certificado continúa en el paso 3.

  3. Microsoft Exchange consulta Active Directory para recuperar la huella digital del certificado en el servidor. El atributo msExchServerInternalTLSCert del objeto de servidor almacena la huella digital del certificado.

    Si no puede leerse el atributo msExchServerInternalTLSCerto si el valor es null, Microsoft Exchange no anuncia X-ANONYMOUSTLS en la sesión SMTP y no se carga ningún certificado.

    Nota

    Si el atributo msExchServerInternalTLSCert no puede leerse o si el valor es null durante el inicio del servicio de transporte de Microsoft Exchange y no durante la sesión SMTP, el evento ID 12012 se registra en el registro de aplicaciones.

  4. Si se encuentra una huella digital, el proceso de selección de certificado busca en el almacén de certificados del equipo local uno que coincida con la huella digital. Si no se encuentra el certificado, el servidor no anuncia X-ANONYMOUSTLS, no se carga ningún certificado y el evento ID 12013 se registra en el registro de aplicaciones.

  5. Después de cargar un certificado desde el almacén de certificados, se lo examina para ver si ha expirado. El campo Valid to del certificado se compara con la hora y la fecha actuales. Si el certificado ha expirado, se registra el Id. de evento 12015 en el registro de la aplicación. En este caso, el proceso de selección de certificados no causa error y continúa con las comprobaciones restantes.

  6. El certificado se comprueba para ver si es el más reciente en el almacén de certificados del equipo local. Como parte de esta comprobación, se crea una lista de dominios para posibles dominios de certificado. La lista de dominios se basa en la siguiente configuración de equipo:

    • Nombre de dominio completo (FQDN) como, por ejemplo, mail.contoso.com

    • Nombre de host como, por ejemplo, EdgeServer01

    • Nombre de dominio completo físico como, por ejemplo, EdgeServer01.contoso.com

    • Nombre de host físico como, por ejemplo, EdgeServer01

      Nota

      Si el servidor está ejecutando Microsoft Windows Load Balancing, se comprueba la siguiente clave de registro en lugar de la configuración DnsFullyQualifiedDomainName: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parameters\Interface{GUID}\ClusterName

  7. Una vez creada la lista de dominios, el proceso de selección de certificado realiza una búsqueda para localizar todos los certificados del almacén cuyo FQDN coincida. Desde esta lista, el proceso de selección de certificado identifica una lista de certificados elegibles. Los certificados elegibles deben cumplir con los siguientes criterios:

    • El certificado es un certificado X.509 versión 3 o de una versión posterior.

    • El certificado tiene una clave privada asociada.

    • Los campos Asunto o Nombre alternativo de asunto contienen el FQDN que se obtuvo en el paso 6.

    • El certificado está habilitado para el uso de Nivel de sockets seguros (SSL)/TLS. Concretamente, el servicio SMTP se ha habilitado para este certificado usando el cmdlet Enable-ExchangeCertificate.

  8. Entre los certificados elegibles, se selecciona el mejor en base a la siguiente secuencia:

    1. Ordenar los certificados elegibles por la fecha más reciente de Valid from. Valid from es un campo Versión 1 en el certificado.

    2. Se usa el primer certificado de infraestructura de clave pública (PKI) válido que se encuentra en esta lista.

    3. Si no se encuentra ningún certificado PKI válido, se utiliza el primer certificado autofirmado.

  9. Cuando se haya determinado el mejor certificado, se realiza otra comprobación para determinar si su huella digital coincide con el certificado que está almacenado en el atributo msExchServerInternalTLSCert. Si el certificado coincide, se usa para X-ANONYMOUSTLS. Si no coincide, el evento Id. 1037 se registra en el registro de aplicaciones. Sin embargo, esto no causa ningún error de X-ANONYMOUSTLS.

 © 2010 Microsoft Corporation. Reservados todos los derechos.