bg-tutorials

如何在 Skype for Business Server 上生成 CSR

本指南将向您展示如何在 Skype for Business Server 上生成 CSR(证书签名请求)。您可以通过两种方式创建该请求:使用 Skype for Business Server 部署向导中的图形化证书向导,或者在 Skype for Business Server 管理外壳中使用 Request-CsCertificate cmdlet。这两种方式都会从您已发布的拓扑中读取证书所需的名称,这也是它们比通用 CSR 工具更可靠的原因。

以下步骤适用于本地部署的 Skype for Business Server:2015、2019 及订阅版。它们不适用于已于 2021 年 7 月 31 日停用的 Skype for Business Online,也不适用于已于 2025 年 5 月 5 日停用的消费版 Skype。如果您的组织已迁移至 Microsoft Teams,则该服务的证书由 Microsoft 负责管理,无需生成 CSR。

首先检查您的 Skype for Business Server 版本

打开 Skype for Business Server 管理外壳,列出所有已安装组件的版本号:

Get-CsServerPatchVersion

相关的 Get-CsServerVersion cmdlet 仅报告本地服务器的许可信息和基础版本号,不包括累积更新,因此当您需要确切了解当前所处的更新级别时,请使用 Get-CsServerPatchVersion。

截至 2026 年 7 月的支持状态:

  • Skype for Business Server 2015 和 2019 均已于2025 年 10 月 14 日结束延长支持。
  • 付费的扩展安全更新计划从 2025 年 10 月运行至 2026 年 4 月底(第一阶段)。第二个窗口期,即第二阶段,从 2026 年 5 月运行至 2026 年 10 月底。第二阶段需要单独购买:购买第一阶段并不会自动延续到第二阶段,反之,购买第二阶段也无需先购买第一阶段。
  • Microsoft 于 2026 年 7 月 21 日重申不会再有进一步延期。一旦 2026 年 10 月结束,2015 或 2019 版本将不再获得任何更新,即使是持有第二阶段 ESU 的组织也不例外。
  • Skype for Business Server 订阅版自 2025 年 7 月 1 日推出以来,遵循 Microsoft 现代生命周期政策,是当前的本地部署版本。它以 Skype for Business Server 2019 的原地升级方式安装。

CSR 流程在这三个版本上是完全相同的。支持状态并不会改变证书的行为:无论运行哪个版本,过期的证书都会导致客户端登录失败、会议加入失败以及服务器间 TLS 通信中断,因此在规划迁移的同时,请继续保持证书续期。

生成 CSR 之前的准备工作

  • 先发布您的拓扑。 上述两种方式都会从拓扑生成器发布到中央管理存储的拓扑文档中读取使用者名称和使用者备用名称。向导会在一个只读摘要页面上显示这些信息。如果其中某个名称有误,请取消向导,在拓扑生成器中进行更正,重新发布,然后再重新开始请求。
  • 先创建 DNS 记录。 最终出现在证书上的每个名称都需要能被使用它的客户端解析。
  • 检查您的权限。 要运行证书向导,您必须是 RTCUniversalServerAdmins 组的成员。Microsoft 表示,向公共 CA 提交离线请求除该组成员身份外无需其他权限,但后续处理 CA 的响应并分配证书还需要本地管理员组的权限。若要向内部 Windows CA 提交在线请求,则需要本地管理员权限,外加该 CA 所在域中经身份验证的域账户。
  • 确定您要请求的是哪种证书。 前端服务器或标准版服务器拥有一个默认证书,外加内部和外部 Web 服务证书。边缘服务器则拥有独立的外部证书和内部证书。它们不能相互替代使用。

哪些 Skype for Business 证书可以由公共 CA 签发?

并非全部都可以,而这正是大多数人容易忽略的关键点。自 2015 年 11 月起,CA/浏览器论坛基准要求已禁止受公共信任的 CA 为内部服务器名称和保留 IP 地址签发证书。任何以 .local 结尾的名称、任何单标签主机名,以及任何位于您不公开拥有的域内的 FQDN,都不能出现在公共证书上。

  • 来自公共 CA:外部边缘证书和反向代理证书。Microsoft 的指导意见是,外部边缘接口至少需要来自公共 CA 的证书,因为外部客户端和联合合作伙伴必须能够信任它。
  • 通常来自您的内部 CA:默认证书、内部 Web 服务证书、导演角色(Director)证书和内部边缘证书。这些证书携带的池和服务器 FQDN 通常是内部名称。如果您的内部 FQDN 恰好位于您公开拥有的域内,也可以为其购买公共证书。Microsoft 明确允许内部边缘证书既可来自公共 CA,也可来自您的内部 CA。

由于外部证书会同时携带多个名称,因此通常会使用多域(UCC/SAN)证书。Microsoft 的文档说明支持在简单 URL 名称和自动发现名称中使用通配符条目,但文档中记载的边缘证书示例是逐一明确列出每个 SIP 访问名称,因此建议为每个 SIP 域分别列出一个 sip.yourdomain.tld 条目,而不要依赖通配符。

规划使用者名称和 SAN 条目

Skype for Business 证书通常包含大量 SAN 条目,浏览器和客户端匹配的是 SAN 字段中的主机名,而非通用名称(Common Name)。在下单前把这份清单规划正确,是区别于事后重新签发证书的关键。下表使用 Microsoft 自己的示例域:contoso.com 作为主 SIP 域,fabrikam.com 作为第二个 SIP 域,contoso.net 作为内部域。

证书使用者名称(CN)使用者备用名称示例
默认(标准版或前端池)池 FQDN池 FQDN 和服务器 FQDN。如果该池是自动登录服务器,且组策略中强制执行严格的 DNS 匹配,则为每个 SIP 域添加 sip.sipdomain。SN=eepool.contoso.com; SAN=eepool.contoso.com; SAN=ee01.contoso.com
内部 Web池 FQDN(标准版为服务器 FQDN)内部 Web FQDN、服务器 FQDN、池 FQDN,每个 SIP 域的 Meet 简单 URL、Dial-in 简单 URL 和 Admin 简单 URLSN=eepool.contoso.com; SAN=eepool.contoso.com; SAN=ee01.contoso.com; SAN=meet.contoso.com; SAN=meet.fabrikam.com; SAN=dialin.contoso.com; SAN=admin.contoso.com
外部 Web池 FQDN(标准版为服务器 FQDN)外部 Web FQDN,每个 SIP 域的 Meet 简单 URL,以及 Dial-in 简单 URLSN=eepool.contoso.com; SAN=webcon01.contoso.com; SAN=meet.contoso.com; SAN=meet.fabrikam.com; SAN=dialin.contoso.com
移动功能(添加至前端和导演角色证书)同上内部自动发现名称和外部自动发现名称,每个 SIP 域各一对SAN=lyncdiscoverinternal.contoso.com; SAN=lyncdiscover.contoso.com
外部边缘主 SIP 域的 sip 名称每个 SIP 域一个 sip 条目,外加 Web 会议边缘 FQDNSN=sip.contoso.com; SAN=sip.contoso.com; SAN=webcon.contoso.com; SAN=sip.fabrikam.com
内部边缘边缘内部 FQDN无。内部边缘证书仅使用一个使用者名称。SN=sfbedge.contoso.net
反向代理外部 Web 服务 FQDN外部自动发现名称,加上您的外部 Web 服务 FQDNSAN=lyncdiscover.contoso.com; SAN=skypewebextpool01.contoso.com; SAN=dirwebexternal.contoso.com

提交前值得核查的四个细节:

  • 简单 URL。 每个 SIP 域需要一个 Meet 简单 URL,整个组织需要一个 Dial-in 简单 URL,Admin 简单 URL 为可选项。您使用的每个 Meet URL 都必须出现在证书中。
  • sipinternal 和 sipexternal。 如果您在 DNS 中创建了 sipinternal.contoso.com 或 sipexternal.contoso.com 记录,Microsoft 要求它们同样出现在 SAN 列表中。
  • A/V 名称不属于 SAN。 av.contoso.com 是 A/V 边缘服务的 DNS 记录,该服务并不使用证书来加密媒体流,因此不应出现在请求中。外部边缘证书会分配给接入边缘、Web 会议边缘以及独立的 A/V 身份验证服务。
  • 边缘池共享同一证书。 池中的每台边缘服务器都必须携带完全相同的证书和相同的私钥,以支持媒体中继身份验证服务,因此这是唯一一种确实需要可导出私钥的请求。

使用部署向导生成 CSR

如果您已经使用其他工具生成了 CSR,请跳过本节,转而参考我们的如何在 Skype for Business Server 上安装 SSL 证书指南。

请在证书对应的服务器上执行以下步骤:如果是默认证书或 Web 服务证书,则在前端服务器上执行;如果是边缘证书,则在边缘服务器上执行。

  1. 打开开始菜单,启动 Skype for Business Server 部署向导。
  2. 点击安装或更新 Skype for Business Server 系统。
  3. 在第 3 步:请求、安装或分配证书旁,点击运行。如果此计算机上已存在证书,该按钮会显示为再次运行。
  4. 在证书向导中,选择您需要的证书(例如默认证书,或在边缘服务器上选择外部边缘证书),然后点击请求。
  5. 选择现在准备请求,但稍后发送(离线证书请求)。这是面向公共 CA 的选项。另一个选项立即将请求发送至在线证书颁发机构,是向您自己 PKI 内部的 CA(通常是内部 Windows CA)注册,并不是通向公共 CA 的途径。
  6. 在文件名框中输入请求文件的路径和文件名,或点击浏览选择位置。请记下保存位置。默认路径是运行该向导的账户的“文档”文件夹。
  7. 在名称和安全设置页面上,输入一个在该计算机证书存储中唯一的友好名称,然后选择位长。列表中提供 1024、2048 和 4096 三个选项:请选择 2048,因为公共 CA 不会为 1024 位密钥签发证书。除非您是为边缘服务器池请求证书(Microsoft 明确指出这是唯一需要该选项的情况),否则请保持将证书的私钥标记为可导出选项为未勾选状态。
  8. 在组织信息页面上,填写组织和组织单位。组织单位在证书上是自由文本,不必与 Active Directory 中的组织单位相匹配。
  9. 在地理信息页面上选择国家/地区,然后输入州/省和城市/地区。两者都请完整拼写,例如使用 Arizona 而非 AZ。
  10. 查看使用者名称/使用者备用名称页面。这些条目来自您已发布的拓扑,此处无法编辑。如果其中某项有误,请点击取消,在拓扑生成器中进行更正,重新发布拓扑,然后重新开始请求。
  11. 在使用者备用名称(SAN)上的 SIP 域设置页面上,勾选您的主 SIP 域以及此证书需要覆盖的任何其他 SIP 域。如果您未勾选任何域,而后续配置发生变化,则必须重新请求新证书。
  12. 在配置其他使用者备用名称页面上,添加拓扑未提供的任何名称:输入 FQDN 并点击添加。删除和全部清除仅影响您在此页面添加的条目,不会影响来自拓扑的名称。
  13. 检查请求摘要,然后点击下一步以生成 CSR。在证书请求文件页面上,点击查看以在记事本中打开请求内容,方便您复制,然后点击完成。

使用 PowerShell 生成 CSR

以管理员身份打开 Skype for Business Server 管理外壳,运行 Request-CsCertificate。它生成的请求与向导相同:该 cmdlet 会在写入文件之前分析您的拓扑,并自动为您填写使用者名称和使用者备用名称。

一个完整的前端服务器离线请求示例如下。它是一整行命令,请完整复制:

Request-CsCertificate -New -Type Default,WebServicesInternal,WebServicesExternal -ComputerFqdn "ee01.contoso.com" -FriendlyName "SfB Front End 2026" -KeySize 2048 -Organization "Contoso Ltd" -OU "IT" -Country US -State "Arizona" -City "Phoenix" -DomainName "meet.contoso.com,dialin.contoso.com,admin.contoso.com,lyncdiscover.contoso.com" -Output "C:certscontoso_sfb.csr"

各部分的作用如下:

  • -New 启动一个新请求,这是该命令形式的必需参数。
  • -Type 是必需参数。它指定证书所覆盖的服务角色,这些角色决定了 cmdlet 会将哪些 FQDN 写入 SAN 字段。
  • -Output 会将离线请求写入您指定的路径。正是这个参数使该命令生成可提交给公共 CA 的 CSR。如果省略它并改用 -CA,cmdlet 会直接联系内部 Windows CA。
  • -ComputerFqdn 是证书所对应计算机的 FQDN。Microsoft 建议始终使用计算机名称,即使您请求的是池证书,因为 cmdlet 会自行将池名称添加到使用者中。
  • -DomainName 接受一个以逗号分隔的额外 FQDN 列表,用于在拓扑提供的名称基础上追加到 SAN 字段。
  • -Organization、-OU、-Country、-State 和 -City 用于填充使用者信息。国家/地区使用两字母代码(US、GB、DE);州/省和城市请完整拼写。
  • -KeySize 接受 1024、2048 和 4096。请使用 2048 或更大。
  • -FriendlyName 用于在 Windows 证书存储中标记该证书,且必须在该存储中唯一。
  • -PrivateKeyExportable $True 将密钥标记为可导出。只有在您确实需要将证书复制到另一台机器时才设置此项,例如下文的边缘池示例。
  • -AllSipDomain 会将每个 SIP 域都添加到 SAN 字段。如果不使用该参数,则只有主 SIP 域会被自动添加。
  • -Template 指定内部 CA 上的证书模板名称。对于公共 CA 的请求,该参数没有意义。

可传递给 -Type 的证书类型

Microsoft 文档记录了以下这些值,并指出该列表并非详尽无遗:AccessEdgeExternal、AudioVideoAuthentication、DataEdgeExternal、Default、External、Internal、iPhoneAPNService、iPadAPNService、MPNService、PICWebService、ProvisionService、WebServicesExternal、WebServicesInternal 和 WsFedTokenTransfer。多个类型之间用逗号分隔。

其中有两项对于本地部署的服务器已无实际意义:Microsoft 将 PICWebService 和 ProvisionService 列为 Skype for Business Online 的类型,而该服务已于 2021 年停用。实际使用中,您会用到以下三种组合之一:

  • 前端或导演角色: -Type Default,WebServicesInternal,WebServicesExternal
  • 边缘内部接口: -Type Internal
  • 边缘外部接口: -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication

外部边缘请求是需要可导出密钥的一种情况,因为池中的每台边缘服务器都必须共享同一证书和密钥:

Request-CsCertificate -New -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -ComputerFqdn "sfbedge01.contoso.net" -FriendlyName "SfB Edge External 2026" -KeySize 2048 -PrivateKeyExportable $True -Organization "Contoso Ltd" -OU "IT" -Country US -State "Arizona" -City "Phoenix" -DomainName "sip.contoso.com,webcon.contoso.com,sip.fabrikam.com" -Output "C:certscontoso_edge.csr"

保持使用 RSA 作为密钥算法

该 cmdlet 还有一个 -KeyAlg 参数,接受 RSA、ECDH_P256、ECDH_P384 和 ECDH_P521。Microsoft 自身的系统要求文档明确指出 Skype for Business Server 不支持 CNG 证书,而公共 CA 在此工作流程中也期望使用 RSA,因此请勿更改 -KeyAlg,让请求默认使用 RSA。同一份文档还排除了 RSASSA-PSS 签名算法,指出它可能导致登录和呼叫转移失败。

管理已提交的请求

同一个 cmdlet 也会跟踪自身待处理的请求。您可以列出它们、检索已签发的请求,或按请求 ID 删除某个请求:

Request-CsCertificate -List
Request-CsCertificate -Retrieve
Request-CsCertificate -Clear -RequestId 224

当检索因某个被吊销的请求阻塞而失败时,清除该请求也是文档记载的解决方法:Request-CsCertificate 仅处理已签发、已拒绝和待处理这三种状态。

将 CSR 提交给您的证书颁发机构

用纯文本编辑器打开您保存的文件。向导的查看按钮会在记事本中为您打开该文件。复制全部内容,包括起始和结尾的标记行。Windows 通常会这样写入:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIICtjCCAZ4CAQAwcTELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0FyaXpvbmExEDAO
... many more lines of base64 ...
jCD4RG92Kab0LzO1Hl07fPvTf8j4kDkWhlE=
-----END NEW CERTIFICATE REQUEST-----

有些工具会写成 BEGIN CERTIFICATE REQUEST,不带 NEW 字样。两者都是同样的 PKCS #10 请求,证书颁发机构都能接受。请注意,这些标记两侧各是五个普通连字符。如果字处理软件或富文本字段将其转换为印刷体破折号,或丢失了换行符,CA 会将该请求判定为格式错误而拒绝,因此请粘贴到纯文本字段中。

在为验证付费之前,先将该内容块通过我们的CSR 解码器检查一遍,确认您规划表中的每个名称确实都出现在 SAN 列表中。遗漏一个 Meet URL 或忘记一个第二 SIP 域,都意味着需要重新签发。

在等待证书签发期间,请避免以下两件事:

  • 不要清除待处理的请求或重建服务器。 私钥保存在该服务器的证书存储中,且永远不会离开该存储。已签发的证书如果没有匹配的密钥则毫无用处。
  • 不要为同一证书生成第二个 CSR 并同时提交两者。 每次请求都会创建自己的一对密钥,而 CA 返回的证书只会与其中一个匹配。

请现在就规划好续期日期。自 2026 年 3 月 15 日起,受公开信任的 TLS 证书有效期上限为 200 天,到 2027 年 3 月 15 日将降至 100 天,到 2029 年 3 月 15 日进一步降至 47 天。在 Skype for Business 上手动通过向导完成的续期,现在至少每年需要进行两次,因此请将此事纳入日历,并附上相关拓扑说明。

如果您不想在服务器上生成请求,我们的 CSR 生成器可以在您的浏览器中生成 CSR 和私钥。但在 Skype for Business 上,这是较弱的选择,因为该请求无法从您的拓扑中读取名称,之后您还需要将签发的证书转换为 .pfx 文件,并手动导入密钥。

CA 签发证书之后

验证完成后,CA 会返回证书。请在同一台服务器上导入该证书,然后将其分配给您请求时所对应的服务角色,可以回到部署向导的第 3 步操作,也可以使用 Import-CsCertificate 和 Set-CsCertificate cmdlet。我们的配套指南如何在 Skype for Business Server 上安装 SSL 证书详细介绍了这两种方法。

由于您是在该服务器上生成的请求,私钥已经存在于其证书存储中,因此 CA 返回的只是单独的证书文件本身。请按原样导入:.cer 或 .crt 文件,或许多 CA 为 Windows 提供的 .p7b 捆绑包。这里无需进行任何转换。只有当证书和私钥必须一起传输时,才需要 PKCS#12 文件(.pfx 或 .p12),这种情况适用于您在另一台机器上生成 CSR 的场景。此时请先用 OpenSSL 将两者合并,然后使用密码导入 .pfx 文件:

openssl pkcs12 -export -out cert.pfx -inkey private.key -in cert.crt -certfile chain.crt

证书分配完成、服务重启后,使用我们的 SSL 检测工具扫描外部名称,确认证书链和 SAN 列表符合您的预期。

常见问题解答

我应该向 -Type 传递哪些证书类型?

对于前端服务器或导演角色,请使用 -Type Default,WebServicesInternal,WebServicesExternal。对于边缘服务器的内部接口,请使用 -Type Internal。对于外部边缘接口,请使用 -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication。您选择的类型决定了 cmdlet 会从您的拓扑中读取哪些 FQDN 并写入 SAN 字段,因此这不是一个可有可无的设置。

我可以为内部的 Skype for Business 服务器购买公共 SSL 证书吗?

只有当这些名称属于公开注册的域名时才可以。自 2015 年 11 月起,受公开信任的 CA 不得签发包含内部服务器名称或保留 IP 地址的证书,这就排除了 .local 域和单标签主机名。位于您不拥有的域中的 FQDN 同样被禁止,因为 CA 无法验证您对该域的控制权。在典型部署中,外部边缘证书和反向代理证书来自公共 CA,而默认证书、内部 Web 服务证书、导演角色证书和内部边缘证书则来自您组织自己的 CA。

为什么我无法在证书向导中编辑 SAN 条目?

因为这些条目本就不属于该向导可编辑的内容。使用者名称/使用者备用名称页面只是拓扑生成器发布到中央管理存储的拓扑文档中所定义名称的一份只读摘要。如果某个条目有误,请取消向导,在拓扑生成器中修正部署配置,重新发布,然后再次请求证书。您仍然可以在流程后续的配置其他使用者备用名称页面上添加额外的名称。

我应该将私钥标记为可导出吗?

通常不需要。Microsoft 的建议是,只有在确有必要时才勾选将证书的私钥标记为可导出,并明确指出一种必须使用该选项的情形:边缘服务器池,其中每个成员都必须为媒体中继身份验证服务提供相同的证书和相同的私钥。如果您计划将证书移动到反向代理或硬件负载均衡器上,也需要该选项。在其他所有情况下,请保持密钥为不可导出状态,并为每台服务器分别生成独立的请求。

Skype for Business CSR 应该使用多大的密钥长度?

请使用 2048 位 RSA。Skype for Business Server 支持 1024、2048 和 4096 位密钥长度,Microsoft 建议使用 2048 位或更长,但多年来公共 CA 已经不再签发 1024 位密钥的证书。4096 位密钥虽然可以被接受,但对于目前有效期最长仅 200 天的证书而言,并不能带来实质性的额外安全性,反而会在每次 TLS 握手时增加额外的 CPU 开销。

CSR 文件必须以 .csr 结尾吗?

不需要。您在 -Output 中指定或在向导的文件名框中输入的扩展名只是一个标签,Microsoft 自己的参考文档在这方面也不一致:其中一个示例写入的是 .cer 文件,而参数说明中展示的却是 .pfx 路径。真正重要的是内容本身,即位于 BEGIN 和 END 标记行之间的 base64 编码 PKCS #10 请求。建议使用 .csr 或 .req 扩展名,方便日后识别该文件。

我可以在另一台机器上生成 CSR 吗?

可以,但这样会失去在服务器上生成的主要优势。在其他地方生成的 CSR 无法读取您的拓扑,因此您必须手动逐一输入每个 SAN 条目,任何差错都意味着需要重新签发。这样一来,私钥也会存在于服务器证书存储之外,这意味着您需要将签发的证书转换为 .pfx 文件并手动导入。而在前端服务器或边缘服务器上生成请求,可以让密钥保持在 Skype for Business 预期的位置。

2026 年 Skype for Business Server 是否仍受支持?

Skype for Business Server 2015 和 2019 已于 2025 年 10 月 14 日结束延长支持。付费的扩展安全更新覆盖了 2025 年 10 月至 2026 年 4 月的时间段,而针对已单独购买该服务的组织,第二个覆盖期从 2026 年 5 月延续至 2026 年 10 月底。Microsoft 于 2026 年 7 月再次确认此后不会有进一步的延期。Skype for Business Server 订阅版自 2025 年 7 月 1 日起可用,是当前的本地部署版本,遵循现代生命周期政策。本页所述的 CSR 步骤在这三个版本上都是相同的。

立即订购 SSL 证书, 可节省 10% 的费用!

快速发行, 强大加密, 99.99% 的浏览器信任度, 专业支持和 25 天退款保证. 优惠券代码 SAVE10

龙飞行的详细图像
撰写人

经验丰富的内容撰稿人, 擅长 SSL 证书. 将复杂的网络安全主题转化为清晰, 引人入胜的内容. 通过有影响力的叙述, 为提高数字安全作出贡献.

Avatar of Sergiu Rosca
Technical Review by Sergiu Rosca

Sergiu Rosca is the core web developer behind SSL Dragon. He manages the technical infrastructure, platform performance, and backend integrations that keep the site running smoothly and securely. At SSL Dragon, Sergiu shares practical insights on web development, site optimization, and technical troubleshooting.

All SSL Dragon installation guides are tested on live server environments and undergo a strict peer-review process to ensure your infrastructure remains secure. Read our full Editorial Policy.