Hyperledger Fabric背书节点签名校验与通道策略验证机制咨询

1. 背书节点对客户端交易提案签名的校验流程 #

背书节点不是仅靠客户端公钥做单点验签，整套校验分三层执行，完全覆盖身份合法性、内容完整性要求：

• 第一层做证书合法性校验：节点首先解析提案签名头中携带的客户端X.509证书，先校验证书是否在有效期内，再校验证书链是否能回溯到节点本地维护的对应组织MSP可信根CA证书，同时核对证书序列号是否在MSP配置的CRL证书吊销列表中，直接拦截伪造、过期、已吊销的无效证书。
• 第二层做签名与内容绑定校验：客户端发起提案时，会按照Fabric固定的序列化规则，将提案头（包含通道ID、链码ID、防重放nonce、创建者身份摘要、超时时间等字段）和提案载荷（链码调用参数、读写集占位）整体做哈希，再用自身私钥对哈希值签名，签名值和客户端证书共同打包在提案的签名头结构中。背书节点收到提案后，会用完全一致的序列化规则重新计算待签名内容的哈希值，再用客户端证书中解析出的公钥对签名值做解密校验，只要哈希值不匹配、签名解密结果不一致，直接判定签名无效，从机制上避免了提案内容被篡改的可能。
• 第三层做身份类型校验：节点会读取证书的OU（组织单元）字段，确认身份类型属于允许提交交易提案的client或admin类，peer、orderer类型的身份提交的提案会被直接拒绝。

2. 背书节点对交易提交方的Writers策略校验逻辑 #

通道的所有策略（包括Writers策略）都存储在通道配置块中，每个加入通道的背书节点都会同步完整的通道配置到本地，策略校验完全在节点本地完成，不需要依赖外部服务：

• 校验在签名合法性验证通过后触发，节点首先从已验证通过的客户端证书中解析出身份所属的MSP（组织）、角色、属性等完整身份信息。
• 节点调用本地内置的策略评估引擎，加载当前通道最新版本的Writers策略规则做匹配：默认的通道Writers规则一般为「通道内任意组织的client/admin身份即可满足」，用户也可以自定义规则，比如要求必须满足特定组织集合的签名阈值、必须持有特定属性才能提交交易。策略引擎会按照规则中定义的AND/OR逻辑、身份阈值要求判定身份是否合规，不满足策略的提案会被直接拦截，不会进入后续链码执行流程。

3. 运行阶段新签发客户端证书的可信识别机制 #

创世块确实不会存储具体的应用客户端证书，Fabric的身份可信识别是基于MSP信任根锚定机制实现的，不需要提前预存所有客户端身份：

• 组织加入通道时，会在通道配置中锚定本组织的MSP信任信息，核心内容包括本组织的根CA证书、中间CA证书、CRL吊销列表、合法身份OU白名单，这些信任根数据随通道配置同步给所有通道内节点，是节点判定身份是否可信的唯一依据。
• 网络运行过程中，组织用已经完成锚定的根/中间CA签发新的客户端证书时，只要新证书的证书链能回溯到已锚定的可信CA、证书在有效期内、序列号不在最新的CRL列表中、OU字段符合白名单要求，不管证书是在创世块生成后多久签发的，节点都会直接认可其合法身份，不需要额外将新证书上链存证。
• 节点本地会实时同步通道配置更新，当组织轮换CA、更新CRL吊销列表、调整OU白名单时，节点会自动更新本地的可信判定规则，比如证书被吊销后，只要组织将对应序列号加入CRL并更新到通道配置，所有节点会立即拒绝该证书发起的所有请求。

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