6.3.4 测的是 CRL 取不到，这条测的是 CRL 取到了，但它是旧的。CRL 文件本身带有效期，nextUpdate 一过就失效。设备读到一个已经过期的 CRL，该怎么办？
标准给的答案是宽容：报Warning: CRL expired，维持连接，继续握手。
逻辑和 6.3.4 一脉相承。CRL 过期说明发布方没有按时更新，这是运维流程的问题，不是对端证书的问题。为了一个可能只是忘了更新的 CRL 就把连接断掉，代价太大。所以标准还是选择警告加放行。
造一份过期的 CRL
正常的 CRL 用 openssl 的ca -gencrl生成，默认有效期是从现在开始往后算。要造一份过期的，把起止时间往前挪就行：
openssl ca-configca.cnf-gencrl-outca_expired.crl-batch-notext\-startdate20200101000000Z-enddate20200102000000Z这样生成的 CRL，nextUpdate 停在 2020 年，拿到今天用必然是过期的。
服务端配置
关键是让设备加载这份过期 CRL，而不是默认那份：
X509_STORE*store=SSL_CTX_get_cert_store(ctx);X509_STORE_set_flags(store,X509_V_FLAG_CRL_CHECK);X509_STORE_load_locations(store,"certs_keys/ca.crt",NULL);X509_load_crl_file(store,"certs_keys/ca_expired.crl",X509_FILETYPE_PEM);然后客户端正常连：
openssl s_client-connect127.0.0.1:19998-tls1_2\-certclient.crt-keyclient.key-CAfileca.crt判定
| 检查项 | 通过标准 |
|---|---|
| 握手结果 | 成功 |
| 安全事件 | Warning: CRL expired |
| 连接 | 保持，不断开 |
一个容易踩的坑
有些 TLS 实现里，CRL 过期默认会被当成硬错误处理，直接抛X509_V_ERR_CRL_HAS_EXPIRED然后验证失败。如果设备不做特殊处理，测出来就是断链，看起来像是不通过。这时候要先分清是设备故意这么设计的，还是它只是没为这个场景写分支。标准既然把它列成 Warning，设备的 verify 回调里就应该显式地把这个错误码拦下来、记事件、然后返回继续。测之前最好先确认设备有没有这段逻辑，免得白跑一轮。
