CRL已过期但ChainStatus显示RevocationStatusUnknown的技术咨询

我正在执行以下X509证书链验证代码：

var ca = new X509Certificate2(caBytes);
var intermediate = new X509Certificate2(intermediateBytes);

chain.ChainPolicy.TrustMode = X509ChainTrustMode.CustomRootTrust;
chain.ChainPolicy.CustomTrustStore.Add(ca);
chain.ChainPolicy.CustomTrustStore.Add(intermediate);
chain.ChainPolicy.RevocationMode = X509RevocationMode.Online;

var build = chain.Build(intermediate);

执行后build返回false，链状态包含：

• OfflineRevocation
• RevocationStatusUnknown

检查中间证书后发现，其CRL指向可正常访问的URL，但获取到的CRL的Next date已过期。执行命令certutil -verify -urlfetch Tesla_Intermediate_BAM_CRAS.crt后，输出明确标注该CRL已过期。

我预期ChainStatus会返回如CtlNotTimeValid的状态，但实际并未返回。与CA运维方沟通后，对方称CRL分发点有效，但未更新CRL，且表示会主动通知证书吊销情况。

现咨询两个问题：

1. ChainStatus和certutil的输出是否说明CRL已过期，是否只能设置NoCheck才能完成证书链构建？
2. CA不更新CRL是否符合专业运维规范？是否应该不设置CRL？

问题1解答 #

ChainStatus返回的OfflineRevocation和RevocationStatusUnknown，结合certutil的明确标注，确实说明CRL已过期。

关于证书链构建的解决办法，并非只能设置NoCheck：

• 优先方案是要求CA运维方及时更新CRL，这是最合规的解决方式；
• 若暂时无法等待CA更新，可临时将RevocationMode设置为NoCheck跳过吊销验证，但这会带来安全风险，仅建议在可控场景下临时使用；
• 也可以实现自定义链验证逻辑，手动检查CRL状态并根据业务需求决定是否通过验证，但这种方式开发成本较高，需要自行处理CRL解析、过期判断等细节。

问题2解答 #

CA不更新CRL不符合专业运维规范。

CRL（证书吊销列表）的核心作用是及时向依赖方分发证书吊销状态，确保依赖方能够验证证书是否有效。如果CA承诺了CRL分发机制但不按时更新，会导致依赖方无法准确判断证书的吊销状态，破坏PKI体系的安全性和可信度。

至于是否应该不设置CRL：答案是否定的。不设置CRL意味着依赖方完全无法验证证书的吊销状态，同样不符合PKI运维规范。正确的做法是：

• 若使用CRL机制，必须严格按照承诺的周期更新CRL；
• 若无法保障CRL的更新频率，建议改用OCSP（在线证书状态协议），OCSP可以提供实时的证书状态查询，相比CRL更轻量化且能及时反馈状态；
• 无论采用哪种吊销验证机制，CA都需要保障机制的有效性和及时性。

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