证书还没过期域名也对OpenSSL却报certificate revoked。先别急着补fullchainerror 23指向吊销检查不是普通的缺链。本文用隔离根CA、中间CA和叶证书复现叶子与中间证书被吊销的差异再把序列号、CRL来源和部署验收串起来。一、error 23不是进程退出码23OpenSSL验证错误23对应certificate revokeddepth指出出错证书在所构建路径中的位置叶子通常为0直接签发者为1。本轮OpenSSL 1.1.1k FIPS的verify失败退出2不是23。自动化要同时保存错误号、depth和进程退出码。证书有效期像门票日期吊销状态则像一张已被作废的票日期还在范围内不代表可以继续使用。也不要把error 23与error 3混为一谈后者在本文夹具中表示找不到所需CRL。二、先绑定证书再读取吊销列表在受控工作目录保留原始证书与CRL不覆盖现场文件。leaf.pem为待验叶证书intermediate.pem为其签发者root.pem是独立授权的信任根。issuer.crl.pem是中间CA签发的PEM格式CRL文件名只是本文约定不表示它自动可信。openssl version openssl x509 -in leaf.pem -noout -subject -issuer -serial -dates openssl crl -in issuer.crl.pem -noout -issuer -lastupdate -nextupdate openssl crl -in issuer.crl.pem -noout -text核对证书issuer、serial与CRL issuer、时间以及条目。序列号只在同一签发者范围内识别证书不能把另一CA的相同数字当成同一张证书十六进制显示差异也不能只靠字符串包含判断。这些命令用于读取材料不证明CRL签名正确、适用范围正确或当前有效。仅见到某个序列号不能跳过验证就宣布生产证书已吊销。复杂的间接CRL、分区或增量CRL另按其扩展处理本文只实验普通完整CRL。三、显式开启检查才知道当前策略验了什么下面固定信任、构链、服务端用途与主机名并用-crl_check检查叶证书吊销状态。-CRLfile加载本地列表不能把它理解为从证书分发点自动下载本轮没有联网获取CRL也没有测试浏览器策略。openssl verify -trusted root.pem -untrusted intermediate.pem \ -purpose sslserver -verify_hostname app.example.test \ -crl_check -CRLfile issuer.crl.pem leaf.pem本轮把叶证书序列号写进有效、正确签名的CRL后这条命令报error 23 at 0 depth退出2。相同材料不启用吊销检查时普通链验证仍可通过。后者不是修好了只是没有执行同一项检查。不要通过去掉-crl_check、关闭验证或放宽错误处理消除告警。先核实输入确为当前目标证书再向签发方确认吊销事件与原因。CRL签名和时间通过也只说明列表可用于相应检查不意味着叶证书没有条目。四、中间CA被吊销叶子检查可能仍通过第二组实验保持叶子未吊销仅把中间CA序列号加入根CA签发的CRL。叶子级-crl_check通过改用-crl_check_all并提供所需列表后在depth 1报error 23。这里的问题是路径上的中间CA重签一张仍走同一路径的叶证书未必能解决。openssl verify -trusted root.pem -untrusted intermediate.pem \ -purpose sslserver -verify_hostname app.example.test \ -crl_check_all -CRLfile all-crls.pem leaf.pemall-crls.pem在本轮由中间CA与根CA签发的两份PEM CRL组成必须先分别核验来源与适用范围。全路径检查只给叶子签发者CRL会在depth 1报error 3这与真正识别中间CA已吊销是不同结论。不要见到all就以为工具自动补齐了资料。五、隔离对照把“不查”“查不到”“已吊销”分开以下结果来自临时目录生成的RSA测试链未修改系统时钟、信任库或生产服务测试材料已清理。空CRL指有有效签名且零条目的列表不是空文件。版本不同应重新跑正反例不把本机结果推广成所有客户端行为。材料与检查方式本轮结果结论边界叶子已吊销不启用CRL检查链验证通过未验吊销不是修复叶子已吊销crl_check23 / depth 0叶子吊销命中中间CA已吊销仅crl_check通过只查叶子不足中间CA已吊销crl_check_all23 / depth 1需处理签发路径全路径检查缺根签发CRL3 / depth 1补齐适用列表叶子CRL过期12 / depth 0不能当成有效无吊销证明错误签名列表还会导致CRL验证失败不能靠编辑文本删除条目改完也不再具有CA的有效签名。证书和CRL都可能暴露内部名称或序列信息分享排障记录前仍要脱敏。六、脚本验收不能只看最后一行OK下面以全部所需列表已准备好为前提直接保留verify退出状态。日志路径必须由任务身份控制避免并发覆盖和不可信软链接。日志打不开同样阻断不能把空日志解释为“没有错误”。umask 077 rc0 openssl verify -trusted root.pem -untrusted intermediate.pem \ -purpose sslserver -verify_hostname app.example.test \ -crl_check_all -CRLfile all-crls.pem leaf.pem \ verify.log 21 || rc$? [ $rc -eq 0 ] || exit $rc printf %s\n 当前材料的离线CRL校验通过本轮对包装器覆盖有效空列表、叶子吊销、中间CA吊销、缺列表、错误主机名和日志写入失败成功提示只在通过时出现。不要管道接tee后只读取tee的退出码也不要用单项openssl crl能读取或签名检查成功替代整条路径验证。七、替换证书后仍要验真实终点确认吊销后按签发方流程处理原因若涉及密钥泄露应轮换密钥而不是照旧复用。中间CA被吊销则需采用获准的新签发路径不能擅自把它加进信任库来绕过问题。部署后分别核对实际终点返回的证书、签发者、序列号、公钥、SAN和链再按目标客户端的吊销策略与业务请求验收。本文离线通过不证明HTTPS已上线也不证明所有浏览器都采取相同CRL行为CDN和多节点仍需逐点检查。绑定错误号、depth、退出码与精确证书未只凭域名认文件。CRL来源、签名、适用范围、时间和条目分别核验。叶子与全路径检查范围明确负例能阻断日志失败不放行。替换原因已处理真实终点和客户端策略另行验收。八、参考资料OpenSSL verifyCRL与证书路径验证OpenSSL crl列表读取RFC 5280证书与CRL规范CertbotX