Go中CSR签名自动验证失败但手动验证成功问题求助

1. 哈希重复计算导致签名源数据不匹配 #

你的生成流程是先对CSR待签名数据做SHA256哈希，再将该哈希传给第三方服务做二次SHA256后签名，但x509标准中，CSR的签名是直接对TBSCertificateRequest（待签名的CSR核心结构）做指定哈希算法后签名，不存在两次哈希的逻辑。

• 问题本质：csr.CheckSignature()会自动提取CSR中的TBS部分，用CSR指定的哈希算法重新计算哈希并验证，但你的签名基于「SHA256(SHA256(TBS))」生成，和标准验证逻辑的哈希源完全不一致，必然验证失败。而你手动验证时用的是自己预先计算的二次哈希值，所以能通过。
• 验证修复：让第三方服务直接对你传入的原始TBS数据（而非你预先哈希后的结果）做SHA256哈希再签名，重新测试csr.CheckSignature()。

2. CSR签名算法OID指定错误 #

CSR的ASN.1结构中，signatureAlgorithm字段明确标注了签名使用的「哈希算法+签名算法」组合（比如SHA256withECDSA的OID是1.2.840.10045.4.3.2）。

• 问题本质：如果组装CSR时，错误指定了签名算法OID（比如只填了SHA256的OID，而非SHA256withECDSA），csr.CheckSignature()会用错误的哈希逻辑计算TBS哈希，导致和签名不匹配。而你手动验证时明确指定了SHA256，所以能成功。
• 验证方式：
  • 用命令行工具查看CSR的签名算法：openssl req -text -noout -in your_csr.csr，确认是否显示为ecdsa-with-SHA256；
  • 代码组装CSR时，确保x509.CertificateRequest的SignatureAlgorithm字段设置为x509.ECDSAWithSHA256。

3. ECDSA签名的ASN.1编码格式不符 #

ecdsa.Verify()接受的是原始的r、s字节序列，但x509标准要求ECDSA签名必须封装为ASN.1的SEQUENCE结构（包含r和s两个整数）。

• 问题本质：如果第三方服务返回的签名是原始r+s拼接的字节，而非ASN.1编码格式，直接放到CSR的signature字段中会导致csr.CheckSignature()解析签名失败；而你手动验证时可能正确提取了r和s，所以能通过。
• 验证方式：
  • 对比第三方返回的签名字节，和x509.MarshalECDSASignature()生成的ASN.1格式签名是否一致；
  • 用ASN.1解析工具查看签名结构：openssl asn1parse -inform der -in signature.bin，确认是否为SEQUENCE类型的结构。

4. CSR待签名部分（TBS）组装错误 #

你手动验证时用的哈希值是自己预先计算的，但csr.CheckSignature()是基于解析后的CSR内部TBS结构重新计算哈希。如果组装CSR时，TBS部分的ASN.1编码和你预先计算哈希的原始数据不一致，就会导致两边哈希值不同。

• 问题本质：比如你准备的CA信息十六进制数据，在转换为ASN.1结构时，可能和x509.CertificateRequest解析后生成的TBS结构存在差异（比如字段顺序、DER编码方式、冗余字节等）。
• 验证方式：
  1. 导出CSR的TBS部分DER编码：openssl req -in your_csr.csr -out tbs.der -noout -text；
  2. 计算该DER文件的SHA256哈希，和你手动验证时用的哈希值对比，若不一致则说明TBS组装存在问题。

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