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这样生成的 CRLnextUpdate 停在 2020 年拿到今天用必然是过期的。服务端配置关键是让设备加载这份过期 CRL而不是默认那份X509_STORE*storeSSL_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 回调里就应该显式地把这个错误码拦下来、记事件、然后返回继续。测之前最好先确认设备有没有这段逻辑免得白跑一轮。