“Сертификация” Exchange 2010
Доступ к сервисам почтового сервера в локальной сети – это одно, а вот доступ из сети Интернет должен быть хорошо защищен, так что без HTTPS тут никуда! Если речь заходит о безопасном подключении через HTTPS, то на ум сразу приходит вопрос обеспечения этого соединения сертификатом безопасности, а соответственно и задача этот сертификат где-то получить. У Exchange 2010 уже есть свой собственный (самоподписанный) сертификат, который по умолчанию используется для предоставления локального доступа к Outlook 2010, OWA и т.п... В нашем случае такой сертификат не подойдет и мы озадачимся выдачей сертификата безопасности серверу Exchange 2010 из локального центра сертификации (вопросы приобретения и установки коммерческих сертификатов рассматривать не будем). Для того чтобы выдать сертификат, нам необходимо в локальной сети иметь как минимум одни Центр сертификации (ЦС). Для этого на любом сервере под управлением Windows Server 2008 R2 нужно установить роль Службы сертификации Active Directory и добавить компоненты Центр сертификации и Служба регистрации в центре сертификации через Интернет (для получения сертификатов через веб-браузер).
Рис.1: Установка служб сертификации Active Directory.
В данном сценарии, доступ к сервисам Exchange будет происходить как из локальной сети предприятия, так и из сети Интернет, соответственно клиенты будут использовать как минимум 2 FQDN имени для подключения. Дело в том, что сертификаты по умолчанию могут быть привязаны только к одному FQDN-имени. Для включения в сертификат нескольких имен узлов необходимо в центре сертификации активировать функцию SAN. Subject Alternative Name – это специальное поле в сертификате, которое содержит набор имен узлов. Exchange 2010, при генерации запроса на сертификат, сам добавляет в него несколько имен узлов, но без включенной функции SAN, центр сертификации попросту проигнорирует все лишние имена и оставит только одно.
Для включения функции SAN, на сервере с корневым центром сертификации необходимо выполнить команду:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
и перезапустить сам ЦС:
net stop certsvc
net start certsvc
В результате в сертификатах этого ЦС появится ещё одно поле (см.рис.):
Рис.2: Поле SAN в сертификате.
Закончив настройки ЦС можно перемещаться на сервер Exchange, здесь в разделе Конфигурация серверов давайте выберем наш сервер клиентского доступа (CAS), и создадим запрос на получения нового сертификата при помощи действия New Exchange Certificate… (это можно сделать и через EMS при помощи командлета New-ExchangeCertifate). Введем понятное имя сертификата и на странице Exchange Configuration внимательно заполним FQDN имена узлов для необходимых нам сервисов.
Рис.3: Конфигурирование доменных имен сервисов Exchange.
В результате мастер предложит вам список доменных имен, которые будут включены в сертификат. Если бы мы не включили функцию SAN в нашем центре сертификации, то в этом случае сертификат был бы привязан только к доменному имени указанному как Set as common name.
Рис.4: Конфигурирование списка доменных имен.
На следующем шаге мастера необходимо заполнить информацию о вашей организации и сохранить запрос в файл с расширением *.req.
После формирования запроса его нужно будет подтвердить в ЦС. Для этого откроем веб-страничку нашего ЦС по адресу http://YourCA/certsrv и нажмем кнопку Запрос сертификата – Расширенный запрос – Выдать запрос используя Base-64 шифрованный файл….
Рис.5: Расширенный запрос сертификата.
Затем нужно открыть фал с сохраненным запросом (*.req) например Блокнотом, скопировать его содержание в поле Сохраненный запрос, выбрать шаблон сертификата – Веб-сервер и нажать кнопку Выдать.
Рис.6: Генерация сертификата для Exchange.
Теперь возвращаемся в консоль управления Exchange, выбираем новый сертификат и подтверждаем его действием Complete Pending Request…
Рис.7: Подтверждение сертификата.
Если все сделано правильно, то в значок сертификата будет помечен белой галочкой на голубом фоне, и мы сможем приступить к следующему шагу.
Примечание: Если сертификат принят не был, то стоит проверить есть ли у сервера доверие к выдавшему его центру сертификации, для этого нужно открыть MMC, добавить оснастку Сертификаты – Локальный компьютер и посмотреть в раздел Trusted Root Certification Authorities, там должен быть сертификат корневого ЦС, если его там нет, то его нужно запросить со странички http://YourCA/certsrv — запрос сертификата ЦС и импортировать.
После успешного подтверждения сертификата, необходимо ему назначить нужные сервисы, для этого нажмем на нем правой кнопкой мыши – Assign Services to Certificate… и выберем необходимые сервисы, включая IIS.
Рис.8: Присвоение сертификату необходимых служб.
В результате в службе IIS у сайта по умолчанию (Default Web Site) должен измениться SLL сертификат для https, проверить это можно зайдя в мастер редактирования Привязок (Bindings).
Рис.9: SSL сертификат для https.
Импорт/экспорт сертификатов
Для того, чтобы клиенты и серверы (например, ISA/TMG) могли принимать сертификат Exchange`a и пользоваться им, нужно выполнить 2 условия:
1. Обеспечить клиентов доверием к этому сертификату;
2. Обеспечить серверы самим сертификатом.
Что касается клиентов, то в случае рабочих станций, находящихся в домене, сервер ЦС сам позаботится о том, чтобы доменные пользователи ему доверяли, и установит свой сертификат к ним в Trusted Root Certification Authorities. Если же у вас есть не доменные пользователи, то вам нужно запросить сертификат ЦС и импортировать его вручную. Проще всего запросить сертификат ЦС через веб-браузер по адресу http://YourCA/certsrv — Загрузка сертификатов ЦС, цепочки сертификатов или CRL.
Рис.10: Запрос сертификата ЦС.
Скачав сертификат на локальный компьютер его можно импортировать на клиентов при помощи групповой политики (для доменных пользователей) — Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certificate Authorities
Рис.11: Назначение корневых сертификатов при помощи GPO.
Или вручную при помощи оснастки MMC – Certificates. Запускаем MMC от имени администратора – File – Add/Remove Snap-is – Certificates – Computer Account – Local Computer – выбираем нужный раздел и нажимаем Импорт.
Рис.12: Импорт сертификата через MMC.
Также сертификат можно установить нажав на файле правой кнопкой мыши – Установить сертификат (Install Certificate) и поместить его в необходимый контейнер:
Рис.13: Установка сертификата в выбранный контейнер.
Но в этом случае сертификат будет установлен не для компьютера, а для пользователя.
Что касается экспорта, то Личные (Personal) сертификаты выгружаются с приватным ключом
Рис.14: Выгрузка сертификата с приватным ключом.
И при выгрузке надо указать, что экспорт необходимо осуществить со всеми дополнительными параметрами:
Рис.15: Выгрузка с дополнительными параметрами.
Далее необходимо указать пароль на файл и сохранить файл с расширением *.pfx на локальный компьютер.
Корневые сертификаты выгружаются проще, здесь нужно указать формат DER encoded binary X.509 (.CER) и сохранить сертификат в файл с расширением *.cer.
Рис.16: Выгрузка корневых сертификатов в файл *.cer
Сертификат самого сервера Exchange 2010 можно выгрузить просто нажав на нем правой кнопкой мыши в консоли управления Exchange – Export.
Затем необходимо скопировать полученные файлы на нужный сервер/компьютер и импортировать их. Что касается клиентских ПК, то им необходим только сертификат корневого ЦС, для того, чтобы доверять всем другим сертификатам, выданным этим ЦС. Для серверов (TMG/ISA) плюсом к корневому сертификату нужно импортировать сертификат Exchange`a, для того, чтобы он мог использоваться на прослушивателе (Listener`e).
Заключение
На этом тему выдачи сертификата мы закончим. В следующей статье поговорим про публикацию самих сервисов Exchange 2010 в сеть Интернет.
Данная статья является частью цикла “Публикация сервисов Exchange 2010 через TMG”, скачать все целиком вы можете в виде PDF файла – здесь, или посмотреть веб-каст на эту тему на портале TechDays по адресу — http://www.techdays.ru/videos/2814.html
Алексей Богомолов (Alexx)
http://alexxhost.ru
Popularity: 1% [?]
у меня пока 3 вопроса:
1) зачем нужно экспортировать сертификат Exchange с закрытым ключом? Для какой цели?
2) если CA установлен в текущем лесу и работает под управлением Windows Server, ничего публиковать не надо, т.к. он сам публикует свой сертификат в нужное хранилище. Причём, не только в домене, но и во всём лесу. Следовательно, если корневой CA находится вне текущего леса или работает не под управлением Windows Server, его сертификат целесообразно публиковать не через групповые политики, а напрямую в Active Directory.
3) на рисунке 14 вы показываете экспорт сертификата самого CA с закрытым ключом. Для чего это требуется?
спасибо.
Exchange 2010 прекрасно создает SAN сертификаты из мастера и EMS
Для включения функции SAN, на сервере с корневым центром сертификации необходимо выполнить команду:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Вот это нужно делать только для того, чтобы запрашивать сертификат из MMC, а не EMS или EMC от Exchange 2010.
To Vadims Podāns:
— Сертификаты выгружаются с закрытым ключом потому, что потом их планируется импортировать на TMG, который не входит в домен.
— «если CA установлен в текущем лесу и работает под управлением Windows Server, ничего публиковать не надо» — совершенно верно,об этом сказано в самом начале абзаца «Что касается клиентов, то в случае рабочих станций, находящихся в домене,...», о публикации через GPO рассказано просто «для справки».
— «сертификат целесообразно публиковать не через групповые политики, а напрямую в Active Directory.» — спасибо, учту.
— Сертификаты выгружаются с закрытым ключом потому, что потом их планируется импортировать на TMG, который не входит в домен.
это плохо, потому что TMG/ISA должна иметь свою ключевую пару и свой сертификат (с такими же именами в поле Subject и расширении SAN). Экспортируемость ключа повышает вероятность, что его сопрут у вас из под носа.
Вот вам на заметку про экспортируемые ключи: en-us.sysadmins.lv/Lists/.../Post.aspx?ID=21
в достаточно доступной форме рассказано, почему так делать нельзя (и когда это можно и нужно).
Vadims Podāns, почитал вашу заметку о вреде экспортируемых сертификатов. Многие сценарии надуманы и основаны на недоверии к администраторам или пользователям, оставляющим свои компы незалоченными. Это безусловно опасно, но решается никак не на уровне неэкспортируемых сертификатов, а смарткартами и прочими средствами повышения безопасности.
Что до не экспортируемости... Имея админские права, неэкспортируемый сертификат замечательно достается из любого хранидища компьютера, нужна лишь специальная программа.
> Многие сценарии надуманы
с таким подходом можно сказать, что перехват трафика тоже надуман и сертификатами SSL можно смело пренебречь. Да и производители HSM тоже продают свою продукцию для исключения лишь каких-то надуманных сценариев.
> Это безусловно опасно, но решается никак не на уровне неэкспортируемых сертификатов, а смарткартами и прочими средствами повышения безопасности.
я хотел бы посмотреть, как вы на смарт-карте будете хранить сертификаты Exchange.
> решается никак не на уровне неэкспортируемых сертификатов
но это одна из мер, которая снижает риск компрометации ключей.
> Имея админские права, неэкспортируемый сертификат замечательно достается из любого хранидища компьютера, нужна лишь специальная программа
а как вам вариант, что если ключ экспортируемый, тогда даже админских прав и специальной программы не надо для выноса ключей? Простого пользователя и немного соображалки хватит вполне.
> перехват трафика тоже надуман и сертификатами SSL можно смело пренебречь
Зачем же переходить в другую крайность...
> Да и производители HSM тоже продают свою продукцию для исключения лишь каких-то надуманных сценариев.
Специальные средства, HSM, смарт карты с доступом к закрытому ключу с вводом пин-а — они действительно решают свою задачу — безопасное хранение закрытых ключей, в отличае от пометки ключа неэкспортируемым.
> тогда даже админских прав и специальной программы не надо для выноса ключей
Не знаком с таким способом... Можете поделиться?
> Зачем же переходить в другую крайность...
это не крайность, просто вариант сценария. Вы ведь отрицаете возможность хищения ключа? А я отрицаю возможность перехвата трафика.
> Специальные средства, HSM, смарт карты с доступом к закрытому ключу с вводом пин-а — они действительно решают свою задачу — безопасное хранение закрытых ключей, в отличае от пометки ключа неэкспортируемым.
Безусловно это так. Но эти средства стоят относительно больших денег (скажем, те же HSM по несколько килобаксов) и обеспечивают высокий уровень защиты. Компании неориентированные в этом направлении либо неспособны купить такое решение или не осознаёт/считает нецелесообразным его необходимость. Поэтому для бюджетных решений целесообразно применять хотя бы такие простые меры для снижения вероятности выноса ключей.
> Не знаком с таким способом...
вот поэтому вы так немного легкомысленно относитесь к такой простой, но вполне достаточной мере защиты ключей от выноса.