我想在相对较小的 Windows 环境中实现两层 PKI：大约 35 个用户和 5 个虚拟服务器。虽然我对 Linux 没有什么经验，但我正在尝试使用西卡在基于 Linux 的虚拟机上作为离线根证书颁发机构，因为我不确定是否有必要为大部分时间处于关闭状态的计算机支付 Windows Server 许可费用。
我找到了两组我想要实现的配置的说明。
- https://4sysops.com/archives/use-openssl-based-software-xca-as-offline-root-certificate-authority-for-ad-certificate-services/
- https://wiki.ledhed.net/index.php?title=ADCS_with_Linux/BSD_based_Offline_Root_CA
但是，我担心做错，而且这些说明对我来说似乎不够。我已经研究了好几个星期，我有几个问题。
一层还是两层？
有人认为，鉴于业务规模，我不需要两层 PKI，而应该使用单一的在线证书颁发机构。我并不完全反对这种配置，但我的理解是，当根 CA 处于离线状态时，从受损的在线根 CA 中恢复比从受损的中间/下属/颁发 CA 中恢复要困难得多。是这样吗？我是否必须在没有其他程序或服务的服务器上安装在线根 CA，因为如果服务器受损，可能需要重建？两层层次结构是否允许我将运行颁发 CA 的服务器用于其他目的？
AIA 和 CDP URL
我之前曾尝试过使用 Windows 根 CA 执行此操作。当时我的笔记中记录了在根 CA 上执行以下脚本的情况。
# VARIABLES
$HTTPUrl = "pki.mycompany.local"
# AIA
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n0:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n0:http://%1/CertEnroll/%1_%3%4.crt\n0:file://%1/CertEnroll/%1_%3%4.crt\n2:http://$HTTPUrl/pki/%3%4.crt"
# CDP
certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n0:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n0:http://%1/CertEnroll/%3%8%9.crl\n0:file://%1/CertEnroll/%3%8%9.crl\n6:http://$HTTPUrl/pki/%3%8.crl"
Restart-Service -Name CertSvc -Verbose
我找不到任何与 XCA 等效的程序。事实上，我读到过不应在根 CA 上设置 AIA 和 CDP URL。它们会在颁发 (Windows) CA 的属性中设置吗？
互联网信息服务
IIS 是否需要位于颁发 CA 以外的服务器上？
CAPolicy 配置文件
我读过的一些说明描述了如何修改文件 CAPolicy.inf；其他说明没有。一些说明提到了 OID；其他说明没有。我的理解是 CAPolicy.inf 有帮助但不是必需的。如果我创建它，我可以省略 OID 吗？我是否需要使用描述的步骤获取私有 OIDhttps://www.keyfactor.com/blog/establishing-a-private-oid/？
OCSP
我经常看到有人推荐使用 OCSP，但是却找不到很多关于如何实现它的指南。有人可以推荐一些资源吗？
资源
这些是我计划参考的有关配置 Windows 部分的资源。如果您有更好的指南，请分享。
答案1
一层还是两层？
您的环境很小的说法确实有一定道理。根 CA 的目的实际上有两个方面：在多 CA 环境中，它将您的信任锚聚合为一个，从而简化了依赖方存储中信任锚的管理；并且（如果保持真正离线）它有助于在颁发 CA 受到损害的情况下缓解信任锚分布问题，因为它被设计为永远不会受到损害（即离线并具有严格的物理和程序控制）。
听起来第一个目的不适用于你。但是，你的环境可能会增长，如果将来出现第二个颁发 CA，你可能会庆幸你已经有一个根 CA 来签名它？
第二个目的可能听起来不适用于你，但同样，事情可能会随着时间的推移而改变。此外，Microsoft Windows 域在这方面也有些帮助，因为你可以使用 AD 或组策略来分发和/或删除信任锚，但如果你有一个单级 PKI，并且发生了更糟糕的事情，你是否相信 AD/组策略能够从中删除 CA 证书全部您的依赖方？甚至是您忘记的那些，或者由于用户正在路上而处于离线状态的笔记本电脑？
如果您的环境是虚拟的，那么将根 CA 用作另一个 VM 几乎没有什么好处。没有人可以坦诚地说 VM 处于离线状态。它可能已关闭，但可以打开，并且它会有备份（应该有），可以克隆和启动。如果您坚持使用 VM，请确保在磁盘映像上使用某种形式的静态加密，并将密码短语保存得非常安全。然后担心几年后没有人会注意到 VM 已经有一段时间没有启动了，因此会在没有检查的情况下将其删除。这就是这些备份派上用场的地方……
在虚拟环境中，另一种选择是购买一台笔记本电脑并在其上安装根 CA。不使用时，将其锁在保险箱中。您仍然需要在其周围实施一些强大的流程，以确保没有其他人可以访问它，并且没有人会在 10 年后找到它（积满灰尘）并决定将其回收！您还需要在每次使用后将这台笔记本电脑备份到加密的硬盘上，这也需要受到相同级别的保护。
您对此研究得越多，您就越会意识到 PKI 实际上并不是关于技术（它只是少数服务器），而是关于您为使其成为值得信赖的服务而实施的流程和程序。
AIA 和 CDP URL
正如您正确理解的那样，这些将在颁发 CA 证书中设置。它将由根 CA (XCA) 应用于颁发 CA 证书。
XCA 允许您生成用于应用此类设置的模板。只需生成一个新的 CA 模板（基于内置 CA 模板），并将类型设置为证书颁发机构，将路径长度设置为 0（且为关键），以确保此颁发 CA 证书下的任何实体都不能成为另一个 CA。在此模板上启用主题密钥标识符和颁发机构密钥标识符，并将 CRL 分发点设置为您将托管 XCA 生成的 CRL 的 URL（例如http://pki.mycompany.local/cdp/rootCA0.crl）。您需要一些手动过程将 XCA 生成的 CRL 上传到该位置。
无需在颁发 CA 证书上设置 AIA caIssuer，因为颁发者是根 CA，所有依赖方都必须在其信任锚存储中安装根 CA。也就是说，他们永远不需要使用此扩展来查找根 CA 证书。
编辑此模板时，将密钥用法设置为关键，并选择证书签名和 CRL 签名（仅）。不要选择任何扩展密钥用法。
从 Netscape 选项卡中删除所有内容（现在是 2023 年！）
在 CRL 分发点和授权信息访问设置中使用变量的 Microsoft 系统在 XCA 中不可用。但也不是必需的。在 Microsoft 世界中，它用于自动生成 CRL、证书名称和路径，并且在您重新密钥 CA 证书时非常有用。对于 XCA 根 CA，您只有一个 - 下载 CRL 的 URL - 因此使用变量会有些过头。如果将 XCA 用作颁发 CA，这种功能可能在 XCA 中很有用，但我认为它尚未实现。
互联网信息服务
IIS 确实需要位于颁发 CA 以外的服务器上。这是因为它应该绝不在生产环境中安装在 CA 上。
CA 是一项需要保护的高价值服务。考虑添加防火墙规则，以便只有您的订户可以访问它。您的 CRL 的 IIS 服务应该可以从所有依赖方访问，无论他们位于何处。严格的防火墙规则在这里会成为一种障碍。如果您在 CA 上托管 IIS，则需要非常开放的防火墙规则，这会增加攻击面。如果 IIS 受到攻击，攻击者可以访问您的 CA 密钥。
将您的 IIS 服务放在与 CA 不同的服务器上。
话虽如此，但并不存在 PKI 警察，而且我看到很多实施方案为了简单和节省成本而忽略了这一建议。
CAPolicy 配置文件
可能不需要。如果您不想启用所有 ADCS 模板，您可以添加：
[Certsrv_Server]
LoadDefaultTemplates=0
您不太可能需要注册 OID。除了在 PKI 公约中获得一些赞誉之外，它不会给您带来任何好处。检查 OID 的依赖方软件数量极其有限，因此它只是添加到已颁发证书上的标签。如果您决定编写严格的治理文档来管理您的 PKI 服务，那么您可能需要考虑使用 OID，但在深入这个雷区之前，您需要先了解治理原则。
OCSP
如果您希望撤销证书，OCSP 会很有用，因为它减少了您的依赖方下载大型 CRL 的要求（之所以很大，是因为当您撤销证书时它们会变得更大）。
OCSP 还可以帮助在 Web 浏览器中启用撤销功能，而如今 Web 浏览器往往会忽略 CRL。浏览器供应商对 CRL 和 OCSP 的支持有所不同，因此如果您坚持要求浏览器检查证书是否被撤销，则需要进行一些研究。
Microsoft 文档值得一读。
资源
为什么要信任一些随机博客来提供如此重要的安全服务？微软用于配置其产品的资源有什么问题？示例：
如果你真的必须在微软之外冒险，那么我建议PKI 解决方案作为值得信赖的来源，或系统管理员 LV。
最后，既然我提到了值得信赖来源，你现在必须问问自己是否相信我的胡言乱语:-)
最后
请先在实验室中构建此服务。要创建值得信赖的服务，您需要确保生产构建顺利进行，这意味着这不应该是您第一次尝试此操作。