Modifique el nombre de host interno /externo de Exchange para que sea un nombre de dominio unificado (error de certificado de esquema)

Con la popularidad del sistema de correo de Exchange en más y más empresas, los empleados también están dispuestos a usar Office Outlook para enviar y recibir correo, lo que facilita enormemente la entrega en tiempo real de correos electrónicos de trabajo. Sin embargo, cuando los usuarios usan Outlook, se encontrarán con más y más problemas, como el informe de errores de certificados de Outlook, lo que provocará que no se use el cliente. Hoy vamos a hablar sobre el tema del certificado de perspectivas.

Como todos sabemos, la red pública del sistema de correo de la empresa Exchange debe combinarse con el certificado de la red pública. De lo contrario, muchas instituciones de certificación en el país y en el extranjero no pueden juzgar si el correo electrónico de su empresa es una fuente legítima de transmisión, lo que puede resultar en la falla del correo. Normalmente enviar y recibir. La siguiente figura es el valor predeterminado de algunos de nuestros administradores de certificados, la autoridad de certificados raíz de la tarjeta de crédito, y solo el certificado de red pública o el certificado privado emitido por estas organizaciones puede hacer que la aplicación tenga derechos reales de ejecución y derechos de acceso.

En la actualidad, cuando una empresa está configurando un servidor de correo de Exchange, si desea publicar la red pública, generalmente se aplica a dos tipos de certificados. Uno de ellos es "varios nombres de dominio". Certificado ", el otro es el certificado "comodín" y ". El certificado de comodín se presenta en forma de * .contoso.com, lo que significa que se permiten todos los accesos de dominio público del nombre de dominio de segundo nivel. También es un certificado que recomendamos ahora. Debido a que este certificado se usa ampliamente y la superficie de autenticación es muy amplia, básicamente no lo es. El certificado de Outlook mencionado en este artículo informará un error, por lo que no está dentro del alcance de esta discusión.

Este artículo se centra en el alcance del "certificado de varios dominios". En la actualidad, el certificado de múltiples dominios adquirido de diferentes autoridades de certificación en China es un certificado que puede contener cinco nombres de dominio de segundo nivel, por lo que se denomina "certificado de múltiples dominios". En otras palabras, solo cuando se utiliza el servicio de publicación de nombres de dominio de segundo nivel incluido en este certificado, se puede acceder a él de manera efectiva y legal.

En la implementación actual de Exchange Server, generalmente usamos dos CAS front-end recomendados por Microsoft y dos MBX back-end para la implementación de DAG de alta disponibilidad.

En este caso, el "certificado de varios dominios" que solicitamos generalmente contiene los siguientes nombres de dominio de dos niveles:

Podemos ver que los cinco anteriores El nombre de dominio de segundo nivel contiene los FQDN de los dos servidores de aplicaciones para el usuario. El propósito de esto es permitir a los usuarios acceder al servidor de Exchange a través de las redes internas y externas, y luego acceder al servidor desde el cliente para la autenticación. Servicio Pero los dos servidores de CAS front-end también deben tener un efecto legítimo. En otras palabras, deben tener sus propias entradas de certificado de red pública. Debido a esto, también agregaremos el FQDN de los dos servidores CAS en la parte frontal a la entrada de certificado de múltiples dominios.
(Si se trata de un solo servidor de correo con TODO en una implementación, puede solicitar el FQDN de este servidor)

Si solicitamos el certificado de red pública, olvidamos agregar el FQDN del servidor de aplicaciones para múltiples nombres. En la entrada del certificado, o el certificado del servidor de correo antiguo (el nombre CAS no existe o ha cambiado), nuestro Outlook del cliente encontrará el siguiente error al acceder al servidor de correo de Exchange, lo que hace que el usuario no pueda utilizar el cliente de Outlook normalmente. Fin

Entonces, ¿cómo resuelves este problema? Vamos a verlo.

En primer lugar, podemos pensar en ello: cuando el usuario utiliza Outlook para acceder al servidor de correo de Exchange, solicita al certificado que informe un error. Este básico puede determinarse que cuando el cliente accede, no puede ser verificado, entonces nosotros seremos los administradores. Abra EMS y use el comando get-outlookanywhere para ver la configuración actual de outlookwhere.

Efectivamente, encontramos que cuando el servidor accede a Outlook, el nombre del host interno y el nombre del host externo son diferentes, ya que los nombres de acceso al sistema de correo que publicamos generalmente son Es mail.contoso.com u otro, pero el nombre de host de acceso interno se escribe con nuestro FQDN del servidor de aplicaciones para el usuario, por lo que en el caso de que falte el certificado del servidor CAS de aplicaciones para el usuario, no podemos pasar la verificación del servidor. Entonces solo podemos evitar este problema modificando este valor.

Primero activamos la función SSLOffloading con el siguiente comando

Get-OutlookAnywhere