- Что такое публичный центр сертификации?
- Выпуск ssl сертификатов для exchange сервера
- Добавление обслуживаемого домена (accepted domains)
- Запрос сертификата
- Как это бывает
- Настройка внешних url адресов exchange сервера
- Настройка политики адресов электронной почты
- Получение сертификата из публичного центра сертификации (public certification authority)
- Проверка конфигурации
- Установка сертификата
- Настройка соединителя отправки (send connector)
Что такое публичный центр сертификации?
Публичные центры сертификации, также известные как корневые центры сертификации (root certification authorities), являются издателями сертификатов, которым доверяют практически все основные обозреватели и приложения, тем самым избавляя от необходимости делать центр сертификации доверенным.
Когда вы принимаете решение о получении сертификата с публичного центра сертификации, вам нужно знать, будет ли этот публичный центр сертификации доверенным для всех приложений, которые вы будете использовать, и может ли он предоставить необходимые вам сертификаты (речь идет об именах, сроке действия и т.д.).
Выпуск ssl сертификатов для exchange сервера
Цифровые сертификаты очень важны в любой Exchange организации. Именно с их помощью обеспечивается защищенный обмен между клиентами и компонентами почтовой инфраструктуры. По умолчанию, Exchange Server настроен на использование протокола TLS с помощью самоподписанных сертификатов.
Однако, для подключения Outlook клиентов такая конфигурация не совсем корректна. В качестве решения, рекомендуется использовать корпоративную PKI инфраструктуру, на базе ADCS. Службы сертификатов будут работать внутри корпоративного периметра обеспечивая поддержку не только Exchange, но и других криптографических задач предприятия.
Для выпуска сертификата, переходим во вкладку (servers) и открываем раздел (certificates). Заказываем выпуск нового сертификата:

Выбираем первый пункт (Create a request for a certificate from a certification authority) так как использование самоподписанных сертификатов не предполагается:

Указываем отображаемое имя будущего сертификата:

Далее, возможно настроить получение сертификата типа wildcard. Хоть и последние версии Exchange корректно работают с данным типом, я предпочитаю его не использовать. Оставляем без изменений и переходим на следующую страницу.

Указываем сервер на котором будет создан сертификат, т. к. закрытый ключ ключевой пары не покидает Exchange сервер:

Следующий шаг пропускаем не меняя настройки. Далее, подправляем домены на следующие:
- mail.corp.ait.in.ua
- mail.ait.in.ua
- autodiscover.ait.in.ua
- autodiscover.corp.ait.in.ua
- kv-ex01
- kv-ex01.corp.ait.in.ua

где, my-sertif.ru почтовый домен и corp.my-sertif.ru — домен Active Directory. kv-ex01 и kv-ex01.corp.my-sertif.ru — имена сервера. Запись autodiscover необходима для функционирования сервиса автоматического обнаружения почтовой конфигурации клиентами Outlook и ActiveSync. Она должна обязательно присутствовать в теле сертификата.

На следующем шаге необходимо определить расположение для сохранения CSR запроса. В последствии, он будет передан во внешним ЦС. Так как учетная запись Exchange сервера является членом группы Trasted Sybsystems, возможно использовать общими административными каталогами.
Для этого указываем следующий UNC путь — \kv—ex01.corp.my-sertif.ruC$req.req Файл req.req содержащий CSR запрос будет создан в корне системного диска.

Для задачи подписания, можно воспользоваться CertificateEnrollmentWebService. Этот компонент упрощает процесс предоставляя веб приложения для этих целей. По умолчанию, CEWS доступен в каталоге /certsrv сервера.
Перейдя на него, необходимо заказать запрос сертификата (Requestacertificate).

Выбираем расширенный тип запроса (advanced certificate request):

Вставляем содержимое CSR запроса. Из списка доступных шаблонов сертификатов выбираем Web Server:

Скачиваем файл цифрового сертификата:

Загружаем сертификат в корень системного диска Exchange сервера:

В той же вкладке certificates необходимо завершить процедуру выпуска «подложив» подписанный сертификат. Для этого выбираем действие Complete:

В открывшейся окне указываем UNC путь к файлу, который ранее был загружен в корень системного диска.

После завершения операции, сертификат готов к использованию в компонентах сервера. Для его назначения сервисам нажимаем на иконку «карандаш»:

и выбираем сервисы IIS, SMTP:

После применения, необходимо перезапустить браузер. При условии корректно настроенных служб сертификатов Active directory предупреждение о недоверенном сертификате в строке браузера должно исчезнуть. Клиенты Outlook также не выдадут предупреждение при попытке подключения к серверу.
Добавление обслуживаемого домена (accepted domains)
Обслуживаемый домен (accepted domains) — это домен, который используется Exchange организацией для получения и отправки почтового трафика. В рамках него (типы Authoritative и Internal Relay) могут формироваться почтовые адреса пользователей, общих почтовых ящиков, групп распространения и других объектов Exchange которым возможно назначить почтовый адрес.По умолчанию, сразу же после развертывания, доступен лишь один обслуживаемый домен:

Имя его соответствует домену Active Directory. Всего существует три типа обслуживаемых доменов:
- Уполномоченный домен (Authoritative)
- Домен внутренней ретрансляции (InternalRelay)
- Внешний домен ретрансляции (ExternalRelay)
Домены первого типа полностью обслуживаются Exchange организацией. При поступлении на него входящего письма происходит поиск почтового адреса в глобальном каталоге Active Directory. В случае его отсутствия будет возвращен NDR (Not Delivery Report).
Домен внутренней ретрансляции применяется тогда, когда адресное пространство используется совместно с другой почтовой инфраструктурой. Логика работы такая же, как и в первом типе, но при отсутствии почтового адреса в глобальном каталоге возможно перенаправление письма на другой SMTP шлюз.
Последний тип используется в задачах перенаправления входящих писем на внешний SMTP шлюз тогда, когда нет надобности в использовании одного адресного пространства с другой почтовой системой. Так же, его невозможно использовать при формировании почтовых адресов в Exchange организации.
Если письмо будет доставляться в Exchange организацию, а домен получателя отсутствует в обслуживаемых доменах, оно автоматически будет отклонено с ошибкой 550 5.7.54 SMTP; Unabletorelayrecipientinnon—accepteddomain.
Сам процесс добавления домена необходимого типа выглядит следующим образом:

Запрос сертификата
Есть несколько путей, чтобы выполнить процедуру генерации CSR-запроса. Самый простой из них — через оснастку Диспетчер служб IIS, который я рассматривал в статье Exchange Hybrid — Подготовка серверов федерации. В этой же статья я рассмотрю более «хардкорный» вариант, когда запрос надо сгенерировать из консоли EMS1. Итак, сделать это можно командой как в примере ниже:
Примечание: если вдруг надо указать данные об организации, вы можете это сделать внутри параметра -SubjectName, например -SubjectName [C=<CountryOrRegion>, S=<StateOrProvince>, L=<LocalityOrCity>, O=<Organization>, OU=<Department>], CN=<HostNameOrFQDN>.
Папка \exch01c$tmpcert_01 должна существовать. После выполнения команды там будет лежать CSR-запрос cert_01.req. С его помощью вы сможете получить сертификат в локальном доменном ЦС, либо отправить его публичному ЦС.
Как это бывает
Помимо проблем с несвоевременным продлением, вам может также встретиться ситуация с отзывом сертификата со стороны выпускающего центра. Это может случиться в том случае, если вы установили свеженький сертификат, а счет, который центр сертификации присылает позже, оплатить забыли.
Примечание: обычно срок оплаты выпущенного сертификата составляет две недели, но все зависит от отношений вашей организации и центром сертификации. По личным договоренностям вы можете продлить срок оплаты. Также перед отзывом сертификата вас обязательно предупредят менеджеры ЦС, при том сделают это несколько раз.
Если вдруг вы нарвались на отзыв сертификата, то попасть даже в ECP у вас не получится. Вот что покажет браузер:
Как видите, кнопочки Продолжить открытие этого веб-сайта (не рекомендуется) тут нет, а следовательно придется поработать ручками в консоли.
Настройка внешних url адресов exchange сервера
Базовая настройка Exchange Server не заканчивается добавлением обслуживаемого домена и настройкой соединителей. Необходимо задать корректные URL адреса для подключения клиентов. Для этого перейдем в настройки конфигурации:

Выберем сервер и нажмем на «карандаш» открыв страницу настроек. Далее, необходимо перейти в настройки OutlookAnywhere и задаем внешний домен для подключения клиентов:

Данный домен, в последствии, будет использоваться для публикации Exchange сервера. Этот процесс будет описан в будущей статье.
Задание внешнего домена требуется и для веб каталогов Exchange сервера. Для этого необходимо перейти в конфигурацию virtual directories и найти «гаечный ключ»:

На открывшейся странице задаем необходимую конфигурацию:

Задание внешнего домена по которому будет доступна Exchange инфраструктура необходимо для дальнейшего выпуска SSL сертификатов.
Настройка политики адресов электронной почты
Политики адресов электронной почты определяют правила создания электронных адресов для получателей в организации Exchange. Функционал крайне полезен, так как с его помощью транслируется единый формат почтовых алиасов как для существующих, так и для новых пользователей организации.
Чтобы приступить к созданию первой политики, необходимо перейти в раздел (mail flow), далее во вкладку (mail address policies):

Создаем новую политики нажав “Add” ( ). Откроется окно, где необходимо задать название политики и формат адресов электронной почты:

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

Самостоятельно подготовить шаблон можно используя переменные. Ниже таблица с их возможными значениями:
| Переменная | Значение |
| %d | Краткое имя |
| %g | Имя |
| %i | Буква отчества |
| %m | Псевдоним Exchange |
| % rXY | Заменить все вхождения x на y |
| % rXX | Удалить все вхождения x |
| %s | Фамилия |
| %ng | Первые n букв имени. Например, %2g первые две буквы с именем не используются. |
| %ns | Первые n букв фамилии. Например, %2s использует первые две буквы фамилии. |
Следующий шаг будет в определении области применения политики. Она состоит из типов объектов Exchange и их расположения.

После создания, необходимо применение политики:

Получение сертификата из публичного центра сертификации (public certification authority)
Несмотря на то, что Exchange 2007 может генерировать самоподписные сертификаты во время установки, и вы можете заставить клиентов доверять им, следует помнить то, о чем я писал в первой части:
Самоподписные сертификаты действительны только в течение одного года
Самоподписным сертификатам могут доверять только их издатели
Самоподписные сертификаты не поддерживаются ни в Outlook Anywhere, ни в Exchange ActiveSync
Поэтому рекомендуется получить сертификат из центра сертификации. Можно установить собственный центр сертификации или получить сертификат из публичного центра сертификации. Компания Microsoft рекомендует получать сертификаты из публичного центра сертификации в следующих ситуациях:
Если вы получаете сертификат из публичного центра сертификации, вам не придется тратить массу усилий на то, чтобы ваш центр сертификации воспринимался как доверенный клиентами, не входящими в домен, и/или партнерскими организациями, которые хотят настроить безопасность домена с вашей средой Exchange.
Компания Microsoft опубликовала статью в базе знаний (Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007) со списком центров сертификации, издающих унифицированные сертификаты коммуникации для Microsoft Exchange и для Communications Server 2007 (Unified Communications Certificates for Microsoft Exchange and for Communications Server 2007), которые можно использовать для установки функции Безопасности домена.
Проверка конфигурации
Доступ к Outlook Web Access:

Почтовый обмен с внешней почтовой системой:

Установка сертификата
Результатом отправки CSR-запроса в ЦС должно быть получение файла с расширением .crt (.cer) и возможно других (сертификаты промежуточных центров). Поместим этот файл (в моем случае он имеет имя certnew.cer) в папку \exch01c$tmpcert_01. Далее необходимо завершить запрос на получение командой:
Примечание: логично, что завершать запрос на получение сертификата нужно на том же сервере, на котором этот запрос когда-то был сгенерирован.
Посмотреть существующие сертификаты, доступные для использования сервером Exchange, можно командой:
Запомните значение Thumbprint сертификата, для которого вы только что завершили запрос. Это нужно, чтобы назначить этот сертификат необходимым службам Exchange. Делается это командой:
Осталось только перезапустить IIS (можно это сделать через оснастку Службы, полное название IIS — Служба веб-публикаций (W3SVC)):
Теперь снова можете пользоваться ECP. Если сертификат был получен у локального ЦС, то возможно придется раскидать его по каким-то клиентам вручную, либо через GPO (как это сделать, читайте в статье Сертификат Exchange 2021).
Настройка соединителя отправки (send connector)
В Exchange инфраструктуре коннекторы или соединители выполняют задачи обработки входящего и исходящего почтового потока, также участвуют внутри транспортного потока Exchange. Чтобы почтовая инфраструктура могла взаимодействовать с внешними системами по протоколу SMTP, необходимо создать новый соединитель отправки.

Как и в случае с обслуживаемыми доменами, существует несколько типов исходящих почтовых соединителей:
- Внутренний (Internal)
- Внешний (Internet)
- Партнерский (Partner)

Внутренний соединитель отправки используется для ретрансляции почтового потока внутри почтовой организации. Например, в сочетании с доменом внутренней ретрансляции.
Внешний тип предполагает отправку почты во вне организации, например удаленному почтовому серверу через Интернет.
Партнерский тип используется для настройки почтового взаимодействия между двумя внешними партнерскими организациями. Примером может служить холдинг. В холдинге множество отдельно стоящих почтовых систем, взаимодействие между которыми регулироваться политиками безопасности. Одна из политик требует, чтобы во время почтового обмена использовалось шифрование. Партнерский тип решает эту задачу.
Возвращаясь к задаче, для отправки внешним почтовым системам необходим внешний (Internet) тип соединителя.
На следующей странице необходимо указать каким образом будет осуществляться отправка почты. Либо используя MX записи, либо выделенный смарт-хост в виде внешнего почтового релея.

Внизу страницы присутствует чек-бокс с включением конфигурации Use the external DNS lookup settings on servers with transport roles. Задействование данной опции позволит не использовать конфигурацию DNS серверов сетевого интерфейса Exchange сервера, а применить настройки из конфигурации самого сервера. Они задаются на странице Servers, в первом же разделе Servers:

Необходимая вкладка называется DNS lookups:

