У нас есть сервер Exchange 2010, работающий в нашем домене Active Directory, с внутренним именем хоста server.example.local.
Сервер настроен для работы с Exchange где угодно, но в настоящее время имеет самоподписанный сертификат с именем server.example.local установлены.
Внутренне клиенты подключаются и работают нормально, но внешне у нас возникают ошибки сертификата, как и следовало ожидать.
Я собираюсь приобрести сертификат UCC SSL для установки на сервере со всеми соответствующими SAN в сертификате, чтобы исправить это, но из-за очевидной проблемы с получением доверенного сертификата с .local в качестве альтернативного имени субъекта я хочу настроить клиентов во внутренней сети, чтобы они не использовали ссылку на .local имя хоста.
Я настроил наше внешнее DNS-имя для сервера как exchange.example.comи создали CNAME для autodiscover.example.com что также (правильно) указывает на exchange.example.com. Я также настроил внутренние записи DNS для этих двух имен хостов, которые указывают на внутренний интерфейс того же сервера. Не предвижу здесь никаких проблем.
Теперь я пытаюсь внутренне перенастроить автоматическое обнаружение, чтобы Outlook пытался подключиться к exchange.example.com. Я выполнил шаги в KB940726 чтобы подготовиться к этому, и это работало нормально. Ошибок не возникло, и я смог проверить имя CAS в AD с помощью редактирования ADSI.
Я только что попытался протестировать это с помощью недавно созданной тестовой учетной записи пользователя с новым почтовым ящиком Exchange, и Outlook 2007 нормально подключается к внутренней сети, но, глядя глубже в профиль Exchange, Outlook все еще разрешает имя сервера как server.example.local.
Может быть, это самозаверяющий сертификат, из-за которого Outlook отображает имя сервера как server.example.localИли все еще что-то не так с моей внутренней конфигурацией автообнаружения?
Я доказал, что не сертификат отвечает за возврат Outlook server.example.local, установив еще один самосертификат с именем test.example.com. При создании нового профиля Outlook я получаю сообщение об ошибке несоответствия, которое я выражаю, но после принятия сертификата и завершения настройки профиля Outlook снова отображается server.example.local как имя сервера. Это означает, что если бы я приобрел сертификат UCC сейчас, этот внешний клиент работал бы нормально, но внутренние клиенты показали бы несоответствие имени сертификата.
Есть идеи, с чего начать диагностику?
Я считаю, что мне удалось исправить это с помощью редактирования ADSI.
Несмотря на то, что я выполнял команды из статьи базы знаний, на которую ссылался в своем вопросе, я нашел две записи автообнаружения с помощью редактирования ADSI.
Я удалил CN=server запись, и пришлось изменить serviceBindingInformation property объекта CN=exchange.example.com чтобы отразить правильный внешний URL.
Теперь, когда я настраиваю новый профиль обмена или открываю Outlook для существующего пользователя, я получаю ошибку несоответствия имени сертификата. Однако это ожидается, поскольку мой сертификат по-прежнему является самоподписанным сертификатом, который имеет только имя server.example.local. Теперь я ясно вижу, что внутренние клиенты ищут имя exchange.example.com на свидетельство.
Я собираюсь сейчас заказать сертификат UCC с правильными именами SAN exchange.example.com и autodiscover.example.com, который, как я полагаю, теперь оставит у меня работающую систему.
Я заказал и установил доверенный сертификат с именем exchange.example.com, плюс SAN autodiscover.example.com, и я могу сообщить, что Outlook в любом месте отлично работает в следующих сценариях
example.local корпоративная сеть с подключенными к домену компьютерами.