Шифрование и управление сертификатами

Клиент WACS для установки TLS сертификата Let’s Encrypt в IIS на Windows Server

Самый простой способ получить SSL сертификат от Let’s Encrypt — воспользоваться консольной утилитой Windows ACME Simple (WACS) (ранее проект назывался LetsEncrypt-Win-Simple). Она представляет собой простой мастер, который позволяет выбрать один из сайтов, запущенных на IIS, и автоматически выпустить и привязать к нему SSL сертификат.

Итак, предположим у нас имеется веб сайт на IIS, развёрнутый под управлением Windows Server 2016. Наша задача, переключить его в HTTPS режим, установив SSL сертификат от Let’s Encrypt.

Скачайте последний релиз клиента WACS со страницы проекта на GitHub https://github.com/PKISharp/win-acme/releases (в моем случае это версия v2.0.10 – файл win-acme.v2.0.10.444.zip).

Распакуйте архив в каталог на сервере с IIS: c:\inetpub\letsencrypt

Откройте командную строку с правами администратора, перейдите в каталог c:\inetpub\ letsencrypt и запустите wacs.exe.

Запустится интерактивный мастер генерации сертификата Let’s Encrypt и привязки его к сайту IIS. Чтобы быстро создать новый сертификат выберите N — Create new certificates (simple for IIS).

Затем нужно выбрать тип сертификата. В нашем примере нет необходимости использовать сертификат с псевдонимами (несколькими SAN — Subject Alternative Name), поэтому достаточно выбрать пункт 1. Single binding of an IIS site. Если вам нужен Wildcard-сертификат, выберите опцию 3.

Далее утилита выведет список сайтов, запущенных на сервере IIS и предложит выбрать сайт, для которого нужно создать и привязать новый SSL сертификат.

Процесс генерации и установки SSL сертификата Let’s Encrypt для IIS полностью автоматизирован.

По умолчанию выполняется валидация домена в режиме http-01 validation (SelfHosting). Для этого нужно, чтобы в DNS домена имелась запись, указывающая на ваш веб сервера. При запуске WACS в ручном режиме можно выбрать валидацию типа — 4 Create temporary application in IIS (recommended). В этом случае на веб-сервере IIS будет создано небольшое приложение, через которое сервера Let’s Encrypt смогут провести валидацию.

Утилита WACS сохраняет закрытый ключ сертификата (*.pem), сам сертфикат и ряд других файлов в каталог C:\Users\%username%\AppData\Roaming\letsencrypt-win-simple. Затем она в фоновом режиме установит сгенерированный SSL сертификат Let’s Encrypt и привяжет его к вашему сайту IIS. Если на сайте уже установлен SSL сертификат (например, самоподписанный), он будет заменен новым.

В IIS Manager откройте меню Site Binding для вашего сайта и убедитесь, что для него используется сертификат, выданный Let’s Encrypt Authority X3.

В хранилище сертификатов компьютера сертификат Let’s Encrypt для IIS вы можете найти в разделе Web Hosting -> Certificates.

Windows ACME Simple создает новое правило в планировщике заданий Windows (win-acme-renew (acme-v02.api.letsencrypt.org)) для автоматического продления сертификата. Задание запускается каждый день, продление сертификата выполняется через 60 дней. Планировщик запускает команду:

C:\inetpub\letsencrypt\wacs.exe –renew –baseuri “https://acme-v02.api.letsencrypt.org”

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

Основы аутентификации на основе сертификата в iOS

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

В Service Fabric базовый уровень кластера (федерации) также строится на основе протокола TLS (а также других протоколов), что обеспечивает надежную и безопасную сеть участвующих узлов. Подключения к кластеру с помощью API клиента Service Fabric также используют TLS для защиты трафика, а также для удостоверений сторон. В частности, если сертификат используется для аутентификации в Service Fabric, его можно использовать для проверки следующих утверждений: а) сторона, представляющая учетные данные сертификата, обладает закрытым ключом сертификата, б) хэш-код SHA-1 сертификата (отпечаток) соответствует объявлению, включенному в определение кластера, или c) различающееся общее имя сертификата соответствует объявлению, включенному в определение кластера, и издатель сертификата известен или является доверенным лицом.

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

В следующих разделах подробно объясняется, как среда выполнения Service Fabric использует и проверяет сертификаты для обеспечения безопасности кластеров.

Глобально уникальное имя

Для этого сертификата требуется глобально уникальное имя для идентификации службы в Azure. Прежде чем запросить сертификат, убедитесь, что нужное имя развертывания Azure уникально. Например, .

Масштабируемый набор виртуальных машин

Войдите на портал Azure.
На домашней странице портал Azure выберите Создать ресурс в разделе Службы Azure.
Выполните поиск по запросу Масштабируемый набор виртуальных машин. Нажмите Создать.
Выберите подписку и группу ресурсов , которые будут использоваться для шлюза управления облачными клиентами.
В поле Имя масштабируемого набора виртуальных машин введите нужный префикс. Например, .
Выберите регион , который будет использоваться для шлюза управления облачными клиентами. Например, (США) — западная часть США.

Интерфейс отражает, доступно ли доменное имя или уже используется другой службой.

Важно!

Не создавайте службу на портале, просто используйте этот процесс, чтобы проверить доступность имени.

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

Учетная запись хранения CMG с поддержкой содержимого

Если вы также включите CMG для содержимого, убедитесь, что это также уникальное имя учетной записи хранения Azure. Если имя развертывания CMG уникально, а учетная запись хранения — нет, Configuration Manager не удается подготовить службу в Azure. Повторите описанный выше процесс в портал Azure со следующими изменениями:

Выполните поиск по запросу Учетная запись хранения.
Проверьте свое имя в поле Имя учетной записи хранения .

Важно!

Префикс DNS-имени должен содержать от 3 до 24 символов и содержать только цифры и строчные буквы. Не используйте специальные символы, такие как тире (). Например: .

Настройка центра сертификации

1. В «Диспетчере серверов (Server manager)» — выбираем «Служба сертификации Active Directory (AD CS) – правой клавишей по вашему серверу и открываем: «Центр сертификации (Certification Authority).

1.1. Вы попали в оснастку управления центром сертификации: certsrv.

1.2. Выбираем ваш центр сертификации и открываем свойства (рис. 10):

Рисунок 10. Настройка центра сертификации. Оснастка управления центром сертификации certsrv.

1.3. Следующим важным шагом выступает настройка точек распространения CDP и AIA.

Authority Information Access (AIA) — содержит ссылки на корневой сертификат центра сертификации (Certification Authority)

CRL Distribution Point — содержит ссылки на файлы CRL, которые периодически публикует сервер CA, который издал рассматриваемый сертификат. Этот файл содержит серийные номера и прочую информацию о сертификатах, которые были отозваны. (рис. 11)

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

1.4. В разделе свойства переходим в «Расширения (Extensions):

Удаляем ненужные точки распространения и оставляем локальную и внешнюю ссылку для CDP:

Ставим галочки «Включить в CRL. Включить в CDP (Include in CRL. Include in the CDP)».

AIA:

Ставим галочку: «Включать в AIA- расширение выданных сертификатов (Include in the AIA extension of issued certificates)»

OCSP:

Ставим галочку: «Включать в расширение протокола OCSP (Include in the online certificate status protocol (OCSP) extension)»

Рисунок 11. Настройка точек распространения AIA и CRL

В свойствах центра сертификации можно настроить автоматический выпуск сертификатов при поступившем запросе. Так вы исключаете возможность проверки указанных требуемых полей сертификатов. Для этого перейдите в «Модуль политик (Policy Module)» — «Свойства (Properties)» и выберите соответствующий пункт:

В первом случае сертификату присваивается режим ожидания, а одобрение выпуска сертификата остается за администратором;

Во втором случае из-за отсутствия шаблонов в Standalone CA сертификаты будут выпускаться автоматически. (рис. 12)

Рисунок 12. Дополнительные настройки ЦС для автоматического выпуска сертификатов

Да, центр сертификации уже функционирует и доступен по указанному dns-имени. Не забудьте открыть 80 и 443 порты для функционирования веб-сервера и online-reposnder’a, настройкой которого мы займёмся далее.

Проверить работу ЦС вы можете, перейдя в ChromiumGost или Internet Explorer или Edge (с поддержкой Internet Explorer(IE)): https://localhost/CertSrv.

Рисунок 13. Веб-интерфейс центра сертификации. Формирование запроса. Правильное отображение

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

Вернёмся в оснастку certsrv к нашему центру сертификации и настроим выпуск разностных CRL. Для этого необходимо открыть «Свойства (Properties)» раздела «отозванных сертификатов (Revoked Certificates)» (рис. 14).

1. Задаём «Интервал публикации CRL (CRL Publications interval)».

1.1. Включаем публикацию разностных CRL и задаём интервал.

Кажется, что все хорошо. Но есть один момент:

«ЦС будет публиковать Delta CRL, которые содержат символ плюс «+» в имени файла (например, contoso-pica+.crl). По умолчанию IIS будет расценивать этот символ в запросе как метасимвол и не позволит клиентам скачать список отзыва. Необходимо включить двойной эскейпинг в настройках IIS, чтобы расценивать знак плюса в запросе как литерал:»

Выполните следующую команду в power shell:

Рисунок 14. Настройка параметров публикации CRL.

Общие положения

X.509

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

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

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

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

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

ЦС политик – технически, это такой же ЦС, как и все остальные (в разрезе иерархии), с тем отличием, что дополняется внешними политиками и ограничениями по выдаче и использования цифровых сертификатов.

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

Certificate Chaining Engine — how it works

Свойства самозаверяющих сертификатов по умолчанию

Наиболее интересные свойства самозаверяющих сертификатов по умолчанию, которые отображаются в Центре администрирования Exchange и/или командной консоли Exchange на сервере Exchange, описаны в таблице ниже.

Свойство	Microsoft Exchange	Сертификат проверки подлинности Microsoft Exchange Server	WMSVC
Тема	(например, )		(например, )
Альтернативные имена субъектов (домены сертификатов)	<ServerName> (например, Mailbox01) <ServerFQDN> (например, Mailbox01.contoso.com)	none	(например, )
Имеет закрытый ключ (HasPrivateKey)	Да (True)	Да (True)	Да (True)
PrivateKeyExportable*	Неверно	Да	Да
EnhancedKeyUsageList*	Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)	Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)	Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)
Службы IIS*	(например, )	none	none
IsSelfSigned	Да	Да	Да
Издатель	(например, )		(например, )
NotBefore	Дата и время установки Exchange.	Дата и время установки Exchange.	Даты и время установки службы веб-управления IIS.
Срок действия истекает (NotAfter)	Через 5 лет после .	Через 5 лет после .	Через 10 лет после .
Размер открытого ключа (PublicKeySize)	2048	2048	2048
RootCAType	Системный реестр	Нет	Реестр
Службы	IMAP, POP, IIS, SMTP	SMTP	Нет

* Эти свойства не отображаются в стандартном представлении командной консоли Exchange. Чтобы просмотреть их, необходимо указать имя свойства (точное или с использованием подстановочных знаков) с помощью командлетов Format-Table или Format-List. Например:

Дополнительные сведения см. в разделе Get-ExchangeCertificate.

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

Свойство	Microsoft Exchange	Сертификат проверки подлинности Microsoft Exchange Server	WMSVC
Алгоритм подписи	sha256RSA1	sha256RSA1	sha256RSA1
Хэш-алгоритм подписи	sha2561	sha2561	sha2561
Использование ключа	Цифровая подпись, шифрование ключа (a0)	Цифровая подпись, шифрование ключа (a0)	Цифровая подпись, шифрование ключа (a0), шифрование данных (b0 00 00 00)
Основные ограничения			н/д
Алгоритм отпечатка	sha2561	sha2561	sha2561

1 Применяется к новым установкам Exchange 2016 с накопительным обновлением 22 или более поздней версии и Накопительным пакетом обновления 11 для Exchange 2019 или более поздней версии. Дополнительные сведения см. в разделе Exchange Server сертификатов 2019 и 2016, созданных во время установки, используют хэш SHA-1.

Установка издающих центра сертификации

После установки Центра сертификации (из стостава AD CS) необходимо её настроить.

ЦС предприятия
Подчиненный ЦС
Создать новый закрытый ключ
RSA#Microsoft Software Key Storage Provider; длину ключа в 2048 бит и алгоритм подписи в SHA1
Имя ЦС: TEST-CA
Создать запрос сертификата в файле на конечном компьютере
Период действия сертификата = 10 лет
Период публикации отозванных сертификатов = 3 месяца

Скопировать файл запроса на сервер RootCA и выпустить по немуц сертификат

открыть Панель управления-Администрирование-Центр сетрификации
выбрать сервер-все задачи-Выдать новый запрос… и выбрать файл запроса
перейти в подраздел запросы в ожидании
выбелить запрос, затем все задачи — выдать
перейти в подраздел выданные сертификаты и открыть сетрификат
на вкладке Состав нажать копировать в файл и сохратить в формате .p7b (TEST-CA.p7b)

Скопировать файл выданного сертификата (TEST-CA.p7b) и файлы из папки C:\CertData (ROOT-TEST-CA.crt и ROOT-TEST-CA.crl) в сетевое хранилище \\test.local\SOFT\PKI

После этого сервер RootCA можно выключить.

Зарегистрировать файлы с корневого ЦС на подчинённом сервере (запускать с привилегиями Администратора)

Если ошибок не возникло, то установить сертификат ЦС (выданный RootCA)

открыть Панель управления-Администрирование-Центр сетрификации
выбрать сервер-все задачи-Установить сертификат ЦС и выбрать файл (TEST-CA.p7b)
после успешной установки файл .p7b можно удалить

Выполнить пакетный файл настройки для дальнейшей настройки

Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов.

Для Windows 2008 строка будет с двумя знаками %% для переменных certutil -setreg CA\CRLPublicationURLs «65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:\\test.local\SOFT\PKI\%%3%%8%%9.crl\n6:http://pki.test.local/%%3%%8%%9.crl» и также для certutil -setreg CA\CACertPublicationURLs «1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://pki.test.local/%%3%%4.crt Поскольку мы не можем управлять публикацией CRT файлов, мы его переименовываем в нужное имя и копируем в папку CertData

задаём максимальный срок действия издаваемых сертификатов равным 5 лет

Задаём параметры публикации CRL (повторяем, что было указано в CAPolicy.inf)

Включаем наследование Issuer Statement в издаваемых сертификатах

Включаем полный аудит для сервера CA

задаём контекст конфигурации для сервера CA. Контекст конфигурации должен указывать на *корневой домен* текущего леса.

публикуем сертификат CA в AD

Публикуем новый CRL в новую локацию.

Проверка отзыва сертификатов

Некоторые сетевые службы (удаленные рабочие столы, DirectAccess, L2TP и SSTP VPN), которые используют сертификаты для проверки подлинности сервера, требуют проверки этих сертификатов на легитимность (но отозваны ли они центром сертификации). В окружении локальной сети с такими проверками проблем не возникает, так как списки отзыва сертификатов опубликованы в Active Directory и по локальным адресам центра сертификации.

Ситуация меняется, если легитимность сертификата пытаются проверить из интернета, где, естественно, ни Active Directory, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:

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

A revocation check could not be perfomed for the certificate.

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

CRL (Certificate Revocation List, список отзыва сертификатов) на веб-сервере, регулярно обновляемый
Online Responder (сетевой ответчик, доступный начиная с Windows Server 2008 редакции Enterprise), который функционирует примерно также, как и предыдущий вариант, но по более прогрессивному протоколу OCSP (но через HTTP)

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

За инструкциями по настройки ЦС для размещения CRL в интернете обращайтесь к статье TechNet Configuring Certificate Revocation. От себя лишь замечу хитрость: если ваш домен имеет доступное из интернета DNS-имя (то есть argon.com.ru, а не argon.local), а на сервер с корневым ЦС установлена опция Web Enrollment, то ЦС уже настроен на публикацию своих CRL по адресу http://server.argon.com.ru/CertEnroll. Поэтому для полноценной работы CRL достаточно просто опубликовать в интернете порт HTTP по доменному имени server.argon.com.ru.

Настройка и публикация Online Responder немного сложнее, но подробно описана в статьях TechNet Online Responder и Setting Up Online Responder Services in a Network. Тут уже никаких хитростей и настроек по умолчанию нет, честно устанавливаете роль на нужный сервер, конфигурируете эту роль, публикуете HTTP-сайт в интернете и настраиваете ЦС на включение информации об Online Responder’e в публикуемые сертификаты.

Проверить правильность функционирования проверки отзыва (CRL или OCSP) любого сертификата можно с помощью следующей команды:

certutil -url name.cer

где name.cer — имя выданного сертификата.

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

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

Если сертификат используется в течение допустимого периода времени, и потребитель сертификата доверяет выдающем ЦС, то перед использованием сертификата необходимо проверить еще один элемент: список отзыва сертификатов (CRL). Потребитель сертификата проверяет список отзыва сертификатов ЦС (путь к которому входит в сертификат в качестве расширения), чтобы убедиться, что сертификат отсутствует в списке отозванных сертификатов. Списки отзыва сертификатов существуют, так как существуют случаи, когда срок действия сертификата не истек, но он больше не может быть доверенным. Периодически ЦС публикует обновленный список отзыва сертификатов. Потребители сертификатов отвечают за сравнение сертификатов с текущим списком отзыва сертификатов перед рассмотрением сертификата, заслуживающего доверия.

Метод 1. Импорт сертификата с помощью средства работоспособности PKI

PKI Health Tool (PKIView) — это компонент оснастки MMC. Он отображает состояние одного или нескольких ЦС Microsoft Windows, составляющих PKI. Он доступен в составе средств комплекта ресурсов Windows Server 2003.

PKIView собирает сведения о сертификатах ЦС и списках отзыва сертификатов (CRL) из каждого ЦС на предприятии. Затем он проверяет сертификаты и списки отзыва сертификатов, чтобы убедиться, что они работают правильно. Если они работают неправильно или завершались сбоем, PKIView предоставляет подробное предупреждение или некоторые сведения об ошибке.

PKIView отображает состояние ЦС Windows Server 2003, установленных в лесу Active Directory. PKIView можно использовать для обнаружения всех компонентов PKI, включая подчиненные и корневые ЦС, связанные с ЦС предприятия. Средство также может управлять важными контейнерами PKI, такими как доверие корневого ЦС и хранилища NTAuth, которые также содержатся в разделе конфигурации леса Active Directory. В этой статье рассматриваются последние функции. Дополнительные сведения о PKIView см. в документации по инструментам Microsoft Windows Server 2003 Resource Kit Tools.

Примечание.

PKIView можно использовать для управления ЦС Windows 2000 и Центрами сертификации Windows Server 2003. Чтобы установить windows Server 2003 Resource Kit Tools, компьютер должен работать под управлением Windows XP или более поздней версии.

Чтобы импортировать сертификат ЦС в хранилище Enterprise NTAuth, выполните следующие действия.

Экспортируйте сертификат ЦС в CER-файл. Поддерживаются следующие форматы файлов:
- Двоичный файл X.509 в кодировке DER (CER)
- X.509 (CER) в кодировке Base-64
Установите средства комплекта ресурсов Windows Server 2003. Для пакета средств требуется Windows XP или более поздняя версия.
Запустите консоль управления Майкрософт (Mmc.exe), а затем добавьте оснастку «Работоспособность PKI»:
1. В меню консоли выберите » Добавить или удалить оснастку».
2. Выберите автономную вкладку и нажмите кнопку «Добавить «.
3. В списке оснастки выберите Enterprise PKI.
4. Нажмите кнопку «Добавить», а затем нажмите кнопку «Закрыть».
5. Нажмите кнопку ОК.
Щелкните правой кнопкой мыши корпоративную PKI, а затем выберите «Управление контейнерами AD».
Выберите вкладку NTAuthCertificates и нажмите кнопку «Добавить».
В меню Файл выберите Открыть.
Найдите и выберите сертификат ЦС, а затем нажмите кнопку «ОК «, чтобы завершить импорт.

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

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

Служба	Описание
IIS (HTTP)	По умолчанию следующие службы предлагаются на веб-сайте по умолчанию в службах клиентского доступа на сервере почтовых ящиков и используются клиентами для подключения к Exchange: Автообнаружение Exchange ActiveSync Центр администрирования Exchange веб-службы Exchange Распространение автономных адресных книг Мобильный Outlook (протокол RPC через HTTP) MAPI Outlook через HTTP Outlook в Интернете Удаленная оболочка PowerShell* Так как с веб-сайтом можно связать только один сертификат, все DNS-имена, используемые клиентами для подключения к этим службам, необходимо указать в сертификате. Для этого можно использовать сертификат SAN или групповой сертификат.
POP или IMAP	Сертификаты, используемые для POP или IMAP, могут отличаться от сертификата, используемого для IIS. Однако для упрощения администрирования рекомендуется также включить в сертификат IIS имена узлов, используемые для POP или IMAP, и использовать один сертификат для всех этих служб.
SMTP	SMTP-подключения от клиентов или серверов обмена сообщениями принимаются одним или несколькими соединителями получения, настроенными в транспортной службе переднего плана на сервере Exchange Server. Подробнее см. в разделе Соединители получения. Чтобы требовать шифрование TLS для SMTP-подключений, можно использовать отдельный сертификат для каждого соединителя получения. Сертификат должен включать DNS-имя, которое используется клиентами SMTP или серверами для подключения к соединителю получения. Чтобы упростить управление сертификатами, рекомендуется включить все DNS-имена, для которых требуется поддержка трафика TLS, в один сертификат. Сведения о необходимости взаимной проверки подлинности TLS, при которой SMTP-подключения между исходным и целевым серверами шифруются и проходят проверку подлинности, см. в разделе Безопасность домена.
Единая система обмена сообщениями	Дополнительные сведения см. в статье Deploying Certificates for UM. Примечание. UM недоступна в Exchange 2019.
Гибридное развертывание с помощью Microsoft 365 или Office 365	Дополнительные сведения см. в статье Certificate Requirements for Hybrid Deployments.
Secure/Multipurpose Internet Mail Extensions (S/MIME)	Дополнительные сведения см. в статье S/MIME для подписи и шифрования сообщений.

* Проверка подлинности Kerberos и шифрование Kerberos используются для удаленного доступа PowerShell из Центра администрирования Exchange и командной консоли Exchange. Поэтому не нужно настраивать сертификаты для использования с удаленной оболочкой PowerShell, если вы подключаетесь непосредственно к серверу Exchange (а не к пространству имен с балансировкой нагрузки). Чтобы использовать удаленный PowerShell для подключения к серверу Exchange Server с компьютера, который не является членом домена, или для подключения из Интернета, необходимо настроить сертификаты для использования с удаленной оболочкой PowerShell.

Использование CA Let’s Encrypt

Теперь запросим бесплатный сертификат из удостоверяющего центра Let’s Encrypt и разберём процесс организации HTTPS соединения между браузером и моим сайтом https://sushkov.ru. На схеме показана топология CA Let’s Encrypt и процесс получения сертификатов:

Корневой приватный ключ для корневого сертификата «ISRG Root X1» хранится offline, им подписываются intermediate сертификаты, в Let’s Encrypt их несколько. R3 — один из них.
С помощью intermediate ключей уже подписываются конечные (endpoint) сертификаты.

Предусловия для работоспособности сценария:

0. Корневой сертификат Let’s Encrypt должен быть помещен в браузер в список «Trusted Root Certification Authorities». Это мы уже уже видели.

1. Первым шагом владелец сайта запускает утилиту certbot, которая взаимодействует с его сайтом и CA Let’s Encrypt.

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

3. Certbot проверяет наличие файлов.

4. Certbot генерирует приватный ключ, публичный ключ и запрос на сертификат (CSR) и отправляет его на подпись CA Let’s Encrypt.

5. CA подписывает сертификат своим приватным ключом и возвращает в сertbot.

6. После этого владелец помещает сертификат и приватный ключ на сайт. Как конкретно это происходит зависит от платформы, на которой хостится сайт. Пример загрузки сертификата и приватного ключа у провайдера RU-CENTER:

7. Теперь при доступе из браузера к сайту https://sushkov.ru будет устанавливаться TLS соединение .

8. Обмен данными происходит по шифрованному каналу.

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

Тут же можно посмотреть на цепочку сертификатов:

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

Это вывод сайта компании DigiCert: