如何在 Office 365 上生成 CSR

最后更新于 19 8 月, 2026 由 Dionisie Gitlan

Reviewed by Sergiu Rosca, Software Engineer & SSL Expert

本指南将说明如何为 Microsoft 365 (Office 365) 生成 CSR (证书签名请求)。首先给出诚实的答案：您并不需要为 Microsoft 365 云平台本身生成 CSR。Microsoft 365 是一个托管的 SaaS 平台，因此 outlook.office365.com、*.mail.protection.outlook.com 邮件端点、*.sharepoint.com 以及其他 Microsoft 托管服务的 TLS 证书均由 Microsoft 拥有和管理。这些 URL 没有任何门户页面接受客户提供的证书。

只有当您同时运行一个与 Microsoft 365 集成的本地服务器或云托管服务器时，CSR 才会派上用场。CSR 是在该服务器上生成的，而不是在 Microsoft 365 管理门户中生成。以下各节涵盖了实际会用到 CSR 的场景。

您属于哪种场景？

请找出与您实际要保护的对象相匹配的那一行，然后跳转到相应的章节：

您要保护的对象	CSR 的生成位置	章节
Microsoft 365 云服务本身 (Exchange Online、SharePoint Online、Teams、outlook.office365.com)	无需生成。由 Microsoft 管理这些证书。	为什么云服务不需要 CSR
与 Exchange Online 混合部署的本地 Exchange Server	在本地 Exchange 服务器上 (PowerShell，或支持版本中的 EAC)	混合 Exchange CSR
与 Microsoft 365 / Entra ID 进行登录联合的 AD FS 服务器	在 AD FS 服务器上 (Windows 证书请求)	AD FS / Entra 联合 CSR
连接到 Microsoft 365 的 Azure App Service Web 应用、函数或 API	在外部生成 (任意工具)，然后上传至 Azure	Azure App Service CSR
非 Exchange 但与 Microsoft 365 集成的独立 Windows Web 服务器 (IIS)，例如门户、Webhook 接收器或中继服务	在该服务器的 IIS 管理器中	独立 IIS 服务器 CSR

为什么 Microsoft 365 云不需要 CSR

Microsoft 365 是一个完全托管的多租户云平台。Exchange Online、SharePoint Online、OneDrive for Business、Microsoft Teams 以及其他每一个 Microsoft 托管端点的 TLS 证书均由 Microsoft 签发、部署和续期。没有任何管理中心页面、PowerShell cmdlet 或 API 可以让租户为 outlook.office365.com、*.mail.protection.outlook.com 邮件流端点或任何其他 Microsoft 拥有的主机名上传第三方证书。即使您添加了自己的自定义域名（例如 contoso.com），情况也是如此：一旦该域名通过验证，Microsoft 仍会为底层的 SMTP、IMAP、POP 和 HTTPS 端点终结 TLS，因此您这边不需要 CSR。

如果您的目标是在 Microsoft 365 与外部合作伙伴之间的邮件流上强制启用 TLS，可以通过要求合作伙伴出示有效公共证书的 Exchange Online 连接器来实现，而不需要在您这边上传任何证书。相关连接器设置步骤请参阅我们的Microsoft 365 SSL 安装指南。

为混合 Exchange (本地 Exchange Server) 生成 CSR

如果您已经在本地 Exchange 服务器上生成了 CSR，可以直接跳到 Microsoft 365 / Exchange SSL 安装指南。否则，这正是客户最常询问 “Microsoft 365 CSR” 的原因。在混合部署中，您的本地 Exchange Server (2016、2019 或 Subscription Edition) 通过 OAuth、EWS 和 Autodiscover 与 Exchange Online 通信，这些连接必须使用受公众信任的证书进行保护。您需要在本地 Exchange 服务器上生成 CSR，而不是在 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"

在当前版本上必须使用这种两步操作方式（将 cmdlet 输出通过管道传给 Set-Content）：安全更新 KB5014278 已从 Exchange 2016 CU23 和 Exchange 2019 CU12 的 New-ExchangeCertificate 中移除了旧版的 -RequestFile 参数。请编辑以下值以匹配您的环境：

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 文档中 -KeySize 仅支持 1024、2048 和 4096 这三个有效值，因此这里不要使用 3072。
-PrivateKeyExportable $true 让您以后可以导出密钥用于备份，或与 DAG 中的其他节点共享。

在 Exchange Server Subscription Edition 和 Exchange 2019 CU15 上，位于 Servers > Certificates 的 EAC 证书向导再次可用，可作为图形界面操作的备选方案。完整的分步说明 (PowerShell 加上 EAC 向导，并附有各版本差异说明) 请参阅我们的配套文章 Microsoft Exchange CSR 指南。请使用该页面获取标准的混合 Exchange CSR 流程；同一个 CSR 也适用于您将分配给本地 Exchange 服务（用于连接 Microsoft 365）的证书。

运行 cmdlet 之后，用记事本打开 .req 文件，确认其内容看起来像一个正常的 PEM 数据块：

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

复制整个数据块，包括 BEGIN 和 END 那两行（每侧五个连字符），并将其粘贴到您 SSL 订单的 CSR 字段中。在提交之前，先使用我们的CSR 解码器解码，确认通用名称、SAN 和密钥长度是否正确。

为 AD FS / Entra ID 与 Microsoft 365 的联合生成 CSR

如果您使用 AD FS (Active Directory Federation Services) 在本地 Active Directory 与 Microsoft Entra ID (前身为 Azure AD) 之间联合登录以实现 Microsoft 365 单点登录，AD FS 服务需要为其联合服务名称（例如 sts.example.com）配备受公众信任的 TLS 证书。该证书会绑定到 AD FS 服务，以及位于其前端的可选 Web 应用程序代理。

CSR 是在 AD FS 服务器（或任何 Windows 服务器）上使用 Microsoft 管理控制台证书管理单元或 PowerShell 生成的，然后提交给公共 CA。您可以使用我们的CSR 生成器生成 CSR（之后再将签发的证书和密钥合并为 .pfx 文件），或者按照我们的Windows CSR 指南直接在服务器上生成请求。然后使用 Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumb> 将同一证书分配给 AD FS 服务。

AD FS 内部的令牌签名证书和令牌解密证书是另一个话题。它们通常是自签名的，并由 AD FS 自身自动轮换，因此您不需要为它们生成 CSR。

为与 Microsoft 365 集成的 Azure App Service 生成 CSR

如果您在 Azure App Service 上托管一个连接到 Microsoft 365 的 Web 应用、函数或 API（例如自定义门户、SSO 端点、Webhook 接收器），则需要通过上传到 Azure 的证书来保护其自定义域名。Azure App Service 本身不生成 CSR：您需要在 Azure 之外生成请求，然后上传得到的 .pfx 文件。

最简单的方法是使用我们的CSR 生成器：输入您的详细信息，下载 CSR 及匹配的私钥，将 CSR 提交给 CA，然后将签发的证书、中间证书和私钥合并为一个 .pfx 文件 (PKCS#12)。将该 .pfx 文件上传至 App Service > Certificates > Bring your own certificates (.pfx)，并将其绑定到您的自定义域名。如果您更倾向于完全由服务器端管理的流程，可以在 Windows 管理工作站上按照我们的Windows CSR 指南生成 CSR，并在上传前将结果导出为 .pfx 文件。Azure 要求证书包含扩展密钥用法 服务器身份验证 (OID 1.3.6.1.5.5.7.3.1)，而每一个商业 SSL 证书都已经具备这一属性。

在独立的 Windows / IIS 服务器上生成 CSR

如果您所说的 “Office 365” 实际上是指 “与 Microsoft 365 处于同一环境中、运行 IIS 的 Windows 服务器”（例如门户网站、内部网站点，或非 Exchange 的中继服务），那么您需要在该服务器的 IIS 管理器中生成 CSR。这正是原始教程所描述的流程。这对于通用的 IIS 主机来说是正确的操作方式，但它生成的证书并非用于 Microsoft 365 云服务，而只适用于您所管理的 IIS 托管站点。

打开开始 > Windows 管理工具 > Internet Information Services (IIS) 管理器，或按 Win + R 组合键，输入 inetmgr，然后按回车键。
在左侧的连接面板中，选择您的服务器名称。
在中间窗格中，双击服务器证书。
在右侧的操作面板中，点击创建证书请求。
在请求证书向导中，按如下方式填写可分辨名称属性字段：
- 通用名称：您要保护的完全限定域名，例如 portal.example.com。不要输入 outlook.office365.com 或任何 Microsoft 拥有的主机名。
- 组织：贵公司的完整法定名称（例如 Example Inc.）。
- 组织单位：部门名称，通常为 IT。
- 城市/地区：贵公司注册所在的城市（不要缩写）。
- 省/州：省或州的全称（不要缩写）。
- 国家/地区：两位字母的 ISO 国家代码 (US、GB、DE 等)。
点击下一步。
在加密服务提供程序属性屏幕上，保留提供程序为 Microsoft RSA SChannel Cryptographic Provider，将位长度设置为 2048（如果您的策略要求，可设为 3072 / 4096），然后点击下一步。
为 CSR 指定一个文件名（例如 C:certsportal.req），然后点击完成。

IIS 不会通过此向导生成使用者备用名称。若要申请 SAN 证书或多域证书，可使用带有自定义 INF 文件的 certreq 通过 PowerShell 生成 CSR，或使用我们的CSR 生成器，之后再将签发的证书和密钥合并为 .pfx 文件以便导入。有关完整的 IIS 专属流程及配图说明，请参阅我们的Microsoft IIS CSR 指南。

用记事本打开保存的 .req 文件，将包括 -----BEGIN NEW CERTIFICATE REQUEST----- 和 -----END NEW CERTIFICATE REQUEST----- 在内的完整数据块复制到您 CA 的订单表单中。