Применимо к: Exchange Server 2010 SP1

Последнее изменение раздела: 2010-08-31

Протокол Secure Sockets Layer (SSL) обеспечивает безопасность взаимодействия между клиентом и сервером. Для этого он используется на сервере клиентского доступа Microsoft Exchange Server 2010. Клиенты включают в себя мобильные устройства и компьютеры в сети организации и за ее пределами. При этом клиенты могут использовать и не использовать подключения виртуальной частной сети (VPN).

В конфигурации сервера Exchange 2010 по умолчанию связь с клиентами шифруется по протоколу SSL при использовании Microsoft Office Outlook Web App, Exchange ActiveSync и мобильного Outlook. По умолчанию протоколы POP3 и IMAP4 не настроены для использования SSL.

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

Содержание

Обзор цифровых сертификатов

Цифровые сертификаты и использование прокси-сервера

Рекомендации по использованию цифровых сертификатов

Ограничения клиентов

Обзор цифровых сертификатов

Цифровые сертификаты — это файлы, которые используются аналогично паролям для подтверждения подлинности пользователя или компьютера. Они используются для создания зашифрованного канала SSL, по которому осуществляется взаимодействие с клиентами. Сертификат — это цифровой документ, который выпускается центром сертификации; он подтверждает подлинность держателя сертификата и позволяет сторонам взаимодействовать безопасным способом, используя шифрование.

Цифровые сертификаты выполняют следующие функции:

  • проверка того, что их владельцы — физические лица, веб-сайты и даже сетевые ресурсы, например маршрутизаторы — действительно являются теми, за кого себя выдают;

  • защита передаваемых по сети данных от похищения или изменения.

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

Сертификаты могут выдаваться для выполнения различных задач, в том числе для проверки подлинности веб-пользователей и веб-серверов, для использования расширений S/MIME, протоколов IPsec и TLS, а также для подписывания кода.

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

Типы сертификатов

Существует три основных типа цифровых сертификатов: самозаверяющие сертификаты, сертификаты, создаваемые инфраструктурой открытых ключей Windows, и сертификаты сторонних центров сертификации.

Самозаверяющие сертификаты

При установке Exchange 2010 автоматически настраивается самозаверяющий сертификат. Самозаверяющий сертификат подписывается приложением, которое создает его. Получатель и имя сертификата совпадают. Кроме субъекта, в сертификате указывается его издатель. Самозаверяющий сертификат позволяет некоторым клиентским протоколам использовать при передаче данных протокол SSL. Exchange ActiveSync и Outlook Web App могут устанавливать подключения SSL с помощью самозаверяющего сертификата. Мобильный Outlook самозаверяющие сертификаты не поддерживает. Самозаверяющие сертификаты необходимо вручную копировать в доверенное корневое хранилище сертификатов на клиентском компьютере или мобильном устройстве. Когда клиент подключается к серверу по протоколу SSL и сервер предъявляет самозаверяющий сертификат, у клиента запрашивается подтверждение того, что сертификат был выдан доверенным центром сертификации. Клиент должен явно выразить доверие этому центру сертификации. Если клиент подтверждает доверие, взаимодействие по протоколу SSL может быть продолжено.

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

Сертификаты, создаваемые инфраструктурой открытых ключей Windows

Второй тип сертификатов — сертификаты, создаваемые инфраструктурой открытых ключей Windows. Инфраструктура открытых ключей представляет собой систему цифровых сертификатов, центров сертификации и центров регистрации, которые проверяют допустимость каждого компонента, участвующего в электронной транзакции, с использованием шифрования с открытым ключом. При создании инфраструктуры открытых ключей в организации, использующей службу каталогов Служба каталогов Active Directory, необходимо обеспечить инфраструктуру для управления жизненным циклом сертификатов, их обновления, управления отношениями доверия и отзыва сертификатов. Однако для создания сертификатов инфраструктуры открытых ключей Windows и управления ими необходимо выделить дополнительные средства на развертывание серверов и инфраструктуры.

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

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

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

Инфраструктура открытых ключей Windows позволяет организациям публиковать собственные сертификаты. Клиенты могут запрашивать и получать сертификаты от инфраструктуры открытых ключей Windows во внутренней сети. Инфраструктура открытых ключей Windows может обновлять и отзывать сертификаты.

Доверенные сертификаты сторонних центров сертификации

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

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

В начало

Выбор типа сертификата

При выборе типа устанавливаемого сертификата следует учесть несколько факторов. Чтобы сертификат был допустимым, он должен быть подписан. Он может быть самозаверяющим или же подписанным центром сертификации. Самозаверяющий сертификат имеет ограничения. Например, не на всех мобильных устройствах пользователь может установить цифровой сертификат в доверенное корневое хранилище сертификатов. Поддержка установки сертификатов на мобильном устройстве зависит от изготовителя устройства и оператора мобильной связи. Некоторые изготовители и операторы мобильной связи отключают доступ к доверенному корневому хранилищу сертификатов. В этом случае на мобильном устройстве нельзя установить ни самозаверяющий сертификат, ни сертификат, полученный от центра сертификации инфраструктуры открытых ключей Windows.

Большинство мобильных устройств поставляются с несколькими предустановленными доверенными сторонними коммерческими сертификатами. Чтобы сделать работу максимально удобной, реализуйте для Exchange ActiveSync проверку подлинности на основе сертификатов с помощью устройств, работающих под управлением системы Windows Mobile 6.0 или более поздней версии, и цифрового сертификата, полученного от доверенного стороннего центра сертификации.

Сертификаты Exchange по умолчанию

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

Термин «Самозаверяющий» означает, что сертификат был создан и подписан только самим сервером Exchange. Поскольку он не был создан и подписан доверенным центром сертификации, самозаверяющий сертификат по умолчанию не будет доверенным для любого программного обеспечения, кроме других серверов Exchange из той же организации. Сертификат по умолчанию используется для всех служб Exchange. У этого сертификата есть дополнительное имя субъекта, соответствующее имени сервера Exchange, на котором он установлен. Кроме того, у него есть список дополнительных имен субъектов, которые включают в себя имя сервера и полное доменное имя сервера.

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

Требования к сертификатам для различных служб

Сертификаты используются для нескольких задач в Exchange. Большинство клиентов также используют сертификаты на нескольких серверах Exchange. Как правило, чем меньше используется сертификатов, тем проще ими управлять.

Службы IIS

Все следующие службы Exchange используют один и тот же сертификат на отдельном сервере Exchange: 

  • Outlook Web App

  • Панель управления Exchange

  • Веб-службы Exchange

  • Exchange ActiveSync

  • Мобильный Outlook

  • Автообнаружение

  • Распространения адресной книги Outlook

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

POP/IMAP

Сертификаты, используемые для POP или IMAP, можно задавать отдельно от сертификата для служб IIS. Однако для упрощения администрирования рекомендуется включить имя службы POP или IMAP в сертификат для служб IIS и использовать для всех этих служб только один сертификат.

SMTP

Отдельный сертификат можно использовать для каждого соединителя получения, настраиваемого на транспортных серверах-концентраторах или пограничных транспортных серверах. Этот сертификат должен содержать имя, используемое SMTP-клиентами (или другими SMTP-серверами) для доступа к соединителю получения. Чтобы упростить управление сертификатами, рекомендуется включить все имена, для которых требуется поддержка трафика TLS, в один сертификат.

Федерация Live

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

Единая система обмена сообщениями

При подключении серверов единой системы обмена сообщениями Exchange к серверам Microsoft Office Communications Server 2007, сторонним шлюзам SIP или телефонному оборудованию УАТС можно использовать самозаверяющий сертификат или доверенный сертификат сторонней организации для установки защищенных сеансов. Один сертификат можно использовать для всех серверов единой системы обмена сообщениями, пока сертификат содержит полные доменные имена всех серверов единой системы обмена сообщениями в списке SAN. Также потребуется создать отдельный сертификат для каждого сервера единой системы обмена сообщениями, где полное доменное имя сервера единой системы обмена сообщениями представлено в общем имени субъекта (CN) или списках SAN. Единая система обмена сообщениями Exchange не поддерживает групповые сертификаты для Communications Server 2007 и Communications Server 2007 R2.

Обмен мгновенными сообщениями в Outlook Web App с использованием Office Communications Server 2007 R2

Outlook Web App в Exchange 2010 включает в себя программный интерфейс, который позволяет поставщикам услуг обмена мгновенными сообщениями создавать надстройки для управления функциями присутствия и обмена мгновенными сообщениями. Надстройка находится в Communications Server 2007 R2. Чтобы воспользоваться ей, необходимо использовать сертификат для установки безопасного соединения между сервером Communications Server 2007 R2 и сервером клиентского доступа Exchange 2010. Этот сертификат должен быть установлен на серверах клиентского доступа Exchange. Для всех серверов клиентского доступа Exchange 2010 можно использовать несколько сертификатов или один сертификат, пока одно из имен узлов в общем имени сертификата (CN) или списке SAN представлено в списке авторизации узла на сервере Communications Server. Необходимым значением может быть только имя узла, доступное в сертификате, например mail.contoso.com. Групповые сертификаты для установки безопасного подключения к серверу Communications Server 2007 или 2007 R2 не используются.

Устаревшие серверы Exchange

Если вы следуете рекомендациям по переходу с Microsoft Exchange Server 2003 или Exchange Server 2007 на Exchange 2010, на период совместной работы, когда почтовые ящики находятся и на устаревших версиях Exchange, и на Exchange 2010, вам потребуется использовать новое имя узла — legacy.contoso.com. Это устаревшее имя узла также необходимо включить в используемый сертификат. Дополнительные сведения об обновлении с Exchange Server 2003 и Exchange 2007 до Exchange 2010 см. в разделах Обновление с клиентского доступа Exchange 2003 и Обновление с клиентского доступа Exchange 2007.

В начало

Цифровые сертификаты и использование прокси-сервера

Прокси-сервер используется, когда один сервер клиентского доступа отправляет клиентские подключения другому серверу клиентского доступа. Существует два сценария отправки прокси-трафика одним сервером клиентского доступа другому серверу клиентского доступа.

  1. Серверы клиентского доступа на сайте Служба каталогов Active Directory в Интернете отправляют прокси-трафик на серверы клиентского доступа на сайте, который не соприкасается с Интернетом. Это позволяет выполнять обработку клиентских запросов как можно ближе к серверу почтовых ящиков клиента.

  2. Серверы клиентского доступа для Exchange 2010 используются в качестве прокси для соединений от клиентов, почтовые ящики которых находятся на сервере Exchange 2003 или Exchange 2007. Эти клиентские подключения передаются на серверы клиентского доступа Exchange 2007 через прокси. Это происходит из-за того, что для многих служб Exchange серверу клиентского доступа не удается обрабатывать запросы для серверов почтовых ящиков, работающих под управлением более ранних версий Exchange.

Когда серверы клиентского доступа передают запросы, протокол SSL используется для шифрования, но не для проверки подлинности. В большинстве случаев для передачи данных через серверы клиентского доступа можно использовать самозаверяющий сертификат. Если в организации требуется введение чрезвычайных правил безопасности, существует ключ конфигурации, который можно задать, чтобы запрашивать доверенные сертификаты при передаче данных через серверы клиентского доступа. Чтобы настроить следующий ключ для данного сценария, для него необходимо установить значение «false»:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA\AllowInternalUntrustedCerts

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

Дополнительные сведения о перенаправлении см. в разделе Общие сведения по передаче данных через прокси-соединения и перенаправление.

Обратные прокси-серверы и сертификаты

В большинстве развертываний Exchange для публикации служб Exchange в Интернете используются обратные прокси-серверы. Примерами популярных продуктов на базе обратных прокси-серверов являются Microsoft Internet Security and Acceleration (ISA) Server и Checkpoint. Эти обратные прокси-серверы можно настроить для остановки шифрования SSL, изучения трафика на сервере в незашифрованном виде и последующего открытия нового канала шифрования SSL с обратных прокси-серверов на расположенные за ними серверы Exchange. Это называется мостом SSL. Другой способ настройки обратных прокси-серверов заключается в том, чтобы разрешить передачу подключений SSL непосредственно на серверы Exchange, расположенные за обратными прокси-серверами. При любой из моделей развертывания клиенты в Интернете подключаются к обратному прокси-серверу с использованием имени узла для доступа к Exchange, например mail.contoso.com. После этого обратный прокси-сервер подключается к Exchange с использованием другого имени узла, например имени компьютера сервера клиентского доступа Exchange. Вам не требуется включать это имя компьютера сервера клиентского доступа Exchange в сертификат, поскольку наиболее распространенные обратные прокси-серверы могут сопоставлять исходное имя узла, использованное клиентом, с внутренним именем узла сервера клиентского доступа Exchange.

Балансировка нагрузки и сертификаты

Если используется несколько серверов клиентского доступа, рекомендуется настроить массив серверов клиентского доступа. Этот массив позволяет всем клиентам подключаться к серверам клиентского доступа Exchange с использованием одного имени узла. В один массив серверов клиентского доступа можно добавлять любое число серверов клиентского доступа при условии, что все эти серверы находятся на одном сайте Служба каталогов Active Directory. Дополнительные сведения о балансировке нагрузки и массивах серверов клиентского доступа см. в разделах Общие сведения по передаче данных через прокси-соединения и перенаправление и Управление серверами клиентского доступа.

SSL и разделенная DNS

Разделенная DNS — это технология, которая позволяет настраивать для одного имени узла различные IP-адреса в зависимости от того, откуда поступил исходный DNS-запрос. Это также называется DNS с «расщеплением горизонта», комбинированным режимом DNS или расщепленной DNS. Разделенная DNS может помочь снизить количество имен узлов, которыми необходимо управлять в Exchange, позволяя клиентам использовать одно и то же имя узла для подключения к Exchange как из Интернета, так и из интрасети. Разделенная DNS позволяет запросам, исходящим из интрасети, получить IP-адрес, отличный от адреса запросов из Интернета.

Использование разделенной DNS обычно не требуется в небольших развертываниях Exchange, поскольку пользователи могут получить доступ к одной конечной точке DNS как из интрасети, так и из Интернета. Однако для более крупных развертываний такая конфигурация приводит к слишком высокой нагрузке на прокси-сервер исходящих подключений к Интернету и обратный прокси-сервер. Для крупных развертываний следует настроить разделенную DNS таким образом, чтобы внешние пользователи обращались к mail.contoso.com, а внутренние пользователи обращались к internal.contoso.com. При использовании разделенной DNS для данной конфигурации пользователям не требуется помнить об использовании различных имен узлов в зависимости от расположения.

Remote PowerShell

Проверка подлинности Kerberos и шифрование Kerberos используются для доступа к Remote PowerShell как из консоли управления Exchange, так и из командной консоли Exchange. Благодаря этому не требуется настраивать сертификаты SSL для Remote PowerShell.

В начало

Рекомендации по использованию цифровых сертификатов

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

Рекомендация. Использование доверенного стороннего сертификата

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

Выбор центра сертификации

Центр сертификации является компанией, которая выдает сертификаты и обеспечивает их допустимость. Клиентское программное обеспечение (например, браузеры, такие как Microsoft Internet Explorer, или операционные системы, такие как Windows или Mac OS) имеет встроенные списки доверенных центров сертификации. Обычно этот список можно настраивать для добавления и удаления центров сертификации, но часто это требует значительных усилий. Используйте следующие критерии выбора центра сертификации для приобретения сертификатов.

  • Убедитесь, что центр сертификации является доверенным для клиентского программного обеспечения (операционных систем, браузеров и мобильных телефонов), которое будет осуществлять подключение к серверам Exchange.

  • Выбирайте центр сертификации, для которого заявлена поддержка сертификатов единой системы обмена сообщениями для серверов Exchange.

  • Убедитесь, что центр сертификации поддерживает те типы сертификатов, которые планируется использовать. Рекомендуется использовать сертификаты с дополнительными именами субъектов. Такие сертификаты поддерживаются не всеми центрами сертификации; кроме того, некоторые центры сертификации могут не поддерживать требуемое количество имен узлов.

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

  • Сравните цены на сертификаты в разных центрах сертификации.

Рекомендация. Использование сертификатов с дополнительными именами субъектов

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

Рекомендация. Использование мастера сертификатов Exchange для запроса сертификатов

В Exchange существует множество служб, использующих сертификаты. Распространенная ошибка при запросе сертификатов заключается в выполнении запроса без включения в него правильного набора имен служб. Мастер запроса сертификатов в консоли управления Exchange поможет вам включить правильный список имен в запрос сертификата. Это мастер позволяет указать, с какими службами должен работать данный сертификат, и в зависимости от выбранных служб он включает требуемые имена в сертификат, чтобы его можно было использовать для этих служб. Запустите мастер сертификатов после того, как выполнено развертывание начального набора серверов Exchange 2010 и определено, какие имена узлов требуется использовать для различных служб данного развертывания. В идеальном случае мастер сертификатов требуется запустить только один раз для каждого из сайтов Служба каталогов Active Directory, на которых развертывается Exchange.

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

Рекомендация. Использование минимального количества имен узлов

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

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

В сертификаты Exchange необходимо включить те имена узлов, которые используются клиентскими приложениями для подключения к Exchange. Ниже приведен список типичных имен узлов, которые потребуются компании под названием Contoso:

  • Mail.contoso.com   Это имя узла охватывает большинство подключений к Exchange, включая Microsoft Office Outlook, Outlook Web App, мобильный Outlook, автономную адресную книгу, веб-службы Exchange, POP3, IMAP4, SMTP, панель управления Exchange и ActiveSync.

  • Autodiscover.contoso.com   Это имя узла используется клиентами, у которых включена поддержка автообнаружения, включая Microsoft Office Outlook 2007 и более поздних версий, клиенты веб-служб Exchange ActiveSync и Exchange.

  • Legacy.contoso.com   Это имя узла требуется во время совместной работы с Exchange Server 2003 или Exchange 2007. Если имеются клиенты с почтовыми ящиками как на устаревшей версии Exchange, так и в Exchange 2010, настройка устаревшего имени узла не позволяет пользователям узнать второй URL-адрес во время обновления. Дополнительные сведения о б обновлении и совместной работе см. в разделах Обновление с клиентского доступа Exchange 2003 и Обновление с клиентского доступа Exchange 2007.

Общие сведения о групповых сертификатах

Групповой сертификат предназначен для поддержки домена и нескольких поддоменов. Например, результатом настройки группового сертификата для *.contoso.com является сертификат, действующий для mail.contoso.com, web.contoso.com и autodiscover.contoso.com.

В начало

Ограничения клиентов

Некоторые клиенты Exchange имеют ограничения на поддерживаемые сертификаты. Эти клиенты и соответствующие им ограничения описаны ниже: 

  • Outlook на операционных системах Windows XP или более ранних версий   Компонент Windows RPC через HTTP, используемый для мобильного Outlook, требует, чтобы дополнительное имя субъекта или общее имя сертификата соответствовало имени участника сертификата, заданному для мобильного Outlook. В Outlook 2007 и более поздних версий для получения этого имени участника сертификата используется функция автообнаружения. Чтобы настроить данное значение на сервере клиентского доступа Exchange 2010, используйте команду Set-OutlookProvider с параметром -CertPrincipalName. Задайте для этого параметра имя внешнего узла, которое клиенты Outlook используют для подключения к мобильному Outlook.

  • Версии Outlook, предшествующие Outlook 2010, не поддерживают сертификаты с дополнительными именами субъектов для доступа к POP3 и IMAP4   В пакет обновления 2 (SP2) для Outlook 2007 входит исправление, которое обеспечивает поддержку дополнительного имени субъекта. Это исправление можно загрузить здесь.

  • Мобильные устройства   Некоторые мобильные устройства, включая работающие под управлением Windows Mobile 5.0 и некоторые устройства Palm, не поддерживают групповые сертификаты.