Варианты решения проблемы запрета на использование внутренних локальных имен в SSL-сертификатах

Как известно, согласно последним требованиям CA/B форума все сертификаты, содержащие внутренние локальные имена в полях CN или SAN dns names, будут аннулированы 1-го октября 2016 года. И уже сейчас многие удостоверяющие центры не выпускают сертификаты с локальными именами, дата истечения которых - 31 октября 2015г. и позднее.

Для тех, кто создает архитектуру Exchange и Active Directoryс нуля, верным решением является заранее предусмотреть использование внешних имен и позаботиться об их регистрации.
Но что делать тем, чья инфраструктура уже давно функционирует и успешно налажена?

Давайте рассмотрим некоторые выходы из данной ситуации:

1. Первое решение – это использование сертификатов, выпущенных собственным внутренним центром сертификации.
Т.е. для тех локальных имен, которые попали под запрет – Вы просто выпускаете сертификаты от собственного центра сертификации. Для остальных имен продолжаете использование публичных сертификатов от официальных удостоверяющих центров.
Публичный сертификат, в этом случае, привязывается к ISA / TMG для осуществления внешнего доступа в то время, как внутренний сертификат привязывается к самому серверу Exchange.

2. Второе решение также предполагает использование собственного внутреннего центра сертификации.
Вам необходимо создать второй веб-сайт IIS на Exchange сервере с ролью сервера клиентского доступа и сформировать дополнительные виртуальные директории для внешних служб (например, таких, как OWA).
В этом случае публичные сертификаты Вы привязываете к этому веб-сайту IIS, а к веб-сайту, идущему по умолчанию, Вы привязываете свои внутренние сертификаты.
Если в схеме участвует сервер ISA/TMG, то к нему привязывают публичный сертификат.

3. Третье решение – это перенос или переименование доменов Active Directory.
Если выбирать между способами переноса или переименования доменов, вероятно, первый из них будет наименее безболезненным для всей структуры в целом. Однако рекомендуется производить эти изменения в рамках запланированного обновления сервера и учитывать конкретные особенности Вашей среды.

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