Error Nombre de host NO VERIFICA - Certificados de prueba TLS Exchange 2016 cu21

Error Nombre de host NO VERIFICA - Certificados de prueba TLS Exchange 2016 cu21

Practicando con los certificados, en vamos a cifrarganar-acmeSe crea normal, envío y recibo correo normal, https en owa y los demás servicios

Prueba concheques, me da un mensaje de alerta:

El nombre de host del certificado NO VERIFICA:

(mail.contoso.com != mail | DNS:mail | DNS:mail.lan.contoso.com)

No entiendo el error de DNS de mail.lan.contoso.com. Pensé que el error era DNS SPLIT, pero al leer en elforocomentan algo sobre el error.

Entiendo que los demás conectores no se deben cambiar en foros, libros y tutoriales, nadie los cambia. Es por eso que se crea un nuevo conector para recibir desde internet, al cual se le puede cambiar el FQDN.

Recomendaciones de esteforo, mi configuración de DNS:

DNS de AD privado (lan.contoso.com)

Tipo de registro Nombre DNS IP interna
A correo.lan.contoso.com 192.168.1.4
A DC01.lan.contoso.com 192.168.1.3

DNS privado (contoso.com) DIVIDIDO

Tipo de registro Nombre DNS IP interna
A correo.contoso.com 192.168.1.4
A detección automática.contoso.com 192.168.1.4

DNS público (contoso.com)

Tipo de registro Nombre DNS Valor
A correo.contoso.com xxx.xxx.xxx.xxx
A detección automática.contoso.com xxx.xxx.xxx.xxx
MX @ correo.contoso.com

Respuesta1

Después de muchas pruebas, entiendo algunos de los mensajes de error enChequeTls. Es el certificado que utiliza el conector de recepción de Exchange. vuelvo a probar enChequeTlsy pasó toda la prueba sin errores.

Gracias por el consejo @Lutz Willek, seguiré practicando.


Comparto mi solución contigo, espero que ayude a otros con este problema.

No sé si es un buen procedimiento, la solución que estoy usando usa la siguientedocumentación de microsoftpara referencia.

  1. Verifique que se haya creado el certificado Let's Encrypt y que los servicios estén habilitados
    Get-ExchangeCertificate | Format-List FriendlyName,Thumbprint,Issuer,Subject,CertificateDomains,Services
  1. Identificar el conector de recepción a asignar, estaba más enfocado a usuarios anónimos
    Get-ReceiveConnector | where {$_.Bindings -like '*25' -AND $_.PermissionGroups -like '*AnonymousUsers*'} | Format-List Identity,Bindings,RemoteIPRanges,PermissionGroups
  1. Habiendo identificado el conector procedo a asignar el certificado
    $cert = Get-ExchangeCertificate -Thumbprint xxxxxxxx
    $tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"
    Set-ReceiveConnector "Server_Name\Default Frontend Server_Name" -TlsCertificateName $tlscertificatename
  1. Verificar si el certificado fue asignado al conector de recepción
    Get-ReceiveConnector -Identity "Server_Name\Default Frontend Server_Name" | Format-List Name,Fqdn,TlsCertificateName

Respuesta2

El otrorespuestaes 100% correcto.

Lo que sucedió es que se creó un servidor (interno) usando el nombre de host mail.lan.contoso.com. El error es que el certificado que se creó para este host todavía se presenta en caso de que mail.contoso.comse use el nombre dns para conectarse al servidor.


Vos tambiennecesidadhacer lo siguiente para crear un servicio funcional:

  • Elimine la configuración de DNS dividida para autodiscover.contoso.com, ya que 192.168.1.4no se necesita una resolución de nombre específica dentro de su red interna. (Como siempre se puede utilizar la resolución de nombre público)
  • Configure sus clientes para conectarse a mail.contoso.com. (verifique la configuración de detección automática)
  • Configure su servidor Exchange para usar el certificado para el cual se creó ; actualmente, se presenta mail.contoso.comel certificado para .mail.lan.contoso.com

Lo que tupodríahacer, para aumentar la confiabilidad y disminuir el esfuerzo de mantenimiento: (Esto permite dividir el servicio del servidor)

  • En el lado del servidor, configure una segunda dirección IP interna 192.168.1.5y apunte la resolución de nombre interno a mail.contoso.comesta dirección IP. (No cambies mail.lan.contoso.comcuál todavía apunta al servidor mismo)
  • En el lado del servidor (exchange), configure los servicios de correo para escuchar en esta IP 192.168.1.5específica 192.168.1.4.

¿Qué podrías al menosconsiderar, no está usandodividir DNSen absoluto:

  • Mi experiencia indica que existen considerables desventajas si el DNS dividido no se implementa completamente, y también que la experiencia de red del administrador promedio desafortunadamente no es suficiente para supervisar y abordar todos los desafíos asociados.
  • Otra razón importante es un diseño de red simplificado, que ayuda (entre otras ventajas) a aislar la causa raíz más rápidamente en caso de un incidente.
  • No hay muchas ventajas reales de una configuración de DNS dividida que no se puedan lograr de manera más eficiente utilizando otros métodos.

información relacionada