企业官网建设流程全解析

这条和 6.3.16（证书被吊销）经常被放在一起看，因为它们都在问同一件事：设备怎么对待 CRL。区别在于，6.3.16 里 CRL 是拿到了、并且发现证书在吊销名单里，那是硬错误；而这条是 CRL 压根拿不到，属于基础设施出了问题，证书本身并没有毛病。

标准的要求是：设备访问不到 CRL 时，报Warning: CRL not accessible，然后维持连接，继续把握手做完。

这个取舍挺关键。如果设备因为查不到 CRL 就把连接掐了，那只要 CRL 服务器一抖，整条链路就断，可用性没保障。标准选的是可用性优先，用警告把问题暴露出来，让运维去处理 CRL 的分发，而不是让业务跟着陪葬。

前提

这是 PIXIT 测例，成立的条件是 DUT 的 CRL 存放在设备外部（比如一个 HTTP 或 LDAP 地址），并且 PIXIT 里声明了这个位置。如果 CRL 是烧在设备里的本地文件，"拿不到"这个场景就没法自然造出来。

怎么造出"拿不到"

服务器这边要开启 CRL 检查，但不给它 CRL：

X509_STORE*store=SSL_CTX_get_cert_store(ctx);X509_STORE_set_flags(store,X509_V_FLAG_CRL_CHECK);// 关键：这里不调用 X509_load_crl_file，CRL 文件不存在

配置成这样，客户端拿着正常证书连过去：

openssl s_client-connect127.0.0.1:19998-tls1_2\-certclient.crt-keyclient.key-CAfileca.crt

判定

最后一行容易漏。有些实现会把"查不到 CRL"和"证书被吊销"当成一回事，都报 Alarm 都断链，那就是把 6.3.4 和 6.3.16 混了。这两条的区别只有一个：CRL 到底有没有取到。取不到是 Warning，取到了但证书在名单里才是 Alarm。

和 6.3.24 的关系

6.3.24 是这条的重协商版本，场景一样，只是发生在重协商阶段。两条一起做，能看出设备在初始握手和重协商两个阶段对 CRL 的处理是否一致。有的实现在初始握手时老老实实报 Warning，到了重协商却直接断链，这种不一致光测一条是发现不了的。