среда, 16 мая 2012 г.

Установка WildCard SSL сертификата в Exchange 2010

clip_image001Ранее я уже писал о том, как работать с сертификатами на Exchange сервере (Публикация Exchange 2010 – “сертификация” ). Сегодня, в двух словах поговорим о том, как использовать wildcard-сертификаты.

WildCard SSL сертификаты отличаются от обычных SSL-сертификатов только тем, что они выдаются сразу на множество поддоменов. Выглядят это следующим образом - *.domain.ru. Соответственно такой сертификат - штука удобная (не надо генерировать несколько сертификатов с разными именами, не надо заморачиваться на тему SAN и т.п.), но иногда не очень безопасная и полезная, т.к. здесь один закрытый ключ распространяется сразу на множество серверов и, следовательно, возможность его компрометации возрастает в разы.

Генерация сертификата через EMC

Если мы воспользуемся мастером генерации нового сертификата, то он в самом начале предложит нам создать wildcard-сертификат (см. рис.1):

clip_image002

Рис.1: Создание wildcard-сертификата через EMC.

После установки этой галочки, без лишних вопросов про имена, включаемые в сертификат, будет предложено сгенерировать запрос, который потом нужно будет отправить в центр сертификации. Ответом на данный запрос, центр сертификации вам вышлет сертификат, который нужно будет активировать (см. пост Публикация Exchange 2010 – “сертификация”).

Активация уже имеющегося сертификата

Чаще всего, вам не нужно генерировать новый WildCard-сертификат, а приходится использовать уже имеющийся. В результате возникает задача как-то «подсунуть» его Exchange`y. Сделать это можно по крайней мере 2-я способами:

1. PowerShell командлетом, в котором нужно указать путь к контейнеру с сертификатом и ввести после запроса пароль:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\certificates\ExportedCert.pfx -Encoding byte -ReadCount 0)) -Password:(Get-Credential).password

2. Импортировать через оснастку MMC – Certificates – Local Computer (см. рис.2)

clip_image003

Рис.2: Импорт сертификата.

После того, как сертификат будет импортирован, он должен появиться в результатах выдачи командлета Get-ExchangeCertificate (см. рис.3).

Примечание: Если не появился, то первое что надо проверить – это есть ли закрытый ключ у сертификата.

Переключение служб на новый сертификат

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

Важное отличие от обычной процедуры активации сервисов здесь в том, что службы POP и IMAP нельзя активировать таким образом (http://technet.microsoft.com/en-us/library/aa997231.aspx Don't use the Enable-ExchangeCertificate cmdlet to enable a wildcard certificate for POP and IMAP services. To enable a wildcard certificate, you must use the Set-ImapSettings or Set-PopSettings cmdlets with the fully qualified domain name (FQDN) of the service.) Соответственно команды активации сервисов для wildcard сертификата будут выглядеть следующим образом (см. рис.3):

Enable-ExchangeCertificate -Thumbprint <thumbprint> -Services SMTP,IIS

Set-PopSettings -X509CertificateName mail. domain.ru

Set-IMAPSettings -X509CertificateName mail.domain.ru

clip_image005

Рис.3: Активация сервисов для wildcard-сертификата.

В командлетах Set-ImapSettings и Set-PopSettings необходимо указать реальное FQDN имя (НЕ *.domain.ru), которое пользователи будут использовать при подключении. Проверить результат можно командлетами Get-ImapSettings и Get-PopSettings.

Примечание: Thumbprint нужно взять из результатов выдачи командлета Get-ExchangeCertificate.

WildCard сертификат и ошибка Outlook Anywhere

В случае установки WildCard сертификата на сервер, где активирован Outlook Anywhere, у пользователей возникнут проблемы при подключении к серверу через ОА, т.к. в профиле Outlook`a установлена настройка «Подключаться только к прокси-серверам, содержащим это основное имя в своем сертификате:», которая по умолчанию равняется FQDN имени, указанном при настройке Outlook Anywhere, а именно – mail.domain.ru. А т.к. mail.domain.ru и *.domain.ru это все же разные вещи, вот и возникает подобная ошибка.

clip_image006

Рис.4: Настройка Outlook Anywhere.

Чтобы через Autodiscover раздавалась правильная настройка параметров подключения к прокси-серверу, необходимо руками сконфигурировать Outlook Provider. Для этого воспользуемся командлетом Set-OutlookProvider:

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.domain.ru

После этого msstd параметр должен «приходить» пользователям через Autodiscover правильный.

19 комментариев:

Сергей комментирует...

А если wildcard сертификат самоподписанный, то будет ли работать autodiscovery у пользователей вне домена? Притом, что root-ca и sub-ca сертификаты добавлены у них в доверенные корневые? А то уже неделю сражаюсь. Опубликовал через TMG несколько сайтов - Sharepoint и Exchange. Естественно Web listener на TMG один для Https, и сертификат - *.mycontora.com. Добавил на TMG в public names в правило и mail.mycontora.com и autodiscover.mycontora.com Всё ОК - и OWA и OA, а вот автодискавери никак не желает работать. У доменных юзеров в локальной сети нормально, хотя это конечно и несколько разные вещи. Спасибо.

Алексей Богомолов (Alexx) комментирует...

А страничка https://autodiscover.mycontora.com/autodiscover/autodiscover.xml открывается с внешки? Проблем с сертификатом не показывает?
Почитайте статью http://www.alexxhost.ru/2011/05/autodiscover-1.html может поможет... Вообще, мне думается, что проблема не в сертификате.

Сергей комментирует...

https://autodiscover.mycontora.com/autodiscover/autodiscover.xml открывается. и https://www.testexchangeconnectivity.com/ - Служба автообнаружения Outlook - тоже говорит, что всё ок. А настройки Outlook не получает хоть тресни. Пока в расстеряности.
кстати https://www.testexchangeconnectivity.com/ стал корректно работать, только после публикации отдельным правилом autodiscover на TMG.
буду пробовать все варианты http://www.alexxhost.ru/2011/05/autodiscover-1.html раз стандартно не выходит. Если выйдет, отпишу, что за прикол такой.

Сергей комментирует...
Этот комментарий был удален автором.
Сергей комментирует...

Решилась проблема. Решение нашлось через изучение логов с TMG. Судя по всему проблема скрывалась в конфигурации web listener. Обратил внимание, что пользователи по разному проходили проверку LDAP. testexchangeconnectivity.com - передавал учётные данные domain\user, а outlook - в виде user@domain.com.
TMG - не член домена, поэтому аутентификация LDAP.
Что было сделано: В правиле публикации закладка listener > properties (открыли свойства этого listnera). В его свойствах, на закладке Authentication, установлено Authentication Validation Method как LDAP. Тутже открываем Configure validation servers. Там в нижнем окне (define the login expressions...) делаем не domain\*, а *@Domain выражение. И ещё на на закладке Authentication, в Advanced, я указал домен по умолчанию.
Теперь правда при входе в OWA форма гласит, что введите domain\username, а вводит нужно username@domain.com, но это как бы можно и пережить или подправить саму форму.

Алексей Богомолов (Alexx) комментирует...

Спасибо за то, что поделились рецептом.

Александр комментирует...

Добрый день.
А если есть сценарий, когда используется wildcard сертификат и редирект в DNS, для того, чтобы пользователи внутри вводили внешний адрес.

При таком раскладе, когда доменный пользователь подключает аутлук - выдается ошибка, потому что хост ex.domain.local, а сертификат на *.domain.ru

Где забыл настроить?

Алексей Богомолов (Alexx) комментирует...

Есть по крайней мере два варианта решения задачи:
1. Использовать wildcard сертификат только для публикации сервера в Интернет (т.е. привязывать его только к листенеру на TMG, а серверу Exchange выдавать сертификат локального СА со всеми необходимыми именами)
2. Создать CAS-array (можно даже из одного единственного сервера) и указать имя array-a - mail.firma.ru. После этого прописать имя массива как RpcClientAccessServer для базы данных.

mixroot комментирует...

Алексей,
Все выше описанное вами очень здорово, даже больше скажу: Именно по вашему матералу я ставил массив серверов exchange 2010 sp1.
А как создать именно этот CAS Array? Меня это беспокоит, потому как у нас в вышестоящей организации, тоже exchange но один и вот им надо и autodiscovery/active sync и прочее.. Короче почему то не заводится, есть правда решение сделать этот самый сертификат..

Алексей Богомолов (Alexx) комментирует...

Не очень понял что именно не заводится... не получается CAS-Array создать?

Анонимный комментирует...

Алексей, подскажите, у меня сертификат после выдачи командлета Get-ExchangeCertificate так и не появился, как проверить, что у него есть закрытый ключ? И где взять пароль? Мы заказывали wildcard-сертификат у RU-Center.

Алексей Богомолов (Alexx) комментирует...

Прежде всего сертификат должен появиться в консоли ММС - Сертификаты. Если его открыть, то внизу должен быть нарисован ключик и написано про то, что закрытый ключ есть.
По поводу пароля - не должно быть пароля первоначально, т.к. вы в Ru-Center отправляете запрос, а они Вам возвращают ответ. Этот ответ надо открыть на сервере, где был сгенерирован запрос, тогда все и появится.

Unknown комментирует...

Да,я посмотрел, ключа у сертификата нет. Что делать? Перевыпускать сертификат?

Алексей Богомолов (Alexx) комментирует...

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

Unknown комментирует...

Добрый день.

В Echenge 2013 не появился сертификат WildCard открытый.

"Если не появился, то первое что надо проверить – это есть ли закрытый ключ у сертификата."

куда возможно стоит копать, для выяснения причины?

Анонимный комментирует...

Здравствуйте, имеется Exchange 2013 sp1 и wildcard сертификат, появилась необходимость включить IMAP ввожу команду Set-ImapSettings -X509CertificateName -mail.domain.ru после выводится сообщение:
Предупреждение: Команда выполнена успешно, но параметры 'Exchange\1' не были изменены
и сертификат не назначается службе, выдавая всю ту же ошибку, не подскажете, что делать в этом случае?

Алексей Богомолов (Alexx) комментирует...

а откуда у вас -mail.domain.ru, почему не просто mail.domain.ru?

Анонимный комментирует...

Не так написал, без черточки и вводил, на social.technet.microsoft сделали предположение, что с именно с сертификатом проблема, мой случай не единичный

Unknown комментирует...

Имеется два сервера Exchange 2013: Exch1.domain.com и Exch2.domain.com. Они в отказоустойчивом кластере (поэтому на стороне клиента общее имя почтового сервера mail.domain.com) Имеется два сертификата: mail.domain.com – на нем службы IMAP и POP3, и wildcard сертификат *.domain.com – на нем службы IIS и SMTP. Необходимо перенести службы IMAP и POP на wildcard серитификат. Выполняю команды
Set-IMAPSettings -X509CertificateName mail.domain.com
Set-PopSettings -X509CertificateName mail. domain.com
Перезагружаю службы IMAP и POP3
Вопрос: мне в команде set-imapsettings в параметре -X509CertificateName писать конкретное имя сервера (Exch1.domain.com), либо mail.doman.com?
Get-exchangecertificate выдает, службы IMAP и POP остались на старом сертификате (в параметре Services - IP…..). На wildcard сертификате – (…WS..)
Как мне привязать IMAP и POP3 к wildcard сертификату, - только удалить старый сертификат?

Отправить комментарий