Имея в организации почтовый сервер MS Exchange 2013 который был установлен и настроен в далеком 2014 году, рано или поздно я должен был столкнуться с необходимостью установить сертификат заверенный подписью удостоверяющего центра (УЦ), так как мой самозаверенный сертификат перестал приниматься некоторыми почтовыми приложениями (например с версии iOS 10.3 — самозаверенные сертификаты нельзя признать надежными без специальных манипуляций). В большинстве случаев это не нужно, так как самозаверенные сертификаты легко распространить в рамках домена, и проблем с почтой не возникнет, но если хочется иметь доступ к почте из вне и пользоваться современными почтовыми приложениями (например стандартный почтовый клиент в iOS), то такой сертификат уже не подходит.
Тут я столкнулся со следующими проблемами:
- В доменной сети имя почтового сервера — локальное, и оно должно присутствовать в сертификате.
- С октября 2015 года локальные доменные имена и IP адреса больше не допустимы в ssl сертификатах подписанных удостоверяющим центром.
- Так как в домене имя сервера — локальное а снаружи — глобальное, установка сертификата заверенного УЦ создает проблемы в доменной сети. Для решения возникших проблем нужно провести большую работу по перенастройке сервера MS exchange и DNS сервера. А после заменить самозаверенные сертификаты на заверенные УЦ.
Задавшись целью «вкорячить» SSL любой ценой не меняя настройки локальных сервисов я начал перебирать варианты. В интернете много статей по установке SSL Exchange но, как это сделать если в домене все клиенты используют локальное имя, а в интернете глобальное — я не нашел. Имея на руках заказанный ранее Wildcard SSL-сертификат — (просто потому что мы его покупали для установки на сайт, вы можете воспользоваться выпуском сертификата на ваш почтовый поддомен, например у Let’s Encrypt ) я применил следующее решение:
Сразу предупреждаю данное решение можно назвать «костылем», поскольку оно предлагает именно обход переконфигурирования всей структуры. Но постоянно замечая, как во многих организациях сталкиваются с подобной проблемой, я считаю, что оно может быть полезным.
После выпуска сертификата у меня на руках имеется три файла:
- сам сертификат — файл с расширением .crt и выданный моему домену.
- закрытый ключ — файл с расширением .key — секретная информация и важная для шифрования, не передавайте и не публикуйте её!
- корневой сертификат — файл с расширением .crt — выдан удостоверяющему центру для подписания сертификатов.
Для импорта в MS Exchange нужно сконвертировать данные файлы в один с расширением .PFX в котором будет храниться как сам сертификат, закрытый ключ и цепочка доверия, в моем случае корневой сертификат.
Как выполнить данную конвертацию — есть куча статей в интернете. Я не рекомендую делать такие процедуры — Онлайн. Лично я предпочитаю установить Toollit — OpenSSL И с помощью него выполнить конвертацию. Для примера привожу команду:
openssl pkcs12 -export -out out.pfx -inkey key.key -in cert.crt -certfile rootca.crt
Где «out.pfx» — файл который получится в результате конвертации, key.key — закрытый ключ, cert.crt — файл сертификата выпущенный для вашего домена, rootca.crt — корневой сертификат.
Теперь когда файл out.fpx у нас на руках, можем сделать импорт данного сертификата на сервер MS Exchange. Сделать это можно разными способами, один из них — через Центр администрирования Exchange. Центр администрирования Exchange > Серверы > Сертификаты > … >Импорт сертификата. Стоит отметить, что предварительно стоит разместить этот файл в сетевом доступном серверу месте. Далее указываем сетевой путь до этого файла и вводим пароль который задавали при конвертации сертификата. После импорта, не назначаем сертификат ни каким службам.
Далее что бы разделить локальный трафик и трафик «снаружи», создадим дополнительный IP адрес на сетевом интерфейсе. И обязательно установим флаг: SkipAsSource — что бы данный IP не создавал исходящие соединения и не попадал в записи DNS. Как это сделать подробно расписано в данной статье.
Скорее всего Ваш сервер находится за NAT и так как мы создали дополнительный IP адрес для связи с «внешним миром», нужно поменять правила NAT что бы входящие «снаружи» запросы передавались именно на дополнительный IP адрес. Как это сделать — зависит от Вашей сетевой инфраструктуры и используемого оборудования\софта.
Теперь осталось дело за малым, на IIS создать новую привязку в которой будет наш дополнительный IP адрес, и с которым будет использоваться импортированный ранее сертификат. Для этого заходим в Диспетчер служб IIS на Вашем сервере с MS Exchange. В сайте почтового сервера (скорее всего он будет называться Default Web Site) — открываем «привязки»
Далее для создания новой привязки нажимаем «Добавить», выбираем Тип — «https», из выпадающего списка IP-адрес — выбираем дополнительный адрес. Можно указать имя узла как внешнее доменное имя Вашего почтового сервера «mx.yourdomain.com» и выбираем импортированный сертификат, заверенный УЦ.
После создания данной привязки, при https запросе на указанный IP адрес, для соединения будет использоваться сертификат подписанный УЦ. А при запросе на IP адрес который использовался ранее, будет использоваться самозаверенный сертификат. Таким образом трафик «снаружи» шифруется сертификатом подписанным УЦ и почтовые приложения уверены в его надежности. А трафик в локальной сети шифруется самозаверенным сертификатом выданным для локального имени.
На рисунке ниже я попытался отобразить суть данного решения. 