Как сделать сертификат для exchange

Обновлено: 04.07.2024

Сертификаты можно использовать для шифрования потока коммуникации между конечными точками, которыми могут быть как клиенты так и серверы. Сертификаты могут также использоваться этими конечными точками для аутентификации друг на друге. В Exchange 2007 есть несколько компонентов, которые используют сертификаты для шифрования, аутентификации или в обоих случаях. В первой части этой серии я предоставил вам обзор различных компонентов Exchange, которые используют сертификаты, а также рассказал с какой целью они их используют. Я также подробно рассказал о функциях стандартного генерирования самоподписных сертификатов (by-default generated self-signed certificate). В этой части серии я расскажу о требованиях к сертификатам, которые нужно учитывать при их получении. В заключительной третьей части серии я предоставлю вам подробное описание различных команд Exchange Management Shell, которые используются для создания, управления и удаления сертификатов Exchange.

Как доверять самоподписным сертификатам (Self-Signed Certificate)?

Как говорилось в первой части этой серии статей, можно настраивать Exchange (он имеет поддержку) на использование самоподписных сертификатов для внутренних сценариев. Чтобы убедиться в том, что ваши клиенты не получают никаких предупреждений безопасности при подключении к серверу клиентского доступа Exchange 2007 Client Access, нужно, чтобы ваши пользователи доверяли самоподписным сертификатам. Помните, что обучение пользователей игнорированию уведомлений безопасности является ОЧЕНЬ плохой мыслью! На рисунке 1 показано, что самоподписной сертификат не имеет доверия при использовании Outlook Web Access.

Рисунок 1: Отсутствие доверия самоподписному сертификату

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

1. Экспортирование самоподписного сертификата

Чтобы экспортировать самоподписной сертификат, можно воспользоваться командой Export-ExchangeCertificate оболочки Exchange Management Shell. Поскольку это автоматически включает частный ключ, вам нужно определить пароль, что я собственно и сделал в примере на рисунке 2 путем определения переменной строки безопасности $pwd. Обратите внимание, что самоподписной сертификат можно экспортировать только в том случае, если вы отметили его как сертификат, имеющий экспортируемый частный ключ (об этой процедуре говорилось в первой части).

Рисунок 2: Экспортирование самоподписного сертификата

2. Публикация самоподписного сертификата в качестве доверенного сертификата с помощью групповой политики

Можно опубликовать экспортированный сертификат в личном хранилище пользователя с помощью групповой политики. В следующем примере я запустил консоль управления групповой политикой для создания новой групповой политики и ее применения к домену (рисунок 3).

Рисунок 3: Создание и присоединение нового объекта групповой политики (GPO) к домену

Я назвал новый GPO Trust Self Signed Certificate, и не использовал никакого объекта Source Starter GPO (рисунок 4).

Рисунок 4: Название нового GPO

Поскольку я хочу импортировать экспортированный самоподписной сертификат, я перейду к Конфигурации пользователя, Политикам, Настройкам Windows, Политикам частного ключа и правой клавишей нажму Доверенные люди (Trusted People), чтобы запустить мастера импортирования сертификатов (рисунок 5).

Рисунок 5: Запуск мастера импортирования сертификатов

Я укажу ранее созданный файл путем выполнения команды Export-ExchangeCertificate, и нажму Далее для продолжения (рисунок 6).

Рисунок 6: Выбор файла для импортирования

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

Рисунок 7: Ввод пароля, использовавшегося для защиты частного ключа

Хранилищем сертификатов, в котором будет храниться сертификат, будет Личное хранилище (Personal Store), жмем Далее для продолжения (рисунок 8).

Рисунок 8: Выбор хранилища сертификата, в котором будет находиться сертификат

Для завершения жмем Готово после просмотра всех имеющихся параметров (рисунок 9).

Р исунок 9: Завершение работы мастера импортирования сертификатов

Мастер импортирования сертификатов скажет о том, что процесс импортирования успешно завершен. Жмем OK, и процесс импортирования завершен, групповая политика готова к применению (рисунок 10).

Рисунок 10 : Импортирование прошло успешно

При следующем входе пользователя в домен или обновлении групповой политики самоподписной сертификат будет отмечен, как доверенный. Это видно при получении доступа к Outlook Web Access (рисунок 11).

Рисунок 11: Самоподписной сертификат = доверенный (Trusted)

Получение сертификата из публичного центра сертификации (public certification authority)

Несмотря на то, что Exchange 2007 может генерировать самоподписные сертификаты во время установки, и вы можете заставить клиентов доверять им, следует помнить то, о чем я писал в первой части:

Поэтому рекомендуется получить сертификат из центра сертификации. Можно установить собственный центр сертификации или получить сертификат из публичного центра сертификации. Компания Microsoft рекомендует получать сертификаты из публичного центра сертификации в следующих ситуациях:

Внешние клиенты получают доступ к Exchange (POP, IMAP, Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, Autodiscover)

Если вы получаете сертификат из публичного центра сертификации, вам не придется тратить массу усилий на то, чтобы ваш центр сертификации воспринимался как доверенный клиентами, не входящими в домен, и/или партнерскими организациями, которые хотят настроить безопасность домена с вашей средой 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), которые можно использовать для установки функции Безопасности домена.

Что такое публичный центр сертификации?

Публичные центры сертификации, также известные как корневые центры сертификации (root certification authorities), являются издателями сертификатов, которым доверяют практически все основные обозреватели и приложения, тем самым избавляя от необходимости делать центр сертификации доверенным. Когда вы принимаете решение о получении сертификата с публичного центра сертификации, вам нужно знать, будет ли этот публичный центр сертификации доверенным для всех приложений, которые вы будете использовать, и может ли он предоставить необходимые вам сертификаты (речь идет об именах, сроке действия и т.д.).

Какие имена нужны в сертификате

Рассматривая сертификат и причины, по которым сертификат непригоден для шифрования и аутентификации в Exchange, обычно все сводиться к четырем следующим моментам:

Несмотря на то, что некоторые приложения, такие как Outlook Web Access, позволяют использовать сертификат, даже если он выпущен не доверенным ЦС, или сертификат был выпущен для другого адреса веб сайта, не рекомендуется игнорировать данные предупреждения, поскольку они могут означать, что кто-то или какой-либо процесс пытается вас одурачить или перехватить какие-нибудь данные, о чем четко написано в Microsoft Internet Explorer 7 (рисунок 12).

Рисунок 12: Предупреждение сертификата безопасности

Outlook Anywhere и Exchange ActiveSync работать не будет, если есть проблемы с сертификатом (рисунок 13).

Рисунок 13: Outlook Anywhere не может подключиться, поскольку имя сертификата безопасности не совпадает с именем целевого сайта

Давайте рассмотрим имена, которые нужны в сертификате безопасности для сервера клиентского доступа:

Имя, используемое для публикации Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, Pop, и/или IMAP для внешних клиентов.

Имена сертификатов безопасности, которые нужны для ваших серверов Hub/Edge Transport:

Представьте, что у вас есть среда, показанная на рисунке 14.

Рисунок 14: Примерная организация Exchange

В этой среде Exchange вы публикуете Outlook Web Access и Outlook Anywhere с помощью сервера ISA, расположенного в DMZ. Почта, отправляемая из вашей организации и приходящая на нее, проходит через роль сервера Exchange Edge, также расположенного в DMZ. В вашей организации Exchange есть два домена, за которые она отвечает: ProExchange.Global и BelgianBeers.Rock. Вы согласились настроить безопасность домена (Domain Security) между вашей Exchange организацией и одной из партнерских организаций Sunshine.Edu. EdgeSync настроена на репликацию вашей конфигурации и информации получателя на сервер Edge. Вы получите два сертификата с публичного доверенного ЦС, один для публикации Outlook Web Access и Outlook Anywhere, а второй для установки безопасности домена между вашей организацией Exchange и Sunhine.Edu.

В таблице 1 приведен список серверов Exchange и их ролей, которые есть в данной среде Exchange.

Таблица 1

FQDN Exchange Server	Exchange Server 2007 Sp1 (RU5) роли установлены
Edge.ProExchange.dmz	Edge Server роль
Ex2007EE.ProExchange.Global	Mailbox + Client Access + Hub Transport роль
Ex2007SE.ProExchange.Global	Роль сервера Unified Messaging

Более подробное рассмотрение вашей организации Exchange открывает URL, перечисленные в таблице 2, которые используются пользователями извне и внутри для подключения к своим почтовым ящикам.

Эти URL можно получить и изменить с помощью оболочки Exchange Management Shell. На рисунке 15 приведены команды Exchange Management Shell для получения URL, предоставленных Exchange веб службой Autodiscover для клиентов Microsoft Office Outlook 2007.

Рисунок 15: Параметры конфигурации InteralUrl и ExternalUrl

Чтобы включить безопасный доступ к Outlook Web Access и опубликовать Outlook Anywhere, следующие имена должны присутствовать в сертификате, который вы включите для службы IIS на внутреннем сервере клиентского доступа (Client Access Server) и экспортируете на свой сервер ISA 2006 Sp1:

Общее имя (Common Name) = Webmail.ProExchange.Global, Outlook Anywhere требует, чтобы общее имя совпадало с внешним именем узла, используемого для включения Outlook Anywhere

Имена SAN: Webmail.ProExchange.Global Webmail.BelgianBeers.Rock Autodiscover.ProExchange.Global Autodiscover.BelgianBeers.Rock Ex2007EE.ProExchange.Global Ex2007EE Ex2007SE.ProExchange.Global Ex2007SE

Чтобы включить EdgeSync, предложить случайный TLS и настроить безопасность домена с партнерской организацией Sunshine.Edu, вам нужен сертификат для роли сервера Microsoft Exchange Edge со следующими именами:

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

Заключение

В первой части этой серии о сертификатах Exchange мы рассмотрели то, какие компоненты Exchange 2007 используют сертификаты, и какими характеристиками обладает самоподписной сертификат. В этой части я показал вам, как можно делать самоподписные сертификаты доверенными и какие имена нужны вашему сертификату Exchange, прежде чем его можно будет использовать. В третьей части я подробно расскажу о различных командах Exchange Management Shell, которые можно использовать для создания, управления и удаления сертификатов Exchange.

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

Как прикрутить его к днс имени в хостинге, как прикрутить его к Exchange?

Изменен тип Vasilev Vasil Microsoft contingent staff 22 апреля 2019 г. 10:21 давность, нет активности

Все ответы

Опишите пожалуйста подробнее публикацию ваших CAS сервисов Exchange:
- извне клиенты напрямую ходят на Exchange
- либо через reverse proxy, балансеры и т.д.

Чтобы получить сертификат от коммерческого ЦС, вы должны были ему скинуть csr-запрос. Этот запрос, в свою очередь, генерировался на каком-то сервере (обычно для этого используют EMC или консоль IIS). Получив сертификат в формате crt, вы должны его скопировать на сервер, на котором делался запрос, и завершить этот запрос.

По сути делал все по мануалу, из вне использую оснастку OWA. Прокси и балансеры (не знаю что это) не подключены. Сервер имеет публичный адрес и публичное ДНС имя на которое был выдан сертификат.

Чтобы получить сертификат от коммерческого ЦС, вы должны были ему скинуть csr-запрос. Этот запрос, в свою очередь, генерировался на каком-то сервере (обычно для этого используют EMC или консоль IIS). Получив сертификат в формате crt, вы должны его скопировать на сервер, на котором делался запрос, и завершить этот запрос.

Мы создали запрос (файл есть) и на основании этого запроса, они сделали сертификат.

Попробовал через стандартную функцию Exchange сделать импорт сертификата, Сервер-Сертификаты-Импорт сертификата Exchange, указывал сертификат формата *crt в сетевой папке, выбираю имя сервера, и импорт прошел успешно, но в списке он не появился.

Повторный импорт выдает ошибку:

Ошибка
На сервере XXMAIL возникает характерная для Rpc ошибка: Не удается импортировать сертификат. Сертификат с отпечатком 339C4C43193655D564564771211574B228EB22C1 уже существует.

Перезагрузку сервера делал, в списке все равно отсутствует.

Но я не очень разобрался что тут делать.

А если у меня имеется файлы запроса *csr и *rsa, могу я что либо сделать ? или запрашивать конторы что делала серт ?

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

Пароль Вы должны указать сами при конвертации, в формате PEM сертификат поставляется без пароля.

Возможно я при помощи этого генератора и должен сгенерировать закрытый ключ ?

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

Не наоборот: закрытый ключ не хранит никаких паролей, зачем ему это?

Итак. У вас есть сервер, где вы генерировали запрос csr. У вас есть сертификат в формате crt. Вам надо зайти в консоль эксча, выбрать тот самый запрос и завершить его (подсунув файлик crt). Таким образом вы и получите нормальный сертификат с закрытым ключом.

p.s. Если у вас возникают сложности с этими задачами, обратитесь к аутсорсу или отдельным специалистам, которые специализируются на администрировании Exchange.

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

Не наоборот: закрытый ключ не хранит никаких паролей, зачем ему это?

Итак. У вас есть сервер, где вы генерировали запрос csr. У вас есть сертификат в формате crt. Вам надо зайти в консоль эксча, выбрать тот самый запрос и завершить его (подсунув файлик crt). Таким образом вы и получите нормальный сертификат с закрытым ключом.

p.s. Если у вас возникают сложности с этими задачами, обратитесь к аутсорсу или отдельным специалистам, которые специализируются на администрировании Exchange.

Нашел статейку, пойду читать.

Мне сконвертировали ключ, теперь есть *pfx, подскажите что дальше ?)

не могу добавить по инструкции, говорит что есть сертификат, на форуме нашел, что в шеле можно выполнить команду

и в конце добавить

Пробовал и в конце добавить " | Remove-Item", пробовал и в место | ?

Пишет или не знаю что такое | Remove-Item, или Непредвиденная лексема ">" в выражении или операторе.

Нашел другой ресурс, там советуют команду

Remove-ExchangeCertificate -Thumbprint 339C4C43193655D564564771211574B228EB22C1

Но оно при согласии удалить (Y-да), выдало ошибку:

На сервере XXMAIL возникает характерная для Rpc ошибка: Обнаружен сертификат с отпечатком 339C4C43193655D56456477121157
4B228EB22C1, но он не допустим для сервера Exchange Server (причина: PrivateKeyMissing).
+ CategoryInfo : NotSpecified: (:) [Remove-ExchangeCertificate], InvalidOperationException
+ FullyQualifiedErrorId : [Server=XXMAIL,RequestId=13c9060b-c001-4d44-82b1-e522e1255b37,TimeStamp=26.03.2019 16:26
:49] [FailureCategory=Cmdlet-InvalidOperationException] A1A260CA,Microsoft.Exchange.Management.SystemConfiguration
Tasks.RemoveExchangeCertificate
+ PSComputerName

Помогите пожалуйста, как удалить чтоб заново импортировать ?

Подкорректировал предыдущий пост, вышло вот так

Вообщем при импорте, все равно выдает что :

На сервере ХХMAIL возникает характерная для Rpc ошибка: Не удается импортировать сертификат. Сертификат с отпечатком 339C4C43193655D564564771211574B228EB22C1 уже существует

Помогите пожалуйста, как удалить и повторно импортировать сертификат ?

Да найдите вы уже вручную этот сертификат и удалите. Можно ведь все сделать через MMC, если не дружите с пошем.

Да найдите вы уже вручную этот сертификат и удалите. Можно ведь все сделать через MMC, если не дружите с пошем.

Хотя письма с мобильника уходят нормально. Подключаем как Exchange.

Подскажите пожалуйста, почему мобильник не видит письма и папки ?

Тоже самое касательно приложения на iphonе outlook, скачал, указываю имя сервер, пользователь, пароль тут же выдает ошибку о неправильном логине и пароле. А если указываю имя пользователя как в AD (что правильно), очень долго крутит загрузку и в итоге через пару минут выдает ошибку (время подключения к вашему почтовому серверу истекло. Пожалуйста проверьте почтовый настройки)

Куда копать, подскажите плз.

Сервер перезагружал целиком, у меня IIS и Exchange на одном сервере, локально сертификат установил, из интернета все устройства (owa и мобильные) авторизуются и на сертификат не ругается.

Но у мобильных не отображаются письма и папки (только папка входящие), что удивительно, но программа outlook на мобильном, тоже не авторизуется по таймауту.

1. Удостовериться, что в вашем новом сертификате включены все имена по которым клиенты подключаются к Exchange.

Exchange ActiveSync/ActiveSync Discover

Outlook Connectivity/ Outlook Autodiscover

Inbound SMTP Mail

Полные результаты копировать сюда не нужно, достаточно только ошибки (если таковые имеются).

3. Всё-таки разобраться с вашей инфраструктурой, а именно - выяснить используются ли балансировщики + как опубликован Exchange наружу.

Вот это инструмент. пока начал проверку с ActiveSync, есть одно предупреждение:

Additional Details
The certificate is only trusted on Windows Mobile 6.0 and later versions. Devices running Windows Mobile 5.0 and 5.0 with the Messaging and Security Feature Pack won't be able to sync. Root = CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE.
Elapsed Time: 6 ms.

Сегодня столкнулся с необходимостью обновления сертификата для Exchange и понял, что забыл, как правильно это сделать 🙂 Так что данная статья скорее является личной заметкой на будущее, хотя, безусловно, описываемый в ней метод, на мой взгляд, является оптимальным, тем более, что рекомендуется компанией Microsoft. Итак, нам необходимо обновить сертификаты для аутентификации сервера и шифрования трафика, в особенности через OWA и ActiveSync. Конечно вполне можно воспользоваться самозаверенным сертификатом Exchange, однако в нашей организацией развернута структура PKI, и выдача сертификатов с её помощью является более правильным и безопасным решением. В настоящее время я как раз пишу статьи по развертыванию PKI на предприятии, так что заглядывайте почаще, надеюсь на этой неделе хотя бы о планировании и развертывании напишу.

Вернемся к нашим баранам, вернее к сертификатам. В целом, задача сводится к четырем этапам:

Формирование запроса на выдачу сертификата для внутреннего ЦС;
Непосредственно получение сертификта;
Импорт его в организацию Exchange;
Включение и назначение сертификата службам Exchange, таким как POP, IMAP и т.д.

Наиболее правильным будет получение сертификата типа Subject Alternative Names (SAN), который позволяет, среди прочего, использовать в сертификате как DNS, так и NetBIOS имена почтового сервера. В первую очередь это удобно для самих пользователей, так как у меня, например, пользователи внутри организации могут зайти на OWA как по FQDN, так и по NetBIOS-Name сервера, причем FQDN внутренний и внешний отличаются.

Не все центры сертификации позволяют использовать такие сертификаты, хотя настройка ЦС для этого очень проста – в командной строке сервера, являющегося выдающим центром сертификации, выполните команды:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
iis reset /noforce

После этого ЦС сможет принимать запросы и выдавать сертификаты SAN.

Оформляем запрос

На сервере в Exchange Management Shell выполните:

Как видно, я включил в запрос все мыслимые имена почтого сервера, который используются, использовал ключ 1024 бита, разрешил его экспорт и указал дополнительный параметр –subjectname, который и является ключевым в запроса SAM сертификата. Значение указываются те, которые вы использовали при настройке рутового ЦС, в крайнем случае их можно посмотреть в самом рутовом сертификате.

Получение сертификата

Открываем WEB-интерфейс нашего ЦС, “Request a certificate” >> “Advanced certificate request” >> “Submit a certificate request or renewal request” В окно вставляете содержимое вашего файла запроса, созданного на предыдущем шаге, выбираете шаблон “WEB-Server” и нажимаете “Submit”. Сохраняете полученный сертификат на диске.

Импорт сертификата на сервер Exchange

Все просто – в EMS набираете:

Import-ExchangeCertificate –path

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

Включение и назначение сертификата

Enable-exchangecertificate -services IMAP, POP, UM, IIS, SMTP -thumbprint A68435BEF8131350KLJH03BA6FF4372D05ACE71L4

Сервисы указываете те, которые будут обслуживаться данным сертификатом, так как можно (и нужно!) создать несколько сертификатов с разными параметрами, например временем отзыва, доменными именами и т.д. Параметр thumbprint указываем тот, что записали на предыдущем шаге.

Все сертификат готов, попробуйте зайти на OWA и вы увидите аутентификацию уже с новым сертификатом. Безусловно, для корректной работы, в Корневые доверенные центры сертификации всех компьютеров необходимо занести сертификат корневого ЦС вашей организации. Об этом я попозже расскажу в следующих статьях.

У 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). Введем понятное имя сертификата и на странице ExchangeConfigurationвнимательно заполним FQDNимена узлов для необходимых нам сервисов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В нашем телеграм канале мы рассказываем о главных новостях из мира IT, актуальных угрозах и событиях, которые оказывают влияние на обороноспособность стран, бизнес глобальных корпораций и безопасность пользователей по всему миру. Узнай первым как выжить в цифровом кошмаре!

Мы уже говорили о SSL-сертификат для серверов Exchange в общих чертах, но мы собираемся более подробно рассмотреть вопросы защиты экземпляра Microsoft Exchange Server 2013. Хорошая новость заключается в том, что это действительно простой набор шагов, которые вам необходимо предпринять.

Если вы знакомы с Exchange Server 2013 и сертификатами SSL, у вас не возникнет никаких проблем. На всякий случай, если вы не в курсе и того, и другого, мы собираемся рассмотреть основы, чтобы помочь вам получить общее представление о том, как заблокировать и защитить Microsoft Exchange Server для вашей компании.

Что нового в Exchange Server 2013?

Прежде чем мы перейдем к шагу, который вы хотите предпринять для установки сертификата SSL на Exchange Server 2013, мы кратко рассмотрим основные изменения в этой версии коммуникационного решения Microsoft. Возможно, вы уже знакомы со всем этим, но это хорошее напоминание.

Центр администрирования биржи - К счастью, пользовательский интерфейс для Exchange Server 2013 сильно обновился. В этой версии консоль администратора полностью веб-интерфейс, что приятно. Однако из-за этого изменения некоторые старые статьи с практическими рекомендациями могут оказаться не столь полезными, если вы не можете найти настройки, которые они просят изменить. При этом большинству людей абсолютно нравится новый графический интерфейс.
Изменения архитектуры Exchange - Если вы знакомы с Exchange Server 2007 или 2010, вы знаете, что он был разделен на пять отдельных серверов, которые обрабатывали все. Это было сделано для того, чтобы весь комплекс работал более гладко. В Exchange Server 2013 это резко изменилось. Теперь вы имеете дело только с двумя основными серверами - сервером клиентского доступа и почтовым сервером.
ESE (расширяемый механизм хранения) - К сожалению, Microsoft настаивала на продолжении использования этого ядра базы данных для Exchange Server 2013 вместо SQL (что предпочли бы многие сетевые администраторы - оставьте нам комментарий, если вы один из них!), Но они изменили способ работы ESE. Каждая база данных работает как отдельный поток. Это означает, что если кто-то выйдет из строя, он не унесет с собой все остальное, что действительно приятно.
Встроенная защита от вредоносных программ - Спам-фильтры какое-то время были частью Exchange Server, но Microsoft сделала еще один шаг в Exchange Server 2013. Теперь в их программное обеспечение встроена защита от вредоносных программ. Это очень помогает в обеспечении безопасности и постоянной защиты вашей сети. Это действительно полезно, когда вы блокируете попытки фишинга и обеспечиваете безопасность пользователей сети.

Хотя в Exchange Server 2013 были и другие обновления и изменения, перечисленные выше являются главными, о которых мы должны знать.

Какой тип SSL-сертификата следует использовать?

Это будет зависеть от ваших потребностей, но вот краткий список типов сертификатов SSL, которые мы рекомендуем для настройки Exchange Server 2013.

Как установить сертификат SSL на Microsoft Exchange Server 2013

STEP 1 - CSR Создание

ШАГ 2 - Установка сертификата

После того, как вы получили сертификат SSL, следующим шагом будет его установка. Если вы получили файл .crt, вам потребуется отдельно установить промежуточные сертификаты. Если вы получили файл сертификата .p7b, промежуточные сертификаты уже установлены. В любом случае вы захотите установить основной сертификат SSL, выполнив следующую команду:

ШАГ 3 - Тестирование

Многим нравится пропускать этот шаг, но мы не рекомендуем его. После того, как ваш сертификат SSL установлен, вы хотите убедиться, что он работает правильно. Чтобы проверить установку, выполните следующую команду:

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

Ресурсы для SSL-сертификатов Exchange Server 2013

Вот еще несколько ссылок, которые могут быть полезны для правильной установки SSL-сертификата на ваш Exchange Server 2013.

Команды Exchange Server 2013

Вот удобный список всех страниц Microsoft о различных командах, которые вы будете использовать для установки SSL-сертификата в установке Exchange Server 2013.

У вас есть конкретные вопросы о выборе подходящего SSL-сертификата для установки Exchange Server 2013? Оставьте комментарий ниже или свяжитесь с нами, и мы позаботимся о том, чтобы вы получили нужные ответы. После того, как вы установили SSL сертификаты на сервере Exchange один или два раза станет проще. Сообщите нам, если вы нашли эту страницу полезной.

Читайте также: