Главная Exchange/UC, Security, Без рубрики, Новое “Сертификация” Exchange 2010
  • “Сертификация” Exchange 2010

    image Доступ к сервисам почтового сервера в локальной сети – это одно, а вот доступ из сети Интернет должен быть хорошо защищен, так что без HTTPS тут никуда! Если речь заходит о безопасном подключении через HTTPS, то на ум сразу приходит вопрос обеспечения этого соединения сертификатом безопасности, а соответственно и задача этот сертификат где-то получить. У Exchange 2010 уже есть свой собственный (самоподписанный) сертификат, который по умолчанию используется для предоставления локального доступа к Outlook 2010, OWA и т.п.. В нашем случае такой сертификат не подойдет и мы озадачимся выдачей сертификата безопасности серверу Exchange 2010 из локального центра сертификации (вопросы приобретения и установки коммерческих сертификатов рассматривать не будем). Для того чтобы выдать сертификат, нам необходимо в локальной сети иметь как минимум одни Центр сертификации (ЦС). Для этого на любом сервере под управлением Windows Server 2008 R2 нужно установить роль Службы сертификации Active Directory и добавить компоненты Центр сертификации и Служба регистрации в центре сертификации через Интернет (для получения сертификатов через веб-браузер).

    image

    Рис.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

    В результате в сертификатах этого ЦС появится ещё одно поле (см.рис.):

    image

    Рис.2: Поле SAN в сертификате.

    Закончив настройки ЦС можно перемещаться на сервер Exchange, здесь в разделе Конфигурация серверов давайте выберем наш сервер клиентского доступа (CAS), и создадим запрос на получения нового сертификата при помощи действия New Exchange Certificate… (это можно сделать и через EMS при помощи командлета New-ExchangeCertifate). Введем понятное имя сертификата и на странице Exchange Configuration внимательно заполним FQDN имена узлов для необходимых нам сервисов.

    image

    Рис.3: Конфигурирование доменных имен сервисов Exchange.

    В результате мастер предложит вам список доменных имен, которые будут включены в сертификат. Если бы мы не включили функцию SAN в нашем центре сертификации, то в этом случае сертификат был бы привязан только к доменному имени указанному как Set as common name.

    image

    Рис.4: Конфигурирование списка доменных имен.

    На следующем шаге мастера необходимо заполнить информацию о вашей организации и сохранить запрос в файл с расширением *.req.

    После формирования запроса его нужно будет подтвердить в ЦС. Для этого откроем веб-страничку нашего ЦС по адресу http://YourCA/certsrv и нажмем кнопку Запрос сертификатаРасширенный запросВыдать запрос используя Base-64 шифрованный файл….

    image

    Рис.5: Расширенный запрос сертификата.

    Затем нужно открыть фал с сохраненным запросом (*.req) например Блокнотом, скопировать его содержание в поле Сохраненный запрос, выбрать шаблон сертификата – Веб-сервер и нажать кнопку Выдать.

    image

    Рис.6: Генерация сертификата для Exchange.

    Теперь возвращаемся в консоль управления Exchange, выбираем новый сертификат и подтверждаем его действием Complete Pending Request

    image

    Рис.7: Подтверждение сертификата.

    Если все сделано правильно, то в значок сертификата будет помечен белой галочкой на голубом фоне, и мы сможем приступить к следующему шагу.

    Примечание: Если сертификат принят не был, то стоит проверить есть ли у сервера доверие к выдавшему его центру сертификации, для этого нужно открыть MMC, добавить оснастку Сертификаты – Локальный компьютер и посмотреть в раздел Trusted Root Certification Authorities, там должен быть сертификат корневого ЦС, если его там нет, то его нужно запросить со странички http://YourCA/certsrv – запрос сертификата ЦС и импортировать.

    После успешного подтверждения сертификата, необходимо ему назначить нужные сервисы, для этого нажмем на нем правой кнопкой мыши – Assign Services to Certificate… и выберем необходимые сервисы, включая IIS.

    image

    Рис.8: Присвоение сертификату необходимых служб.

    В результате в службе IIS у сайта по умолчанию (Default Web Site) должен измениться SLL сертификат для https, проверить это можно зайдя в мастер редактирования Привязок (Bindings).

    image

    Рис.9: SSL сертификат для https.

    Импорт/экспорт сертификатов

    Для того, чтобы клиенты и серверы (например, ISA/TMG) могли принимать сертификат Exchange`a и пользоваться им, нужно выполнить 2 условия:

    1. Обеспечить клиентов доверием к этому сертификату;

    2. Обеспечить серверы самим сертификатом.

    Что касается клиентов, то в случае рабочих станций, находящихся в домене, сервер ЦС сам позаботится о том, чтобы доменные пользователи ему доверяли, и установит свой сертификат к ним в Trusted Root Certification Authorities. Если же у вас есть не доменные пользователи, то вам нужно запросить сертификат ЦС и импортировать его вручную. Проще всего запросить сертификат ЦС через веб-браузер по адресу http://YourCA/certsrvЗагрузка сертификатов ЦС, цепочки сертификатов или CRL.

    image

    Рис.10: Запрос сертификата ЦС.

    Скачав сертификат на локальный компьютер его можно импортировать на клиентов при помощи групповой политики (для доменных пользователей) – Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certificate Authorities

    image

    Рис.11: Назначение корневых сертификатов при помощи GPO.

    Или вручную при помощи оснастки MMCCertificates. Запускаем MMC от имени администратора – File – Add/Remove Snap-is – Certificates – Computer AccountLocal Computer – выбираем нужный раздел и нажимаем Импорт.

    image

    Рис.12: Импорт сертификата через MMC.

    Также сертификат можно установить нажав на файле правой кнопкой мыши – Установить сертификат (Install Certificate) и поместить его в необходимый контейнер:

    image

    Рис.13: Установка сертификата в выбранный контейнер.

    Но в этом случае сертификат будет установлен не для компьютера, а для пользователя.

    Что касается экспорта, то Личные (Personal) сертификаты выгружаются с приватным ключом

    image

    Рис.14: Выгрузка сертификата с приватным ключом.

    И при выгрузке надо указать, что экспорт необходимо осуществить со всеми дополнительными параметрами:

    image

    Рис.15: Выгрузка с дополнительными параметрами.

    Далее необходимо указать пароль на файл и сохранить файл с расширением *.pfx на локальный компьютер.

    Корневые сертификаты выгружаются проще, здесь нужно указать формат DER encoded binary X.509 (.CER) и сохранить сертификат в файл с расширением *.cer.

    image

    Рис.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

Комментарии

  1. у меня пока 3 вопроса:
    1) зачем нужно экспортировать сертификат Exchange с закрытым ключом? Для какой цели?
    2) если CA установлен в текущем лесу и работает под управлением Windows Server, ничего публиковать не надо, т.к. он сам публикует свой сертификат в нужное хранилище. Причём, не только в домене, но и во всём лесу. Следовательно, если корневой CA находится вне текущего леса или работает не под управлением Windows Server, его сертификат целесообразно публиковать не через групповые политики, а напрямую в Active Directory.
    3) на рисунке 14 вы показываете экспорт сертификата самого CA с закрытым ключом. Для чего это требуется?

    спасибо.

  2. Exchange 2010 прекрасно создает SAN сертификаты из мастера и EMS

    Для включения функции SAN, на сервере с корневым центром сертификации необходимо выполнить команду:
    certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

    Вот это нужно делать только для того, чтобы запрашивать сертификат из MMC, а не EMS или EMC от Exchange 2010.

  3. To Vadims Podāns:
    – Сертификаты выгружаются с закрытым ключом потому, что потом их планируется импортировать на TMG, который не входит в домен.
    – “если CA установлен в текущем лесу и работает под управлением Windows Server, ничего публиковать не надо” – совершенно верно,об этом сказано в самом начале абзаца “Что касается клиентов, то в случае рабочих станций, находящихся в домене,…”, о публикации через GPO рассказано просто “для справки”.
    – “сертификат целесообразно публиковать не через групповые политики, а напрямую в Active Directory.” – спасибо, учту.

  4. — Сертификаты выгружаются с закрытым ключом потому, что потом их планируется импортировать на TMG, который не входит в домен.

    это плохо, потому что TMG/ISA должна иметь свою ключевую пару и свой сертификат (с такими же именами в поле Subject и расширении SAN). Экспортируемость ключа повышает вероятность, что его сопрут у вас из под носа.

    Вот вам на заметку про экспортируемые ключи: http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=21

    в достаточно доступной форме рассказано, почему так делать нельзя (и когда это можно и нужно).

  5. Vadims Podāns, почитал вашу заметку о вреде экспортируемых сертификатов. Многие сценарии надуманы и основаны на недоверии к администраторам или пользователям, оставляющим свои компы незалоченными. Это безусловно опасно, но решается никак не на уровне неэкспортируемых сертификатов, а смарткартами и прочими средствами повышения безопасности.

    Что до не экспортируемости… Имея админские права, неэкспортируемый сертификат замечательно достается из любого хранидища компьютера, нужна лишь специальная программа.

  6. > Многие сценарии надуманы

    с таким подходом можно сказать, что перехват трафика тоже надуман и сертификатами SSL можно смело пренебречь. Да и производители HSM тоже продают свою продукцию для исключения лишь каких-то надуманных сценариев.

    > Это безусловно опасно, но решается никак не на уровне неэкспортируемых сертификатов, а смарткартами и прочими средствами повышения безопасности.

    я хотел бы посмотреть, как вы на смарт-карте будете хранить сертификаты Exchange.

    > решается никак не на уровне неэкспортируемых сертификатов

    но это одна из мер, которая снижает риск компрометации ключей.

    > Имея админские права, неэкспортируемый сертификат замечательно достается из любого хранидища компьютера, нужна лишь специальная программа

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

  7. > перехват трафика тоже надуман и сертификатами SSL можно смело пренебречь

    Зачем же переходить в другую крайность…

    > Да и производители HSM тоже продают свою продукцию для исключения лишь каких-то надуманных сценариев.

    Специальные средства, HSM, смарт карты с доступом к закрытому ключу с вводом пин-а — они действительно решают свою задачу — безопасное хранение закрытых ключей, в отличае от пометки ключа неэкспортируемым.

    > тогда даже админских прав и специальной программы не надо для выноса ключей

    Не знаком с таким способом… Можете поделиться?

  8. > Зачем же переходить в другую крайность…

    это не крайность, просто вариант сценария. Вы ведь отрицаете возможность хищения ключа? А я отрицаю возможность перехвата трафика.

    > Специальные средства, HSM, смарт карты с доступом к закрытому ключу с вводом пин-а — они действительно решают свою задачу — безопасное хранение закрытых ключей, в отличае от пометки ключа неэкспортируемым.

    Безусловно это так. Но эти средства стоят относительно больших денег (скажем, те же HSM по несколько килобаксов) и обеспечивают высокий уровень защиты. Компании неориентированные в этом направлении либо неспособны купить такое решение или не осознаёт/считает нецелесообразным его необходимость. Поэтому для бюджетных решений целесообразно применять хотя бы такие простые меры для снижения вероятности выноса ключей.

    > Не знаком с таким способом…

    вот поэтому вы так немного легкомысленно относитесь к такой простой, но вполне достаточной мере защиты ключей от выноса.

  9. проблемка!
    застрял на Запросе сертификата через веб-мордочку. ЦС обозвал SRV-FR-CA, вбиваю в браузер http://srv-fr-ca/certsrv и ничего! даже при отключенной усиленной безопасности в IE8 – ничего!
    еще пробовал “Выдать новый запрос…” в самой оснастки “Центр сертификации”, но после выбора файла *.req ничего не происходит!
    что я пропустил??

  10. извиняюсь! ))
    всемогущий ребут и правильный урл (не имя ЦС, а имя хоста нужно) и чудесным образом веб-мордочка показала свой интерфейс. ))
    но у меня почему-то в “Шаблонах сертификатов” отсутствует “Веб-сервер” (как показано на скрине данной статьи), а есть только “Пользователь” и “Базовое шифрование EFS” !
    хотя в оснастки «Центр сертификации» он присутствует!

    P.S. с начала я проморгал этот момент и при подтверждении сертификата на сервере Exchange он у меня просто исчез! О_о

  11. разобрался!
    формируя запрос на веб-мордочку нужно было заходить с сервера на котором установлен Exchange, а не ЦС. )
    у меня TMG является членом домена, по этому манипуляции с LDAP не проводил, а выбрал проверку подлинности “Active Directory (Windows)”
    по внешнему урл захожу без проблем: выбираю “Продолжить открытие этого веб-узла”, появляется Outlook Web App, ввожу domenusername и password, “Вход в систему” и вижу:
    Не удается отобразить страницу. Код ошибки: 500 Внутренняя ошибка сервера. Параметр задан неверно. (87)

    всё делал по инструкции, в чем тонкость??

  12. Александр, предлагаю вам дополнительно посмотреть веб-каст на эту тему (ссылка в конце статьи), если проблема не решиться – то пишите на электронку alexey_b @ list . ru, будем разбираться детальней.

  13. Спасибо Вам за столь полезный и понятный веб-каст! )
    сделал всё по шагах и заработало!! ))
    однозначно не могу сказать где я ошибся, но думаю где-то с сертификатом напортачил…

  14. Приветствую, Алексей!
    Ты мне как-то помог с перемещением почтовой базы на TechNet…
    Тут решил обзавестись сертификатом, но застрял в самом начале.
    Все делаю строго по пунктам, но никак не появляется Subject Alternative Name в списке сертификата.
    Сервер 2008R2 Standart, ADC, Exchange 2010.
    Делаю все именно так:
    1.Отмечаю галкой роль «Службы сертификации AD», далее;
    2.Отмечаю «Центр сертификации», «Служба регистрации в центре сертификации через Интернет», далее;
    3.Задание типа установки – «Предприятие», далее;
    4.Задание типа ЦС – «Корневой ЦС», далее;
    5.Установка закрытого ключа «Создать новый закрытый ключ», далее;
    6.Шифрование «RSA (SHA1)», Галочку «Разрешить взаимодействие с администратором…. – не ставлю, далее;
    7.Имя – оставляю по умолчанию, далее;
    8.Срок – 5 лет, далее;
    9.Расположение по умолчанию, далее;
    10.Устанавливаем;
    11.В PowerShell (x86) вставляю «certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2», пишет, что выполнилось успешно;
    12.Перезапускаю службу «certsvc»;
    13.Захожу в диспетчер сервера, службы сертификации AD, нахожу сертификат, и нет там SAN (Дополнительное имя субъекта).
    Очередной раз нуждаюсь в твоей помощи:)
    Что я делаю не так?

    Большое спасибо за ранее.

  15. Для обеспечения доверия к сертификату на различных платформах (например на мобильных устройствах) для данной задачи большинство доверенных центров сертификации разработали сециальные виды сертификатов. Например в линейке COMODO это UCC (Unified Communications Certificate). Получить данные сертификаты можно, например, в foxlaboratory.ru.

  16. Камрады проблема!, установил корневой центр сертификации на Контроллер домена 2008R2 для сертификация Exchange 2010. При вводе в строке браузера команды http://localhost:80/CertSrv выдет ошибку

    Модуль IIS Web Core
    Уведомление BeginRequest
    Обработчик Пока не определено
    Код ошибки 0x80070003
    Ошибка конфигурации Не удалось прочитать файл конфигурации
    Файл конфигурации \?C:Windowssystem32CertSrvru-RUweb.config
    Запрашиваемый URL-адрес http://localhost:80/CertSrv
    Физический путь C:Windowssystem32CertSrvru-RU
    Способ входа Пока не определено
    Пользователь, выполнивший вход Пока не определено

    На сервере IIS базы 1С доступ к ним из Web есть все без нарекания. В чем может быть засада? Может кто сталкивался с такой бедой?

  17. Файл C:Windowssystem32CertSrvru-RUweb.config существует? В Authentication что выбрано для вирт. каталога?
    А Web Enrollment для СА вообще ставился?

  18. 1. файл конфига есть
    2. В аутефикации – Проверка подлинности Виндовс Включен!
    3. Служба установлена Состояние Работает.

  19. Уважаемые, есть сертификат от Comodo – wildcard *.example.com
    Можно его привязать к exchange 2010?

  20. To Юрий,
    Конечно же можно, но есть маленькое “но”, внутри сети вечно будет жалоба на не совпадающие имена внутри домена организации и снаружи.