是否可以（...补丁，模块，任何......）配置apache / mod_ssl webserver（任何版本）以自动发现/下载中间颁发CA证书回到预定义的信任根CA？< / p>
我们需要能够为数以万计的最终用户提供TLS客户端身份验证，并且Web服务器可能需要信任数百个中间发布CA.我们可以访问Axway/Tumbleweed Server Validator来处理链中证书的SCVP / OCSP / CRL验证（撤销，OID策略等），但为了让Axway Server Validator插件传递客户端证书， apache / mod_ssl必须首先验证/验证客户端证书，并且它针对预先配置的apache CA证书数据库（具有PEM编码的CA证书的连锁列表的文本文件或包含各个证书文件的目录）发布链。
我会接受任何证书，无论apache是否知道发行CA链（因为SCVP会为我验证链），但我找不到任何表明甚至可能的信息。
我可以手动（或通过脚本）创建CA证书捆绑文本文件，但我确信这会很快变成一个非常大的文件，需要定期扫描以删除过期的CA证书并添加新颁发的证书。当然，这种方法的问题是，当新的CA证书被添加到捆绑文件/目录时，需要重新启动Web服务器，并且结果文件的大小可能是几兆字节，这对网络服务器的性能不利。
非常感谢任何帮助和/或想法。
答案 0 :(得分：1)
您可能对this question感兴趣。 但是，除非您真正了解自己在做什么，否则很可能会引入安全漏洞。
这有两个问题：
SSLVerifyCLient optional_no_ca将通过任何客户端证书。您唯一可以确定的是客户端的私钥与他们提供的证书中的公钥相匹配（证书可能还需要当前有效且具有TLS客户端密钥用法，我不能记住）。
将SSLCADNRequestFile指向空（或只是行返回）文件也会使服务器向其客户端通告一个空的CA列表。请注意，这是TLS 1.0之前的未记录行为（但通常有效）并且从TLS 1.1开始授权，但是作为“未指定”行为。
第一点是一个问题，因为您在Apache Httpd中根本没有验证证书。如果后面的应用程序（依赖于身份验证）作为其身份验证层（您以可信方式转发客户端证书链）的一部分执行某项操作，则可以。对于Apache Httpd层本身内的任何事情来说绝对不行：Httpd中的任何限制都会使用像SSL_CLIENT_S_DN这样的表达式，或FakeBasicAuth，只能不能依赖。
第二点可能在可用性方面存在问题，因为它可能会混淆许多客户端，特别是具有多个证书可用且通常根据服务器公布的CA执行自动选择的客户端。
更一般地说，具有如此多种中间CA的“数万个最终用户”的情况似乎不同寻常。在传统的PKI模型中，您配置的CA是您信任的锚点：它们是有原因的，并且您信任它们。它应该由客户端提供所需的中间证书（或由服务器来信任它们并明确地通告它们）。虽然您尝试做的事情可能在技术上可行，但您需要在实施过程中非常谨慎。目前还不清楚这与各种行政标准和政策的相符程度如何。