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