Поделиться через

Цифровые сертификаты и протокол SSL

  • Статья

Область применения: Exchange Server 2013 г.

Ssl — это метод защиты связи между клиентом и сервером. В Exchange Server 2013 году ssl используется для защиты обмена данными между сервером и клиентами. К клиентам относятся мобильные телефоны, компьютеры в сети организации и за ее пределами.

По умолчанию при установке Exchange 2013 обмен данными между клиентами шифруется по протоколу SSL при использовании Outlook Web App, Exchange ActiveSync и Outlook Anywhere.

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

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

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

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

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

  • Они защищают данные, которыми обмениваются через Интернет, от кражи или незаконного изменения.

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

Сертификаты могут быть выданы для нескольких применений. К ним относятся проверка подлинности веб-пользователей, проверка подлинности веб-сервера, безопасные и многоцелевые расширения электронной почты (S/MIME), безопасность по протоколу ИНТЕРНЕТ (IPsec), безопасность транспортного уровня (TLS) и подписывание кода.

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

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

Существует три основных типа цифровых сертификатов: самозаверяющих сертификатов, сертификатов windows PKI и сторонних сертификатов.

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

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

Примечание.

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

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

Сертификаты инфраструктуры открытых ключей Windows

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

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

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

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

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

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

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

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

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

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

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

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

"Самозаверяющий" означает, что сертификат был создан и подписан только самим сервером Exchange Server. Так как он не был создан и не подписан в обычно доверенном ЦС, самозаверяющий сертификат по умолчанию не будет доверять ни одному программному обеспечению, кроме других серверов Exchange в той же организации. Сертификат по умолчанию включен для всех служб Exchange. У него есть альтернативное имя субъекта (SAN), соответствующее имени сервера Exchange Server, на котором он установлен. Он также содержит список san, включающих как имя сервера, так и полное доменное имя (FQDN) сервера.

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

Требования к сертификатам по службам

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

Службы IIS

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

  • Outlook Web App

  • Центр администрирования Exchange (EAC)

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

  • Exchange ActiveSync

  • Мобильный Outlook

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

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

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

POP/IMAP

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

SMTP

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

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

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

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

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

Многие развертывания Exchange используют обратные прокси-серверы для публикации служб Exchange в Интернете. Обратные прокси-серверы можно настроить так, чтобы завершить шифрование SSL, проверить трафик на сервере, а затем открыть новый канал шифрования SSL от обратных прокси-серверов к серверам Exchange за ними. Это называется мостом SSL. Другой способ настроить обратные прокси-серверы — разрешить SSL-подключениям проходить прямо на серверы Exchange за обратными прокси-серверами. В любой из моделей развертывания клиенты в Интернете подключаются к обратному прокси-серверу, используя имя узла для доступа к Exchange, например mail.contoso.com. Затем обратный прокси-сервер подключается к Exchange, используя другое имя узла, например имя компьютера сервера клиентского доступа Exchange. Вам не нужно включать имя компьютера сервера клиентского доступа Exchange в сертификат, так как большинство распространенных обратных прокси-серверов могут сопоставлять исходное имя узла, используемое клиентом, с именем внутреннего узла сервера клиентского доступа Exchange.

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

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

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

Удаленная оболочка Windows PowerShell

Проверка подлинности Kerberos и шифрование Kerberos используются для удаленного Windows PowerShell доступа из Центра администрирования Exchange (EAC) и командной консоли Exchange. Поэтому вам не придется настраивать SSL-сертификаты для использования с удаленными Windows PowerShell.

Рекомендации по цифровым сертификатам

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

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

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

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

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

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

  • Выберите ЦС с поддержкой сертификатов Unified Communications для использования с Exchange Server.

  • Убедитесь, что ЦС поддерживает типы сертификатов, которые вы будете использовать. Рассмотрите возможность использования сертификатов альтернативного имени субъекта (SAN). Не все ЦС поддерживают сертификаты SAN, а другие ЦС не поддерживают столько имен узлов, сколько может потребоваться.

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

  • Сравнение цен на сертификаты между центрами сертификации.

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

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

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

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

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

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

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

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

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

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

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

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

Общие сведения о сертификатах с подстановочными знаками

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