Go x509.Certificate.CreateCRL 生成证书吊销列表的参数与签名边界

如果只是维护旧项目，x509.Certificate.CreateCRL 的核心就是：用签发者证书接收一组 pkix.RevokedCertificate，再用对应私钥生成 DER 编码的 CRL。真正容易出错的地方不在参数数量，而在“谁是签发者、哪些证书被吊销、私钥是否匹配、时间窗口如何表达”这四层边界。

CreateCRL 的参数怎样对应 CRL 结构

旧方法的签名可以按“身份、内容、签名、时间、随机性”来读。接收者 c *x509.Certificate 是签发者身份；revokedCerts 是吊销列表中的条目；priv 是签名私钥；now 与 expiry 描述列表的时间范围；rand 提供需要的随机字节。返回值是 DER 字节，不是 PEM 文本，也不是已经完成线上吊销检查的结果。

最小调用要把错误和输出格式分开处理

下面的片段只展示调用边界。真实项目需要先从 PEM 或其他安全存储中解析签发证书与私钥；不要把示例中的占位变量当成可直接使用的密钥。

package crl

import (
    "crypto/rand"
    "crypto/x509"
    "crypto/x509/pkix"
    "encoding/pem"
    "fmt"
    "time"
)

func makeLegacyCRL(issuer *x509.Certificate, signer any, revoked []pkix.RevokedCertificate) ([]byte, error) {
    // 时间窗口表达这份 CRL 在什么区间内可被依赖方接受。
    now := time.Now().UTC()
    expiry := now.Add(24 * time.Hour)

    // CreateCRL 返回 DER；rand.Reader 只负责签名过程需要的随机性。
    der, err := issuer.CreateCRL(rand.Reader, signer, revoked, now, expiry)
    if err != nil {
        // 生成失败时不要上传半成品，调用方应保留原错误上下文。
        return nil, fmt.Errorf("create CRL: %w", err)
    }

    // PEM 是传输封装，不能把 DER 字节直接当作可读证书文本。
    pemBytes := pem.EncodeToMemory(&pem.Block{Type: "X509 CRL", Bytes: der})
    if len(pemBytes) == 0 {
        return nil, fmt.Errorf("encode CRL PEM: empty result")
    }
    return pemBytes, nil
}

这里的 signer 应该是与签发证书公钥对应的私钥实现。函数只负责生成和封装，不负责判断调用方是否应该信任某个 CRL；信任链、分发地址和吊销检查是另外的策略层。

CreateCRL 的兼容边界为什么需要单独标记

Go 官方文档把这个方法标记为 deprecated，并明确说明它不会生成符合 RFC 5280 的 X.509 v2 CRL。也就是说，旧接口可以帮助兼容历史代码，但不能因为“返回了 DER 且签名成功”就推断所有依赖方都接受它。协议版本、扩展字段和下游解析器的要求，都要在迁移时重新确认。

新代码应优先围绕 x509.RevocationList 构造模板，再调用 x509.CreateRevocationList。这个 API 让签发者证书、CRL 条目和签名者的关系更明确；官方文档还要求 issuer 非空，并且其 KeyUsage 包含 CRLSign。

迁移前按这张清单复查

• 确认 CRL 的签发证书与签名私钥是同一对密钥，且用途允许签发 CRL。
• 确认每个吊销条目的序列号、吊销时间和原因来自可信的撤销记录。
• 确认下游需要的是旧 DER CRL，还是符合 RFC 5280 的 v2 CRL。
• 生成后用解析 API 读取对象，并用签发者关系做签名复查；不要把“能解析”当成“签名可信”。

延伸问答

CreateCRL 返回 DER 后还需要 PEM 吗？

如果系统接口要求 PEM 文本，就像示例一样额外封装；DER 本身已经是编码结果，两者不是两次签名。

为什么私钥正确仍可能生成失败？

还要检查时间窗口、签名者类型、证书对象是否完整，以及吊销条目是否能被 ASN.1 编码。

生成成功就代表证书已经被撤销了吗？

不代表。CRL 还必须被分发到依赖方能访问的位置，并由验证策略决定是否加载和检查。