Ошибка Имя хоста НЕ ПРОВЕРЯЕТСЯ - Тестовые сертификаты TLS Exchange 2016 cu21

Ошибка Имя хоста НЕ ПРОВЕРЯЕТСЯ - Тестовые сертификаты TLS Exchange 2016 cu21

Практика с сертификатами в Let's Encryptwin-acmeсоздается нормальный, я отправляю и получаю обычную почту, https в owa и других сервисах

Тестирование счектлс, он выдает мне предупреждающее сообщение:

Имя хоста сертификата НЕ ПРОВЕРЯЕТ:

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

Я не понимаю ошибку DNS mail.lan.contoso.com. Я думал, что ошибка была в DNS SPLIT, но, прочитав вФорумони комментируют что-то об ошибке.

Я понимаю, что другие коннекторы не должны меняться на форумах, в книгах и учебниках, их никто не меняет. Вот почему создается новый коннектор для получения из интернета, на который можно изменить FQDN.

Рекомендации этогоФорум, мои настройки DNS:

Частный AD DNS (lan.contoso.com)

Тип записи DNS-имя Внутренний IP-адрес
А mail.lan.contoso.com 192.168.1.4
А DC01.lan.contoso.com 192.168.1.3

Частный DNS (contoso.com) РАЗДЕЛЕНИЕ

Тип записи DNS-имя Внутренний IP-адрес
А mail.contoso.com 192.168.1.4
А autodiscover.contoso.com 192.168.1.4

Публичный DNS (contoso.com)

Тип записи DNS-имя Ценить
А mail.contoso.com xxx.xxx.xxx.xxx
А autodiscover.contoso.com xxx.xxx.xxx.xxx
МХ @ mail.contoso.com

решение1

После долгих испытаний я понял некоторые сообщения об ошибках вCheckTls. Это сертификат, используемый коннектором приема Exchange. Я повторно тестирую вCheckTlsи прошел весь тест без ошибок.

Спасибо за совет @Lutz Willek, буду продолжать практиковать.


Я делюсь с вами своим решением, надеюсь, оно поможет другим решить эту проблему.

Я не знаю, хорошая ли это процедура, раствор, который я использую, используйте следующееДокументация Майкрософтдля справки.

  1. Убедитесь, что сертификат Let's Encrypt создан и службы включены.
    Get-ExchangeCertificate | Format-List FriendlyName,Thumbprint,Issuer,Subject,CertificateDomains,Services
  1. Определите, какой соединитель приема назначить, я был больше сосредоточен на анонимных пользователях.
    Get-ReceiveConnector | where {$_.Bindings -like '*25' -AND $_.PermissionGroups -like '*AnonymousUsers*'} | Format-List Identity,Bindings,RemoteIPRanges,PermissionGroups
  1. Определив соединитель, я приступаю к назначению сертификата.
    $cert = Get-ExchangeCertificate -Thumbprint xxxxxxxx
    $tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"
    Set-ReceiveConnector "Server_Name\Default Frontend Server_Name" -TlsCertificateName $tlscertificatename
  1. Проверьте, был ли сертификат назначен коннектору приема.
    Get-ReceiveConnector -Identity "Server_Name\Default Frontend Server_Name" | Format-List Name,Fqdn,TlsCertificateName

решение2

Другойотвечатьна 100% верно.

Произошло то, что (внутренний) сервер был создан с использованием имени хоста mail.lan.contoso.com. Ошибка заключается в том, что сертификат, созданный для этого хоста, по-прежнему представлен в случае, если mail.contoso.comдля подключения к серверу используется имя DNS.


Так что вынуждатьсядля создания функционального сервиса необходимо сделать следующее:

  • Удалите конфигурацию разделенного DNS для autodiscover.contoso.com, так как специальное разрешение имен 192.168.1.4не требуется в вашей внутренней сети. (Поскольку всегда можно использовать публичное разрешение имен)
  • Настройте своих клиентов для подключения к mail.contoso.com. (проверьте настройки автообнаружения)
  • Настройте сервер обмена на использование сертификата, созданного для — в настоящее время представлен mail.contoso.comсертификат для .mail.lan.contoso.com

Что тымогсделать, чтобы повысить надежность и сократить усилия по обслуживанию: (Это позволяет отделить обслуживание от сервера)

  • На стороне сервера настройте второй внутренний IP-адрес192.168.1.5 и укажите внутреннее разрешение имен для mail.contoso.comэтого IP-адреса. (Не изменяйте mail.lan.contoso.comего, он по-прежнему указывает на сам сервер)
  • На стороне сервера (обмена) настройте почтовые службы на прослушивание этого конкретного IP-адреса 192.168.1.5.192.168.1.4 .

Что вы могли бы по крайней мереучитывать, не используетразделение DNSсовсем:

  • Мой опыт показывает, что если раздельная DNS не реализована должным образом, это может привести к существенным недостаткам, а также что опыта работы с сетями среднего администратора, к сожалению, недостаточно для контроля и решения всех связанных с этим проблем.
  • Еще одной важной причиной является упрощенная структура сети, которая помогает (помимо прочих преимуществ) быстрее изолировать первопричину в случае возникновения инцидента.
  • У раздельной настройки DNS не так много реальных преимуществ, которые нельзя было бы достичь более эффективно с помощью других методов.

Связанный контент