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.
- 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
- 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
- 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
- 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.com
se 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 que192.168.1.4
no 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.com
el 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.5
y apunte la resolución de nombre interno amail.contoso.com
esta dirección IP. (No cambiesmail.lan.contoso.com
cuá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.5
específica192.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.