HTTP Signature签名头如何生成？Triodos非公开API签名构造排查

这类自定义RSA签名的通用规则 #

• 待签名串的字段顺序是硬校验项，要么按HTTP头名称字典序排列，要么按客户端代码固定的顺序排列，顺序错误直接导致签名失效
• 多数实现不会只拼接请求头的值，会采用头名: 头值的键值对格式逐行拼接，行尾带换行符\n，和HTTP原始报文格式保持一致
• 待签名串几乎都会包含请求方法（GET/POST等）、请求路径（含Query参数）、Host头字段，你之前的尝试完全未覆盖这部分高权重字段
• 你获取到的X-Triodos-SignatureSourceType: raw-v2标识说明，签名计算直接基于原始字节流，不会对待签名整体做Base64编码，仅最终生成的签名二进制值会做编码后放入请求头。

待验证的签名构造方案（按排查优先级排序） #

第一优先级：补全核心缺失字段 #

• 将请求方法、请求完整路径（含?后所有Query参数）、Host头值加入待签名串拼接范围，这三类字段是90%以上自定义签名的必选组成部分。

第二优先级：调整拼接规则 #

• 方案1：按你已确认的参与签名的请求头顺序，逐行拼接头名: 头值\n，最后追加一个空行后拼接原始请求载荷{}，整体直接送入RSA签名计算
• 方案2：将所有参与签名的请求头按头名字典序重排，其余拼接逻辑同方案1
• 方案3：拼接时将所有头名统一转为全小写（例如x-triodos-requestid: 37169686-6D43-458F-904C-661D094F0853），其余逻辑同方案1，不少HTTP框架处理请求头时会自动转小写，签名逻辑会同步做相同转换
• 方案4：替换分隔符尝试，除.外，签名实现常用的分隔符包括|、&、换行符\n、空字符\0，分隔符需分别测试头字段之间、头串与请求体之间的拼接场景

第三优先级：核对RSA签名参数 #

• 确认签名哈希算法匹配，常见选项为SHA256withRSA、SHA1withRSA、SHA512withRSA，算法不匹配时即使待签名串完全正确也会校验失败
• 确认RSA填充模式匹配，常见选项为PKCS#1 v1.5、PSS，填充模式错误同样会导致签名无效
• 确认私钥解析格式正确，区分PKCS#1、PKCS#8格式，解析错误会生成完全无效的签名值

第四优先级：字节级细节校验 #

• 核对所有参与签名的头值前后无多余空格，尤其是几个Base64编码的头值，单个空格的差异就会导致签名错误
• 确认原始请求载荷{}的字节完全匹配，区分无空格压缩版本、带空格/换行的格式化版本
• 确认最终签名值放入请求头时的编码格式，不少实现会使用URL安全Base64变体（将+替换为-、/替换为_、删除末尾填充的=）。

之前尝试方案的共性问题 #

• 已测试的4种方案均只拼接了请求头的值，未携带头名，也未加入请求方法、路径等核心字段，不符合绝大多数签名实现的设计逻辑
• 多套方案对待签名串做了整体Base64编码，和raw-v2标识的原始流计算规则冲突。

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