使用CertPathValidator验证签名：指定历史时间时CRL吊销检查失效问题

这种指定过去时间验证时CRL吊销检查失效的情况，我之前在处理电子签名合规验证时也遇到过，核心原因大多和CRL的时效性机制以及安全提供者的默认处理逻辑有关，具体拆解如下：

1. CRL本身的有效期限制是核心 #

CRL（证书吊销列表）自身带有thisUpdate（生效起始时间）和nextUpdate（失效时间）两个关键时间戳。当你指定一个过去的验证时间时：

• 如果这个时间早于当前获取到的CRL的thisUpdate：意味着这份CRL在你要验证的那个时刻还未发布，安全提供者会判定它无法用来验证过去的状态，直接跳过CRL检查。
• 如果这个时间晚于当前CRL的nextUpdate：这份CRL在你要验证的时刻已经过期，同样会被判定为无效，不会用于检查。

而当你用当前时间或null（默认当前时间）时，获取到的最新CRL通常正好处于thisUpdate和nextUpdate的有效期内，所以能正常触发吊销检查。

2. 安全提供者对非当前时间的CRLDP逻辑限制 #

即使你开启了EnabledCRLDP系统属性，大多数默认安全提供者（比如Java的SunMSCAPI、SunJCE）在处理非当前时间的证书验证请求时，会自动跳过CRLDP的自动获取流程。原因很简单：CRLDP服务器通常只提供最新的CRL，几乎不会归档历史CRL——提供者判断无法获取到对应时间点有效的CRL，所以直接放弃了吊销检查。

3. EnabledCRLDP的生效范围有限 #

这个系统属性主要是控制当前时间验证场景下，是否自动从证书的CRLDP扩展字段拉取CRL。当你指定了过去的验证时间，提供者内部的逻辑会优先判断“是否能获取到对应时间的有效CRL”，如果判定不可行，EnabledCRLDP的配置就不会生效。

可行的解决方向 #

• 手动导入历史CRL：如果你能从CA的归档服务、或者自己的存储中获取到签署时刻有效的CRL，可以手动将这些CRL添加到证书验证的参数中（比如Java的PKIXParameters里的addCRL()方法），强制让验证逻辑使用指定的历史CRL进行检查。
• 切换更灵活的安全提供者：比如BouncyCastle的PKIX实现，对非当前时间的验证场景支持更友好，可以配置它去尝试匹配历史CRL的时间范围，不过同样需要你能获取到对应的历史CRL。
• 联系CA获取历史CRL：合规性要求高的场景下，CA通常会保留一段时间的CRL归档，你可以申请获取对应时间段的CRL用于验证。

内容的提问来源于stack exchange，提问作者Lucas Grijander