如何实现CRL及证书吊销校验？CA如何创建维护证书吊销列表？

• 处理吊销请求：CA首先验证吊销申请的合法性，确认申请人为证书持有者或具备对应权限，核实吊销理由（如密钥泄露、业务终止、身份信息失效等）
• 生成CRL：按照X.509标准构造CRL结构，包含版本、签发者信息、更新周期、所有吊销证书条目，使用CA私钥对整个CRL签名防止篡改
• 更新维护：按照预设周期（通常数小时到1天不等）生成新的CRL，发生大规模证书风险事件时触发紧急更新，旧版本CRL同步失效
• 分发：将CRL发布到证书预设的分发点，保障用户可正常访问获取

你提到的List<thumbprint, revocationDate>是极度简化的抽象，和实际标准存储格式有很大差异：
标准X.509 CRL采用ASN.1 DER编码，结构分为三部分：

• 头部：包含CRL版本、签名算法、签发者名称、本次更新时间、下次预期更新时间
• 吊销条目列表：每个条目核心字段为证书序列号（不是证书指纹thumbprint）、吊销时间、可选的吊销原因扩展字段
• 签名值：CA对前两部分内容的私钥签名，用于校验CRL的完整性和合法性

• 客户端拿到待校验的服务端证书后，解析证书中CRL Distribution Points扩展字段，获取对应CRL的获取地址
• 客户端下载CRL文件后，首先使用对应CA的公钥验证CRL的签名合法性，同时确认CRL在有效更新周期内，过期或被篡改的CRL会被直接拒绝
• 提取待校验证书的序列号，在CRL的吊销条目列表中进行匹配查询
• 若匹配到对应条目，判定证书已吊销，终止 TLS 连接；若未匹配到，判定证书状态正常，校验通过

• 无论是CA侧维护吊销状态，还是客户端下载CRL后的本地查询，通常都会采用HashMap/哈希集合结构，以证书序列号为key存储吊销信息，将查询复杂度降到O(1)，完全能满足千万级条目下的查询性能要求
• 但纯CRL方案的可扩展性瓶颈不在查询速度，而在全量下载成本：大规模CA的CRL体积通常可达几十MB，用户端尤其是移动网络下下载耗时、耗流量，延迟很高
• 目前行业内已经通过增量CRL（仅下载近期新增的吊销条目）、OCSP在线证书状态查询、OCSP装订等方案替代纯CRL校验，大幅降低对大体积CRL的依赖，解决可扩展性问题

内容的提问来源于stack exchange，提问作者divyanshm