嗨，埃里克！

这不是我第一次听到这个问题：-)前一段时间，当该功能于2017年初推出时，我还想知道如何应对 ACDS数据库。

通常，CA（例如您公司的CA）必须不高度可用。 当CA脱机时，甚至CA链验证和CRL检查仍在起作用。 但是，如果由于某种原因无法使用CA，则以下限制适用：

• 不能从相应的CA请求新证书
• CA不能撤消证书
• CA不能发布新的（或更新的）CRL（！ ）

Microsoft ADCS支持实施故障转移群集。 一次只能运行一个CA实例。 ADCS角色可以使用基础MSFT Windows操作系统的故障转移在主动-被动模式下工作。 但是，这种设置很少在其中使用。

作为登录机构运行并通过HTTP-Destination连接到您的（远程证书颁发机构）的安全登录服务器，一旦与该范例矛盾， 在此操作模式下使用。 现在情况看起来有所不同。 考虑到CA服务的计划或意外关闭，甚至是网络故障，即使您正在运行两个SLS（故障转移），您的用户也将不再收到短期的身份验证证书。 SSO将无法正常工作。 当然，由于每天发布数百甚至数千个8小时有效SSO证书，CA数据库的大量增长。 您可以通过定期清理CA数据库来解决这一问题，但是-您（或您的CA管理员）通常不会这样做。

但是在此操作模式下，它还有很多优点。 您的SLS不再需要他自己的CA密钥对，您可以将SLS限制为某些证书模板（很棒），并且通过使用自己的CA，您仍然支持CRL或OCSP。

在我看来，弊大于利，尤其是在使用远程CA颁发短期SSO证书的情况下。 突然有一个双重SPOF，即SLS和CA。

因此，我倾向于推荐一种混合方法。 我强烈建议通过远程CA进行集成，以为SAP系统（如SNC，TLS等）颁发较长的有效服务器证书。可以使用SLS证书生命周期管理来最佳组合此功能。

在 并行地，我将向SLS捐赠另一个CA以颁发SSO（用户）证书。 这可以是从属于现有根CA的CA。 这样，您的SLS只有一个用户CA，并且仅使用自己的私钥对用户证书进行签名。 使用安全登录客户端机制（enrollURLn），故障转移仍然可以正常工作。 尽管对此表示支持，但可能会导致与（CA）安全负责人进行讨论，因为他们担心SLS-CA（不再受控制）可能会被滥用来颁发其他类型的证书，这些证书随后将在整个公司范围内值得信赖 。

这可以通过证书策略和约束（路径长度，命名，EKU ...）来抵消，但这会使整个CA层次结构变得更加复杂-可能在最初没有考虑到这一点 公司PKI的设计。

不过，我认为这种混合方法是将世界，长期的SAP服务器证书（远程CA）和短期的SSO证书（由企业根目录签名的SLS子CA）结合在一起的最佳方法 CA）

有帮助吗？

干马驹