关于微软AD集成在线根CA冗余方案的技术咨询

嘿，针对你的问题，结合你公司极简（KISS）的原则，我来给你拆解下可行度和注意事项：

我的公司更倾向于极简主义和"KISS"原则，而非遵循最佳实践。我了解到"离线根CA"是最佳实践，但我们现有一个已上线的微软AD集成根CA，现在需要为它添加冗余。据我所知，配置完善的两层PKI中，客户端会检查多个CA的URL，因此证书本身就具备冗余性（无需负载均衡）。

问题：在我们的场景下，部署一个子CA并允许根CA或子CA向终端颁发证书，这样做是否足够实现冗余？

核心结论 #

这个方案完全可以满足你的冗余需求，但需要你权衡几个关键的风险和管理细节：

• 冗余能力达标：如果你的在线根CA出现故障，子CA可以继续正常颁发证书（因为子CA证书由根CA签发，终端信任根CA就会信任子CA的签发结果）；反过来子CA故障的话，根CA也能顶上去。这样确实解决了单点故障问题，符合你要的冗余目标。

• 注意根CA在线的风险：这里要提醒你，在线根CA本身就违背了最佳实践——根CA是整个PKI信任链的顶端，一旦被攻陷，所有由它签发的证书（包括子CA的）都会失去可信度。现在让它继续参与证书签发，相当于把最核心的信任节点持续暴露在网络中，这个风险你需要和团队评估清楚。当然，如果你们坚持KISS原则，愿意承担这个风险，那没问题。

• 管理复杂度略有增加：虽然比标准两层PKI简单，但你需要维护两个可签发证书的CA：

  • 要确保两者的证书模板、AD发布配置完全一致，避免终端出现证书信任问题；
  • 后续维护CRL（证书吊销列表）时，两个CA的CRL都要同步管理，不然可能出现吊销的证书无法被终端识别的情况。

• 小细节：CA请求的分配：默认情况下，域内终端会向所有可用的CA发起证书请求，你可以通过组策略调整CA的优先级，或者限制某些请求只能由子CA处理（比如把根CA的签发权限收窄，只用来签子CA证书，这样能降低根CA的暴露风险，也更接近最佳实践的简化版）。

总结 #

如果你们能接受在线根CA的安全风险，并且愿意承担少量额外的管理工作，这个方案完全符合你们KISS的原则，足以实现所需的冗余，不用折腾复杂的离线根CA架构。

备注：内容来源于stack exchange，提问作者MustQ