证书有效，印章仍被拒：DPP 注册库的签名格式规则

数字产品护照注册库只接受一种身份证明：在注册库内生成声明文件，加盖贵组织的合格电子印章后上传，由系统自动校验。实施条例 (EU) 2026/1778 第 4 条确立了这一规则；注册库的验证引擎全程无人工介入。校验通过，护照注册功能即为贵组织解锁；校验失败，则收到一条往往不说明具体原因的拒绝。

八月，欧盟委员会发布了 DPP Registry User Guide for Economic Operators 的 1.02 版，所有改动页面都集中在组织注册章节。综合来看，这些改动正是我们七月自行完成验证时的经验教训：证书可以是真正合格的、由真正合格的信任服务提供方签发，而加盖印章的声明仍可能被拒。

指南现已点名的两类失败原因

嵌入格式。 声明上的印章必须以 PAdES Baseline 格式（B、T、LT 或 LTA）之一嵌入，其他文档格式和签名容器一律不被接受。指南明确点名 Adobe Acrobat：取决于配置，Acrobat 可能以不符合 PAdES 的格式嵌入签名，这样签署的声明即使证书有效也会在验证中被拒。解决办法是一处隐蔽的首选项：首选项、签名、创建和外观，将 Default Signing Format 设为 CAdES-Equivalent——在签署之前设置，而不是之后。

密钥保管问题。 在 eIDAS 框架下，只有当私钥保存在合格的签名创建设备中——信任服务提供方提供的智能卡或 USB 令牌，或其合格的远程签名服务——签名或印章才是合格的。以软件文件形式交付的合格证书不满足这一要求：它产生的是高级印章（AdESeal-QC）而非合格印章，注册库验证会因此失败。指南的建议是：先在委员会免费的 DSS Validation WebApp 中验证已盖章的声明。资格字段显示 QESeal 即可放心；显示 AdESeal-QC，请先联系提供方，再考虑上传任何文件。

救了我们一次的那道检查

指南现在还指向委员会的 DSS Standalone Application（用于签署）和 Validation WebApp（用于校验）——免费，且建立在注册库所依赖的同一验证框架之上。在我们自己的流程中，已盖章声明在 DSS 中被判定为完全合格，却仍被拒绝：证书中的组织标识符与注册库档案未能逐字符一致。这个教训可以推广：注册库执行的每一项检查——格式、资格、标识符——都可以在提交前预演，而每一项在验证器中失败的代价都远低于在正式队列中失败。

盖章之前

四分钟的上传前检查，按顺序进行：确认证书是组织印章而非个人签名；读取证书中的 organizationIdentifier 属性，使注册库中的组织档案与之逐字符一致；设置签名格式，或直接使用 DSS 应用；验证已盖章文件并确认 QESeal 后再上传。

验证是整条护照链路中唯一无法由任何平台代办的环节——它绑定的是贵组织的法律身份，而 2027 年 2 月 18 日不会因为您还在与信任服务提供方往返更换证书而推迟。完整流程及上述失败原因，见我们的经济运营者验证页面——已对照 User Guide v1.02 更新。