У нас есть windows 2012R2 с Exchange 2013, у нас был публичный ssl-сертификат, который использовался как для внешних, так и для внутренних пользователей. Мы решили не продлевать сертификат и подписать новый с помощью нашего контроллера домена CA. Я выполнил эту статью, чтобы настроить split-dns (https://practical365.com/exchange-server/avoiding-exchange-2013-server-names-ssl-certificates/) Итак, я настроил все так же, как в статье, запросил и подписал новый сертификат для веб-сервера из нашего центра сертификации контроллера домена, применил новый сертификат в IIS к «веб-странице по умолчанию», все работало нормально, но на следующем день появлялись разные ошибки: от ошибки 500 при попытке подключения owa до невозможности войти в ecp с учетной записью администратора (она просто перенаправила вас на сломанный owa), и теперь некоторые пользователи не могут отправлять письма через owa или получать их через Outlook. Я просто не знаю, где искать. Чтобы быть ясным, у нас есть люди, которые имеют доступ к серверам обмена, но их компьютеры не в домене, поэтому они не доверяют нашему новому сертификату.
Единственная причина, по которой это не работает, заключается в том, что у пользователей, не являющихся пользователями домена, нет сертификата CA, и поэтому они не могут запустить сеанс TLS.
Вы запускали iisreset от имени администратора в командной строке на серверах Exchange, чтобы он вступил в силу после привязки нового сертификата в IIS?
Если проблема не исчезнет, откройте IIS и проверьте пулы приложений, чтобы узнать, работают ли MSExchangeOWAAppPool и MSExchangeECPAppPool в .NET Framework v2.0, и перезапустите виртуальный каталог для проверки. Вот похожая тема об ошибке 500, см. Невозможно получить доступ к OWA или ECP. - «Что-то пошло не так» или «500 непредвиденных ошибок»
Кроме того, выполните команду ниже, чтобы удалить и воссоздать виртуальный каталог owa / ecp.
Чтобы удалить: Remove-OwaVirtualDirectory -Identity "имя сервера обмена \ owa (веб-сайт по умолчанию)"
Для воссоздания: New-OwaVirtualDirectory –WebSiteName
Кроме того, проверьте файл журнала IIS, чтобы найти любую ошибку, связанную с MSExchange на сервере клиентского доступа Exchange 2013, найдите папку «c: \ inetpub \ logs \ logfiles \ W3SVC1».