这条和 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 检查但不给它 CRLX509_STORE*storeSSL_CTX_get_cert_store(ctx);X509_STORE_set_flags(store,X509_V_FLAG_CRL_CHECK);// 关键这里不调用 X509_load_crl_fileCRL 文件不存在配置成这样客户端拿着正常证书连过去openssl s_client-connect127.0.0.1:19998-tls1_2\-certclient.crt-keyclient.key-CAfileca.crt判定检查项通过标准握手结果成功连接建立安全事件Warning: CRL not accessible连接保持能收发应用数据有没有 Alarm不应该出现 Alarm 级别的事件最后一行容易漏。有些实现会把查不到 CRL和证书被吊销当成一回事都报 Alarm 都断链那就是把 6.3.4 和 6.3.16 混了。这两条的区别只有一个CRL 到底有没有取到。取不到是 Warning取到了但证书在名单里才是 Alarm。和 6.3.24 的关系6.3.24 是这条的重协商版本场景一样只是发生在重协商阶段。两条一起做能看出设备在初始握手和重协商两个阶段对 CRL 的处理是否一致。有的实现在初始握手时老老实实报 Warning到了重协商却直接断链这种不一致光测一条是发现不了的。
