Как сгенерировать CSR в Office 365

В этом руководстве объясняется, как сгенерировать CSR (запрос на подпись сертификата) для Microsoft 365 (Office 365). Честный ответ сразу: вы не генерируете CSR для самого облака Microsoft 365. Microsoft 365 — это размещённая SaaS-платформа, поэтому Microsoft владеет и управляет TLS-сертификатами на outlook.office365.com, почтовых конечных точках *.mail.protection.outlook.com, *.sharepoint.com и других сервисах, размещённых Microsoft. Не существует страницы портала, которая принимала бы предоставленный клиентом сертификат для этих URL.

CSR требуется только в том случае, если вы также используете локальный или облачный сервер, который интегрируется с Microsoft 365. CSR генерируется на этом сервере, а не в административном портале Microsoft 365. В разделах ниже рассматриваются сценарии, в которых это действительно происходит.

В каком сценарии вы находитесь?

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

Что вы пытаетесь защитить	Где генерируется CSR	Раздел
Сами облачные сервисы Microsoft 365 (Exchange Online, SharePoint Online, Teams, outlook.office365.com)	Нигде. Microsoft управляет этими сертификатами.	Почему для облака нет CSR
Локальный сервер Exchange в гибридной конфигурации с Exchange Online	На локальном сервере Exchange (PowerShell или EAC на поддерживаемых сборках)	CSR для гибридного Exchange
Сервер AD FS, обеспечивающий федеративный вход в Microsoft 365 / Entra ID	На сервере AD FS (запрос сертификата Windows)	CSR для федерации AD FS / Entra
Веб-приложение, функция или API Azure App Service, подключающиеся к Microsoft 365	Генерируется внешне (любым инструментом), затем загружается в Azure	CSR для Azure App Service
Автономный веб-сервер Windows (IIS), не являющийся Exchange, но интегрирующийся с Microsoft 365 (например, портал, приёмник вебхуков или ретранслятор)	В IIS Manager на этом сервере	CSR для автономного сервера IIS

Почему для облака Microsoft 365 нет CSR

Microsoft 365 — это полностью размещённая многопользовательская облачная платформа. TLS-сертификаты для Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams и всех остальных конечных точек, размещённых Microsoft, выпускаются, развёртываются и продлеваются самой Microsoft. Не существует ни страницы административного центра, ни командлета PowerShell, ни API, которые позволили бы арендатору загрузить стороннний сертификат на outlook.office365.com, конечные точки потока почты *.mail.protection.outlook.com или любое другое имя хоста, принадлежащее Microsoft. Это касается и случая, когда вы добавили собственный «красивый» домен, например contoso.com: после того как домен подтверждён, Microsoft по-прежнему завершает TLS-соединения для базовых конечных точек SMTP, IMAP, POP и HTTPS, поэтому CSR с вашей стороны не требуется.

Если ваша цель — принудительно применять TLS при потоке почты между Microsoft 365 и внешним партнёром, вы делаете это с помощью коннектора Exchange Online, который требует, чтобы партнёр предъявил действительный публичный сертификат. Никакой сертификат с вашей стороны не загружается. Ознакомьтесь с нашим руководством по установке SSL для Microsoft 365, чтобы узнать шаги настройки коннектора.

Генерация CSR для гибридного Exchange (локальный Exchange Server)

Если вы уже сгенерировали CSR на своём локальном сервере Exchange, переходите сразу к руководству по установке SSL для Microsoft 365 / Exchange. В противном случае это самая распространённая причина, по которой клиенты просят «CSR для Microsoft 365». В гибридном развёртывании ваш локальный Exchange Server (2016, 2019 или Subscription Edition) взаимодействует с Exchange Online через OAuth, EWS и Autodiscover, и эти соединения должны быть защищены публично доверенным сертификатом. CSR генерируется на локальном сервере Exchange, а не где-либо в Microsoft 365.

На каждой поддерживаемой сборке Exchange (и как единственный поддерживаемый способ на Exchange 2016 CU23+ и Exchange 2019 CU12-CU14, где Microsoft удалила опции сертификатов из EAC) CSR генерируется с помощью PowerShell. Запустите Exchange Management Shell от имени администратора на сервере, который будет хранить закрытый ключ, затем выполните:

New-ExchangeCertificate `
  -GenerateRequest `
  -SubjectName "C=US, S=California, L=San Francisco, O=Example Inc, OU=IT, CN=mail.example.com" `
  -DomainName mail.example.com, autodiscover.example.com `
  -KeySize 2048 `
  -PrivateKeyExportable $true `
  | Set-Content -Path "C:certsexchange.req"

Двухшаговое использование (вывод командлета передаётся в Set-Content) требуется на текущих сборках: обновление безопасности KB5014278 удалило старый параметр -RequestFile из New-ExchangeCertificate на Exchange 2016 CU23 и Exchange 2019 CU12. Отредактируйте значения в соответствии с вашей средой:

• C — это двухбуквенный код страны (US, GB, DE и так далее).
• S — это полное название штата или региона, а не аббревиатура.
• L — это полное название города или населённого пункта.
• O — это юридически зарегистрированное название компании.
• OU — это отдел, часто «IT». Необязательно.
• CN — это основное полное доменное имя, которое будет защищать сертификат, например mail.example.com.
• -DomainName — это список альтернативных имён субъекта (SAN), разделённых запятыми. Для гибридного развёртывания включите как минимум mail.example.com и autodiscover.example.com, а также любые дополнительные пространства имён, которые вы используете (OWA, EWS, гибридные имена хостов).
• -KeySize 2048 соответствует базовым требованиям CA/Browser Forum. Используйте 4096 только если это требует ваша политика безопасности. Microsoft документирует только 1024, 2048 и 4096 в качестве допустимых значений для -KeySize, поэтому не используйте здесь 3072.
• -PrivateKeyExportable $true позволяет позже экспортировать ключ для резервного копирования или для передачи другим узлам в DAG.

В Exchange Server Subscription Edition и Exchange 2019 CU15 мастер сертификатов EAC в разделе Servers > Certificates снова доступен как альтернативный поток графического интерфейса. Полное пошаговое руководство (PowerShell плюс мастер EAC с примечаниями по версиям) находится на нашей сопутствующей странице руководства по CSR для Microsoft Exchange. Используйте эту страницу для канонического процесса создания CSR для гибридного Exchange; тот же CSR подходит для сертификата, который вы назначите локальным службам Exchange, подключающимся к Microsoft 365.

После выполнения командлета откройте файл .req в Блокноте и убедитесь, что он выглядит как обычный блок PEM:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIC6TCCAdECAQAwgaMxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
...
-----END NEW CERTIFICATE REQUEST-----

Скопируйте весь блок, включая строки BEGIN и END (по пять дефисов с каждой стороны), и вставьте его в поле CSR вашего заказа SSL. Сначала декодируйте его с помощью нашего Декодера CSR, чтобы подтвердить общее имя, SAN и размер ключа, прежде чем отправлять запрос.

Генерация CSR для федерации AD FS / Entra ID с Microsoft 365

Если вы используете AD FS (Active Directory Federation Services) для федеративного входа между вашим локальным Active Directory и Microsoft Entra ID (ранее Azure AD) для единого входа в Microsoft 365, службе AD FS необходим публично доверенный TLS-сертификат для имени службы федерации (например, sts.example.com). Этот сертификат привязывается к службе AD FS и к необязательному Web Application Proxy перед ней.

CSR генерируется на сервере AD FS (или любом сервере Windows) с помощью оснастки сертификатов Microsoft Management Console или PowerShell, а затем отправляется в публичный CA. Либо сгенерируйте CSR с помощью нашего Генератора CSR (а затем объедините выпущенный сертификат и ключ в файл .pfx), либо следуйте нашему руководству по CSR для Windows, чтобы сформировать запрос непосредственно на сервере. Затем тот же сертификат назначается службе AD FS с помощью команды Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumb>.

Сертификаты подписи токенов и расшифровки токенов внутри AD FS — отдельная тема. Обычно они самоподписаны и автоматически обновляются самой AD FS, поэтому CSR для них генерировать не нужно.

Генерация CSR для Azure App Service, интегрируемого с Microsoft 365

Если вы размещаете веб-приложение, функцию или API на Azure App Service, которое подключается к Microsoft 365 (пользовательский портал, конечная точка SSO, приёмник вебхуков), вы защищаете его пользовательский домен сертификатом, который загружаете в Azure. Azure App Service сам не генерирует CSR: вы генерируете запрос вне Azure и загружаете полученный файл .pfx.

Самый простой путь — наш Генератор CSR: введите свои данные, скачайте CSR и соответствующий закрытый ключ, отправьте CSR в CA, затем объедините выпущенный сертификат, промежуточные сертификаты и закрытый ключ в файл .pfx (PKCS#12). Загрузите этот .pfx в разделе App Service > Certificates > Bring your own certificates (.pfx) и привяжите его к своему пользовательскому домену. Если вы предпочитаете полностью серверный процесс, сгенерируйте CSR на рабочей станции администратора Windows с помощью нашего руководства по CSR для Windows и экспортируйте результат в .pfx перед загрузкой. Azure требует, чтобы сертификат включал расширенное использование ключа Server Authentication (OID 1.3.6.1.5.5.7.3.1), что уже присутствует в любом коммерческом SSL-сертификате.

Генерация CSR на автономном сервере Windows / IIS

Если под «Office 365» в вашем случае на самом деле подразумевается «сервер Windows с IIS в той же среде, что и Microsoft 365» (например, портал, интранет-сайт или ретранслятор, не связанный с Exchange), тогда вы генерируете CSR в IIS Manager на этом сервере. Это путь, описанный в оригинальном руководстве. Это правильный процесс для обычного хоста IIS, но он не создаёт сертификат для облака Microsoft 365, только для того сайта на IIS, которым вы управляете.

1. Откройте Пуск > Средства администрирования Windows > Диспетчер служб IIS (Internet Information Services), либо нажмите Win + R, введите inetmgr и нажмите Enter.
2. На панели Connections слева выберите имя вашего сервера.
3. В центральной панели дважды щёлкните Server Certificates.
4. На панели Actions справа нажмите Create Certificate Request.
5. В мастере Request Certificate заполните поля Distinguished Name Properties следующим образом:
   • Common Name: полное доменное имя, которое вы хотите защитить, например portal.example.com. Не вводите outlook.office365.com или любое другое имя хоста, принадлежащее Microsoft.
   • Organization: полное юридическое название вашей компании (например, Example Inc.).
   • Organizational unit: отдел, часто IT.
   • City/locality: город, где зарегистрирована ваша компания (не сокращайте).
   • State/province: полное название штата или региона (не сокращайте).
   • Country/region: двухбуквенный код страны по ISO (US, GB, DE и так далее).
6. Нажмите Next.
7. На экране Cryptographic Service Provider Properties оставьте провайдера Microsoft RSA SChannel Cryptographic Provider, установите Bit length равным 2048 (или 3072 / 4096, если этого требует ваша политика), затем нажмите Next.
8. Укажите имя файла для CSR (например, C:certsportal.req) и нажмите Finish.

IIS не генерирует альтернативные имена субъекта через этот мастер. Для сертификата с SAN или несколькими доменами сгенерируйте CSR с помощью PowerShell, используя пользовательский INF-файл с certreq, либо воспользуйтесь нашим Генератором CSR и позже объедините выпущенный сертификат и ключ в файл .pfx для импорта. Полный процесс для IIS со скриншотами смотрите в нашем руководстве по CSR для Microsoft IIS.

Откройте сохранённый файл .req в Блокноте и скопируйте весь блок, включая строки -----BEGIN NEW CERTIFICATE REQUEST----- и -----END NEW CERTIFICATE REQUEST-----, в форму заказа вашего CA.

Проверьте CSR перед отправкой

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

После того как CA проверит запрос и выпустит сертификат, переходите к нашему руководству по установке SSL для Microsoft 365 для выполнения соответствующего шага установки (импорт для гибридного Exchange, привязка AD FS, загрузка в Azure App Service или привязка в IIS).