XML签名验证的校验逻辑并不复杂：对引用节点做规范化，计算摘要，再用签名者公钥验证签名值。但在实际联调中，证书链、算法强度都正确，却频繁出现摘要不匹配或签名无效，问题多半不在密码学算法，而在XML规范化没有对齐。同一份XML经过不同解析器、序列化器或中间网关后，可能产生多种物理表示；如果签名端与验证端看到的字节流不一致，签名值自然失效。因此，理解并固化规范化规则，是保证XML签章稳定验证的前提。
一、XML签章验证为什么必须依赖规范化
XML与普通文本不同，它的逻辑信息可以对应多种物理写法。例如属性先后顺序可以调整，空元素可以写为<Item/>，也可以展开为<Item></Item>；命名空间前缀可以任意命名；换行与缩进在多数业务场景中不影响数据含义。可是数字签名计算的是字节或规范化后字节的摘要，任何物理差异都会改变摘要值。
XML签名规范在设计时已经考虑到这一问题，因此在<ds:Reference>中引入了<ds:Transforms>链。验证方不会直接对原始文件计算摘要，而是先执行引用节点上的Transform，其中最关键的就是规范化Transform。只要签名端和验证端执行完全相同的Transform序列，并得到一致的规范化字节流，摘要就能对上。下面是一个典型引用结构：
<ds:Reference URI="#orderData">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>...</ds:DigestValue>
</ds:Reference>
这里的第二个Transform就是独占规范化。它负责把引用节点转换为一种稳定、可复现的字节序列。如果验证端忽略或改动了这一Transform，即使XML内容看似一样，核心摘要也会不同。很多验签失败并不是证书不可信，而是从这一步开始就埋下了不一致。
二、C14N 1.0、1.1与独占规范化的关键差异
规范化算法并不是只有一个。C14N 1.0定义在http://www.w3.org/TR/2001/REC-xml-c14n-20010315，它规定UTF-8编码、属性按命名空间URI和本地名排序、文本节点中换行符统一、字符引用展开、CDATA段替换为文本等规则。但同时它会把当前节点在整个文档中的可见命名空间声明全部复制到输出中。这个行为在整篇文档签名时通常没问题，但只对某个子节点签名时，就可能把大量无关的命名空间声明带进来。
独占规范化即Exclusive XML Canonicalization，算法URI为http://www.w3.org/2001/10/xml-exc-c14n#。它只输出节点实际依赖的命名空间，对上下文中的无关命名空间不会带入，从而降低验证时因外层命名空间变化导致的失败概率。独占模式还支持InclusiveNamespaces PrefixList，某些命名空间必须参与规范化时可以显式补充。
C14N 1.1则是对1.0的修正，主要解决xml:id、xml:base等特殊属性处理不一致的问题。不过并不是所有平台都完整支持C14N 1.1，一些老旧的网关或中间件仍在使用C14N 1.0。因此，跨系统联调前必须确认双方实际使用的算法URI，而不是只看文档名称。算法URI不同，摘要几乎必然不同。
三、命名空间、空白与实体：三类高频陷阱
命名空间前缀是最常见的坑。假设签名时节点写成<ns1:Item xmlns:ns1="urn:order" id="1"/>，验证时经过DOM序列化后变成<ns2:Item xmlns:ns2="urn:order" id="1"/>，业务上命名空间URI没变，但前缀不同。普通C14N 1.0输出会带着具体前缀，因此摘要不同；独占C14N虽然能减少上下文污染，但前缀本身如果不同，仍可能影响输出。解决方法是让签名与验证使用同一个规范化算法，并尽量避免中间环节重写前缀。
空白处理同样不可忽视。XML解析器是否保留缩进、换行和尾随空白，取决于是否加载了DTD或Schema。没有DTD时解析器通常原样保留；有DTD且元素内容模型为元素时，空白可能被忽略。如果签名端和验证端的解析器配置不同，连源节点树都可能不一致。字符引用和实体展开也存在类似问题：C14N要求先解析实体再做规范化，如果验证环境禁用了外部实体或未正确展开字符引用，摘要计算就会偏离。
还有一类容易被忽略的问题是换行符归一化。XML规范规定换行符统一为\n，但Windows环境下生成的XML可能携带\r\n。如果不做规范化，不同平台的验签结果可能不一致。因此，验证程序在解析XML时最好固定编码和行结束策略，不要依赖操作系统的默认行为。
四、工程上的稳定验证策略与排查方法
要让XML签章验证稳定通过，第一步是固化算法集。把签名端和验证端使用的规范化算法、摘要算法、签名算法、Transform链全部写入接口规范，不允许单方升级。Java环境下可以直接从签名对象中读取CanonicalizationMethod和Transform的Algorithm属性，把它们打印到日志中，便于对比。
第二步是保留原始报文。签章验证最怕的是原始XML经过网关、消息队列或日志系统被“好心”格式化。缩进变了、前缀改了、属性顺序动了，业务上没问题，但签名验证就会失败。如果条件允许，签名方和验证方应共享同一份不可变报文；如果中间必须转换，需要在转换后重新签名，不能指望签名还能继续有效。
第三步是安全解析。验证外部传入的XML签名时，要关闭DTD和外部实体，防止XXE攻击。下面是一个Java解析并验证XML签名的基础代码框架，它同时做了命名空间感知和实体禁用：
import javax.xml.crypto.dsig.XMLSignature;
import javax.xml.crypto.dsig.XMLSignatureFactory;
import javax.xml.crypto.dsig.dom.DOMValidateContext;
import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.Document;
import org.w3c.dom.NodeList;
import java.security.PublicKey;
public class XmlSignatureValidator {
public static boolean verify(String path, PublicKey publicKey) throws Exception {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setNamespaceAware(true);
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
Document doc = dbf.newDocumentBuilder().parse(path);
NodeList nodes = doc.getElementsByTagNameNS(
"http://www.w3.org/2000/09/xmldsig#", "Signature");
if (nodes.getLength() == 0) {
return false;
}
XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");
DOMValidateContext ctx = new DOMValidateContext(publicKey, nodes.item(0));
XMLSignature signature = fac.unmarshalXMLSignature(ctx);
return signature.validate(ctx);
}
}
排查摘要不匹配问题时，可以分两步定位：先用规范化工具把引用节点导出为字节数组，再计算SHA-256并与签名中的<ds:DigestValue>对比。如果此步一致，说明规范化没有问题，继续检查签名值；如果不一致，则逐段对比规范化输出，重点看命名空间声明、属性顺序和空白。把问题缩小到具体Transform，比盲目更换证书或算法有效得多。
最后，多签名场景也要小心。一个XML文档中可能存在多个<ds:Signature>，验证时必须选中所对应的签名节点和公钥。不同签名引用的节点不同，规范化上下文也不同。独占规范化虽然降低了外部命名空间干扰，但InclusiveNamespaces PrefixList的配置必须与签名端完全一致，否则仍会偶发验证失败。