Запускаются сотни новых доменов верхнего уровня, которые переопределяют то, что составляет внутреннее имя
Внутреннее имя - это домен или IP-адрес, который является частью частной сети. Обычными примерами внутренних имен являются:
Любое имя сервера с суффиксом непубличного доменного имени. Например, www.contoso.local или server1.contoso.internal.
Имена NetBIOS или короткие имена хостов, что угодно, без публичного доступа. Например, Web1, ExchCAS1 или Frodo.
Любой IPv4-адрес в диапазоне RFC 1918.
Любой IPv6-адрес в диапазоне RFC 4193.
Причина, по которой дается изменение, заключается в том, что имена внутренних серверов не уникальны и поэтому легко фальсифицируются.
С общими именами, такими как server01 или webmail, конечный пользователь никогда не уверен, действительно ли он имеет дело
с правой стороной или с вредоносным.
Внутреннее имя определяется как «Строка символов (а не IP-адрес) в поле «Общее имя или имя альтернативного имени»
сертификата, который не может быть проверен как глобально уникальный в общедоступном DNS на момент выдачи сертификата,
поскольку он не заканчивается доменом верхнего уровня, зарегистрированным в базе данных корневой зоны IANA» .
Например, «mail» и «exchange.local» - это внутренние имена; «Casecurity.org» и «paypal.com» являются публично
зарегистрированными именами. В соответствии с правилами, принятыми на форуме CA / Browser еще в 2011 году,
центры сертификации (CA) не могут выпускать сертификаты, содержащие внутренние имена
Причина всех этих правил довольно проста и более подробно объясняется в этом документе CA / Browser Forum.
Внутренние имена по своей сути не уникальны, потому что они не зарегистрированы в центральном органе.
Любой пользователь может запустить сервер по адресу https: // mail /, например, и до этих правил любой может получить
сертификат для «почты». Это позволяет злоумышленнику легко получить сертификат и запустить атаку «человек-в-середине» (MITM).
Корпоративные гостевые сети Wi-Fi являются особенно привлекательной мишенью для такого типа атаки, поскольку сеть, вероятно,
будет настроена для распознавания любых внутренних имен, используемых организацией.
В случае новых доменов верхнего уровня аналогичный риск присутствует, поскольку ранее сертификат выдавался для имени,
которое теперь зарегистрировано другим объектом.
Решение проблемы внутренних имен
В некоторых случаях нет простых решений проблем, созданных благодаря использованию внутренних имен,
но есть несколько вариантов, которые вы можете выбрать:
Переконфигурируйте систему для использования общедоступного доменного имени
Зарегистрировать имя
Настройка корпоративного центра сертификации
Использовать самозаверяющие сертификаты
1. Первый вариант переноса сервисов на зарегистрированное доменное имя, как правило, является лучшим и самым чистым
решением для конечной зависимости от внутренних имен в сертификатах TLS / SSL. Как это часто бывает, для этого варианта
может потребоваться значительное количество первоначальных усилий, но это почти всегда возможно. Вопреки тому, что некоторые
считают, сервер Microsoft Exchange может быть перенастроен для использования имен общедоступных доменов, а также сетей Active
Directory (дополнительную информацию см. В этом официальном документе CA / Browser Forum). Преимущество такого подхода
заключается в том, что после завершения изменения он не добавляет никакого постоянного административного бремени -
вы сможете продолжать использовать общедоступные сертификаты, как и раньше. Одна из проблем, возникающих при таком подходе,
- это возможность публично раскрывать информацию о внутренней инфраструктуре компании через DNS. Этот риск можно смягчить,
используя субдомен типа «внутренний» или отдельное доменное имя и настроив DNS, чтобы эти зоны не могли быть разрешены за пределами сетей компании.
2. Второй вариант - преобразовать внутренние имена, на которые вы в настоящее время полагаетесь, на публично зарегистрированные имена.
Теоретически имена, такие как «ford.exchange», могут быть зарегистрированы, как только новый домен верхнего уровня доступен для общей регистрации.
На практике это занимает больше времени, чем 120-дневный льготный период, разрешенный текущими правилами, поэтому вам нужно будет
реализовать другое решение, пока вы не сможете успешно зарегистрировать доменное имя. И некоторые новые рДВУ не будут открыты для
регистрации широкой публикой.
3. Переходя к третьему варианту, «корпоративный центр сертификации» - это программное обеспечение, которое действует как публично
доверенный ЦС, но работает или для организации. Эти системы могут выдавать сертификаты, содержащие внутренние имена, при условии,
что сертификаты нельзя доверять публично. Это означает, что Enterprise CA не может быть настроен для подписывания сертификатов,
привязанных к доверенным корням открытого центра сертификации, а сертификаты, выпущенные корпоративным ЦС, заставят браузеры
отображать противные предупреждения пользователям. Обходным путем для этих сообщений об ошибках является установка частного
корневого сертификата CA на клиенте. К сожалению, это сложный процесс в любой гетерогенной среде, где используются несколько браузеров
(Firefox, Chrome, Internet Explorer), настольные операционные системы (Windows, OS X, Linux) и устройства (iOS, Android). Еще один риск с
корпоративным ЦС заключается в том, что компромисс системы оставляет предприятие уязвимым для атаки MITM, поэтому должны быть
приняты сильные меры безопасности для защиты закрытых ключей и приложений, которые могут использоваться для выдачи сертификатов.
4. Конечным вариантом является использование «самозаверяющих» сертификатов. Этот параметр имеет аналогичные недостатки,
чем у Enterprise CA, но не очень хорошо масштабируется, потому что каждый отдельный сертификат должен быть установлен на
всех клиентских устройствах, чтобы избежать сообщений об ошибках в браузере. Помимо обеспечения безопасности на основе
браузера, ваша организация может также использовать сертификаты TLS / SSL для защиты связи между серверами. Не забудьте проверить,
используют ли эти серверы в настоящее время сертификаты с внутренними именами. Если это так, вам нужно выбрать одно из вышеуказанных
решений, хотя это не должно быть тем же решением, которое вы выбираете для трафика между браузерами.
Глобальные изменения в законодательстве в отношении сертификатов SAN SSL
Если вы являетесь администратором сервера, используя внутренние имена, вам необходимо либо перенастроить эти серверы на использование
общедоступного имени, либо переключиться на сертификат, выданный внутренним ЦС до даты отсечения 2015 года. Все внутренние подключения,
требующие публично-доверенного сертификата, должны выполняться с помощью общедоступных имен и проверяемых имен (неважно,
являются ли эти службы общедоступными).
Обратите внимание, что в июне 2011 года ICANN одобрила новую общедоступную доменную программу (gTLD), которая позволяет организациям,
отдельным лицам и правительствам применять заявки на высшие уровни. Это повлияет на многие SSL-сертификаты для внутренних имен
до даты закрытия внутреннего имени.
Microsoft Exchange Internal Names
Руководство по работе с внутренними именами в Exchange 2007
Запустите оболочку управления Exchange.
Измените URL-адрес автообнаружения в точке подключения к службе. Точка подключения к службе хранится в службе каталогов Active Directory.
Чтобы изменить этот URL-адрес, введите следующую команду и нажмите клавишу ВВОД:
Измените атрибут InternalUrl EWS. Для этого введите следующую команду и нажмите клавишу ВВОД:
Set-WebServicesVirtualDirectory -Identity "CAS_Server_Name\EWS (Default Web Site)"
-InternalUrl https://mail.contoso.com/ews/exchange.asmx
Измените атрибут InternalUrl для распределения автономной адресной книги через Интернет. Для этого введите следующую команду и нажмите клавишу ВВОД:
Set-OABVirtualDirectory -Identity "CAS_Server_name\oab (Default Web Site)"
-InternalUrl https://mail.contoso.com/oab
Измените атрибут InternalUrl веб-службы единой системы обмена сообщениями. Для этого введите следующую команду и нажмите клавишу ВВОД:
Set-UMVirtualDirectory -Identity "CAS_Server_Nameunifiedmessaging (Default Web Site)"
-InternalUrl https://mail.contoso.com/unifiedmessaging/service.asmx<
Примечание. Эта команда требуется только в среде Exchange 2007. Эта команда больше не существует в среде Exchange 2010.
Вместо этого для этой цели используется URL-адрес WebServices.
Откройте диспетчер IIS.
Разверните локальный компьютер, а затем разверните пулы приложений .
Щелкните правой кнопкой мыши MSExchangeAutodiscoverAppPool и выберите «Переработать» .
Руководство по работе с внутренними именами в Exchange 2010
Запустите оболочку управления Exchange.
Измените URL-адрес автообнаружения в точке подключения к службе. Точка подключения к службе хранится в службе каталогов Active Directory.
Чтобы изменить этот URL-адрес, введите следующую команду и нажмите клавишу ВВОД:
Измените атрибут InternalUrl EWS. Для этого введите следующую команду и нажмите клавишу ВВОД:
Set-WebServicesVirtualDirectory -Identity "CAS_Server_Name\EWS (Default Web Site)"
-InternalUrl https://mail.contoso.com/ews/exchange.asmx
Измените атрибут InternalUrl для распределения автономной адресной книги через Интернет.
Для этого введите следующую команду и нажмите клавишу ВВОД:
Set-OABVirtualDirectory -Identity "CAS_Server_name\oab (Default Web Site)"
-InternalUrl https://mail.contoso.com/oab
Откройте диспетчер IIS.
Разверните локальный компьютер, а затем разверните пулы приложений .
Щелкните правой кнопкой мыши MSExchangeAutodiscoverAppPool и выберите « Переработать»
В зависимости от вашей конфигурации вам может потребоваться внести некоторые изменения в инфраструктуру для поддержки
этого изменения, разделим конфигурацию следующим образом:
1- Имя домена Active Directory - domain.com или другие допустимые имена доменов:
если в домене Active Directory указано имя домена domain.com или другие допустимые имена доменов, то, скорее всего, ваши изменения минимальны,
единственное уловение здесь, если ваши пользователи обращаются к OWA, используя https: // mail или https: // Exchange внутри
для завершения пользователи простоты, это больше не будет поддерживаться или работать, и вам нужно будет работать с конечными пользователями, чтобы это исправить.
2 - домен Active Directory - domain.local (или другое недопустимое имя):
ха-ха-ха, вам будет весело, из-за того, что внутренние и внешние URL-адреса в Exchange работают, вам нужно будет сделать больше,
чем просто новый запрос сертификата для ваших серверов, но опять же это зависит от того, как вы настроили серверы Exchange:
Для одного развертывания сайта Active Directory:
Если внутренние URL-адреса для веб-служб Exchange используют внешние имена, то вы в порядке, но если вы
используете единый веб-сайт для OWA, OAB и других функций веб-сервисов, вам необходимо будет рассмотреть два решения:
Измените внутренние имена vDirectories для включения имен общедоступных доменов (например, .com или .net), для этого
потребуется создать правильные DNS-зоны в Active Directory (домен. <Допустимый домен>) и настроить записи в этой зоне DNS
для сопоставления к правильным внутренним и внешним IP-адресам (некоторые службы будут указывать на внутренние IP-адреса,
такие как веб-службы Exchange, а некоторые указывают на внешние IP-адреса, такие как ваш веб-сайт, например), вам также могут
потребоваться некоторые изменения в сертификате для включения новых имен или приобретения нового сертификат для размещения новых имен.
Создайте новый веб-сайт на Exchange и разделите трафик между внешним веб-сайтом и внутренним веб-сайтом, для нового
веб-сайта вам нужно будет указать правильные имена (внутренние и внешние) и настроить новый IP-адрес для серверов CAS,
используя хост заголовки с OWA и ECP в настоящее время разрывают OWA / ECP, поэтому вам необходимо назначить новые
серверы CAS для нового IP-адреса и настроить веб-сайты для прослушивания на соответствующих IP-адресах и настроить правила
публикации для публикации новой конфигурации (это также зависит от вашей сетевой инфраструктуры и конфигурация брандмауэра).
Внешние имена и его сертификат нужно будет пересмотреть для выдачи правильных имен в сертификате, я не уверен, будет ли
старый сертификат отменен или сохранен как есть, но если они будут сохранены до тех пор, пока они не будут отменены и не будут
повторно выпущены то вы можете пропустить этот шаг.
Возможно потребуется проверить конфигурацию NLB, если там будет включен новый NLB-IP для внутренних имен.
Для развертывания сайта Multi Active Directory:
опять же, это зависит от вашей конфигурации, и это может быть немного сложно, потому что перенаправление и проксирование и
поскольку существуют различные факторы и конфигурации, но здесь приведены некоторые рекомендации:
Документируйте, как вы делаете OWA и веб-сервисы прямо сейчас, а также то, как вы выполняете настройку прокси или перенаправления.
Внешние имена и его сертификат нужно будет пересмотреть для выдачи правильных имен в сертификате, я не уверен, будет
ли старый сертификат отменен или сохранен как есть, но если они будут сохранены до тех пор, пока они не будут отменены и не будут
повторно выпущены то вы можете пропустить этот шаг.
Внутренние имена должны быть проверены и переназначены именами, которые включают действительные внешние домены, и это
потребует изменений DNS и сертификатов, как я сказал выше.
Внутренние имена, которые будут храниться внутри, должны будут использовать свой собственный веб-сайт, новые IP-адреса и
сертификат, которые могут быть переизданы, также вы можете повторно посетить свою конфигурацию NLB, также вам нужно будет
проверить конфигурацию NLB.
вам нужно будет пересмотреть свой InternalNLBBypassUrl , рекомендуется не изменять его из имени внутреннего сервера, и пока
нет других рекомендаций, и до тех пор, и если вы сделаете прокси-сервер через сайты, которые вы могли бы застрять с новым вариант веб-сайта
OV 
Купить сертификат
