两层PKI

Question

规划两层ADCS PKI基础设施如下：

              ORCA
   ____________|____________
  |            |            |
 SCA1         SCA2        SCA3
one.int      two.int    three.int

其中，ORCA是脱机根CA，而SCA1..SCA3是从属CA，每个从属CA属于完全不同的域/林，彼此之间不信任或不了解(one.int、two.int、three.int)

现在请记住，这是一个ADCS，理想的场景是，ORCA配置了一个用于CRLs的LDAP以及一个HTTP。然后，域客户端将从ORCA获得来自LDAP的S CRL，而非域客户端将从HTTP (可能是运行IIS或其他什么的服务器)获得它。

但是，当多个完全独立的域都使用相同的根时，这是一个问题--当配置ORCA时，它请求一个可分辨的名称，而任何发出的带有LDAP的URL都将包含该可分辨名称。

因此，如果我们将ORCA的S DN设置为DC=one,DC=int，ORCA发布的所有CRL都将包含LDAP://<lots of stuff that don't matter>,DC=one,DC=int。因此，现在来自two.int和three.int的客户将试图转到one.int，从LDAP那里获得CRL--但他们甚至不知道其他域/森林的存在。

如果我们尝试使用包含ORCA LDAP://...,Dc=one,DC=int的CRL并手动将其发布到two.int .我会得到一个没有找到one.int的错误。

我们可以从LDAP中删除所有LDAP URL，并且只有一个HTTP，但是发布到ORCA所带来的(其他)优势是“自动”冗余和负载平衡(也就是说，您从来没有一个带有单个DC的域)。提供HTTP URL意味着我们至少需要一个web服务器集群来确保高可用性，但这也意味着一个构造看起来有点像这样：

              ORCA
               |
          IIS CLORCA
   ____________|____________
  |            |            |
 SCA1         SCA2        SCA3
one.int      two.int    three.int
IIS CL1      IIS CL2     IIS CL3

其中每个IIS CLs都是IIS集群：IIS CLORCA只是ORCA的CRL (并运行OCSP?)，IIS CL1为SCA1托管CRL + delta，运行OCSP等等.

当然，在SCA1..SCA3方面，您可以将CA角色与IIS角色结合起来，但您真的想这样做吗？从安全的角度来看，这是一个垃圾想法，并且增加了CA本身的攻击面。

当然，在这个构造中，每个从属CA都会发布到LDAP，但是所有域都有不属于域的客户端，因此需要HTTP，因此没有必要让一个服务器为CRL/delta + OCSP提供服务。如果在非域客户端尝试验证证书时，该服务器恰好处于脱机状态- -就像在Windows中每月至少会发生一次一样，客户端将不会收到OSCP的答复，也无法下载CRL，因此无法验证证书。因此，在每个单独的域中都有IIS集群的原因。

但是..。这感觉有点过头了。我想让人们的意见记住，这是为了一个生产环境。

Answer 1

我会选择只使用HTTP的URL。LDAP的唯一好处是冗余，而不是其他任何东西。此外，冗余只在全局目录之间组织，而不是在所有域控制器之间进行组织。

HTTP支持E-tag和Max-Age头。Windows CryptoAPI客户端(至少)支持它们来改进吊销检查体验。您可以查看我关于这个主题的博文：CRL分发点和权限信息访问点的设计

当CRL托管在公共IIS上时，您提到了安全风险。只要IIS所有者拥有所有三个森林的存在，安全风险就不会很大。此外，IIS将通过为每个林中创建一个单独的网站来实现CRL分离。唯一的原因是他们在网络服务器上共享相同的硬件。没别的了。在云解决方案中，当您与其他没有意识到的客户共享相同的硬件时，这是相当常见的。域名部分在URL将是唯一的，您可以购买足够的IP地址，使网站完全无关。

one.int现在可以要求与域无关的OCSP验证来自two.int的证书

one.int只能在one.int从two.int获得证书的情况下才能询问OCSP。而且，CRLs是托管在公共web服务器上还是单独的web服务器上并不重要。如果从互联网上可以访问撤销信息，我不清楚安全/隐私问题。