У меня есть Exchange 2010 и Outlook 2003. На сервере обмена установлен SSL-сертификат с подстановочными знаками * .domain.com (для использования с autodiscover.domain.com и mail.domain.com). Локальный fqdn сервера Exchange - exch.domain.local. С такой конфигурацией проблем нет.
Теперь я начал обновлять весь Outlook 2003 до Outlook 2013, и у меня постоянно появляется ошибка сертификата в Outlook:
Имя в сертификате безопасности недействительно или не соответствует имени сайта.
Я понимаю, почему я получаю эту ошибку: Outlook 2013 подключается к exch.domain.local, а сертификат предназначен для * .domain.com.
Я был готов купить сертификат SAN (Subject Alternate Names), содержащий три домена exch.domain.local, mail.domain.com, autodiscover.domain.com. Но есть препятствие: провайдер сертификата (в моем случае Godaddy) требует, чтобы домен был подтвержден как наша собственность. Теперь это невозможно для внутреннего домена, недоступного из Интернета. Так что это не вариант.
Создание самозаверяющего сертификата SAN с помощью Enterprise CA - другой вариант, который едва ли жизнеспособен: при каждом доступе к веб-почте возникала ошибка сертификата, и мне пришлось установить сертификат на всех клиентах Outlook.
Какое рекомендуемое жизнеспособное решение?
Можно ли отключить проверку сертификатов в Outlook?
Или как я могу изменить конфигурацию сервера Exchange, чтобы имя общедоступного домена использовалось для всех подключений?
Как изменить основное доменное имя сервера Exchange, как предлагается в ответе, без необходимости переустановки сервера? Или есть другое решение, о котором я не думаю?
Любые советы приветствуются.
Вот шаги, чтобы изменить полное доменное имя, используемое Outlook для подключения к серверу (источники: Godaddy, Puryear)
С помощью консоли управления Exchange измените внутренний URL-адрес различных веб-служб:
Set-ClientAccessServer -Identity имя_вашего_сервера -AutodiscoverServiceInternalUri https://mail.domain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "Имя_вашего_сервера \ EWS (веб-сайт по умолчанию)" -Set-OABVirtualDirectory -Identity "Имя_вашего_сервера \ oab (веб-сайт по умолчанию)" -InternalUrl https://mail.domain.com/oab
Set-UMVirtualDirectory -Identity «Имя_вашего_сервера \ unifiedmessaging (веб-сайт по умолчанию)» -InternalUrl https://mail.domain.com/unifiedmessaging/service.asmx
Set-ActiveSyncVirtualDirectory -Identity "Имя_вашего_сервера \ Microsoft-Server-ActiveSync (веб-сайт по умолчанию)" -InternalUrl "https://mail.domain.com/Microsoft-Server-ActiveSync"
Главное, на что следует обратить внимание, это то, что вы устанавливаете внутренние URL-адреса такими же, как и внешние URL-адреса.
Я работаю над тем же процессом, Exchange 2010 с клиентами Outlook 2013 и только что зарегистрировал сертификат mail.domain.com. Однако наш сервер не server.local, это server.domain.com, но я не хочу добавлять это имя сервера к перечисленным именам хостов в сертификате, а также хочу сделать это правильно.
https://www.digicert.com/internal-domain-name-tool.htm
Вы можете использовать этот инструмент для создания скриптов Powershell, которые исправят URL-адреса Exchange, чтобы они соответствовали вашему внешнему имени хоста вместо вашего внутреннего имени хоста, а также скрипт отката для отмены изменений.
Вам нужно будет установить сертификаты в Exchange, и вам также потребуется создать внутреннюю запись DNS для преобразования mail.domain.com в servername.local.
Скорее всего, вы увидите, что при доступе к mail.domain.com/OWA (из внутреннего или внешнего) вы не получите ошибку сертификата, но если вы получите доступ к server.local / OWA, вы получите. Тогда это исправление определенно для вас!
Примечание. В статье Microsoft KB940726 показано, что URL-адрес OABVirtualDirectory должен быть HTTPS, однако, если вы настроили HTTP, инструмент DigiCert сохранит его, а не изменит на HTTPS.
Вы можете начать решать вашу ситуацию, не используя ".local" в своем полном доменном имени. Начиная с 2015 года, локально назначенные адреса больше не будут приниматься центрами сертификации. Так что лучше решите эту проблему сейчас, чем через год.
GoDaddy поступает правильно. Вы в основном застряли между камнем и наковальней. Большинство поставщиков сертификатов применяют новое правило сейчас, поэтому вы можете также купить новый сертификат с вашим фактическим глобальным адресом домена (надеюсь, у вас есть настроенный домен) с соответствующими SANS.