法院系统的电子签章怎么建：OFD 公文、卷宗盖章与三员管理

法院的电子签章和普通企业不一样

企业用电子签章，起点是解决合同签署。法院的电子签章建设起点不同，它要解决的是公文、卷宗、审批单据这一整套司法文书的安全流转问题。

差别的根源在两点。一是文书类型不同，法院要处理的是电子公文、电子证据、电子卷宗，这些文书的格式、签章位置、验证要求都有对应的国家标准。二是管理要求不同，司法系统对权限分离、密钥管理、审计留痕的要求比企业场景严格得多。

这两点决定了法院的电子签章建设不能照着企业的合同签署方案套，得按司法公文的技术规范来做。

电子印章技术原理

技术要求一：OFD 格式的签章与验证

OFD 是我国自主制定的版式文档格式标准。党政机关和法院系统的电子公文流转，明确要求支持 OFD 格式的签章及验证功能。

这项要求的含义不只是「能签 OFD 文件」，还包括三层：一是系统要支持对 OFD 格式电子公文进行签章，而不只是 PDF；二是要能保持签章格式的标准化和统一性，同时兼容 PDF 等主流格式；三是要能验证来自不同供应商但符合规范的国密印章。

第三层最容易被忽略。法院收到的公文来自不同单位、用不同系统签发，系统如果只能验证自家签的章，实际业务就跑不通。

技术依据上，安全电子签章需要符合《GB/T 38540-2020 信息安全技术安全电子签章密码技术规范》，采用国密 SM 系列算法，配备 SM2 国密证书，支持多种密码设备进行签名和验签。

技术要求二：多场景签章与批量处理

法院的签章场景分散，每个场景的要求都不同。

庭审场景要支持庭审笔录、调解书的签字，签署人要能在庭审现场完成签字。公文场景要支持发文、收文的签章，格式和位置按公文规范来。卷宗场景要支持电子卷宗的批量盖章，一份案子几十上百页。

批量盖章的技术难点在定位。标准格式文件可以用接口指定用印位置；非标准格式文件需要手动指定位置；同一份文件的不同页采用不同定位方式。有些场景还要求用印人手动落章并输入验证码，而不是静默签署，目的是保证每一次用印都是明确的意思表示。

此外系统要具备跨平台能力，支持 PC 端、云端和移动端，支持在线及离线验证方式，满足法院工作人员在不同场景下的签署需求。

技术要求三：三员分离的管理机制

三员指系统管理员、安全审计员和安全保密员，三个角色分别承担不同权限，互相制约。

系统管理员负责系统配置和用户管理，但不接触审计日志；安全审计员负责审计日志的检查和分析，但不参与系统配置；安全保密员负责密钥盘和印章的安全管理。

这套机制的用意是避免某个角色同时掌握配置权和审计权。如果一个人既能改系统配置、又能检查自己的操作日志，审计就失去了意义。三员分离从结构上排除了这种情况。

落到部署上，常见做法是采用「集中部署、统一管控」模式：签章系统部署在信息中心机房，签章密钥盘和用户印章信息由管理员统一授权和调配，通过接口调用进行管理。这样既能保障密钥盘的统一合理发放，也能保障所有签章用户的印章信息安全。

电子印章平台能力

案例：上海市高级人民法院的电子签章建设

上海市高级人民法院成立于 1955 年 4 月，是我国直辖市上海的最高审判机关，承担审理重大疑难案件、指导监督全市各级法院审判工作、维护司法公正等职能。

在国家推动信息技术应用创新改革的背景下，上海高院需要建设一套符合国家信创标准、安全可靠的电子签章系统，覆盖公文收发、庭审签字、卷宗批量盖章、流程审批签字等场景。2023 年 10 月完成上线验收，交付内容包括 iSignatureServer 签章服务器（信创版）、签章客户端（信创版）、云阅读、PDF 云签、HTML5 及密钥管理系统，对接公文系统、电子签章系统和审判系统。

这个项目的需求清单，把前面讲的三项技术要求落到了具体条款上。

在规范性和安全性上，系统需严格遵守《中华人民共和国网络安全法》《密码法》以及《GB/T 38540-2020》规范，采用国密 SM 系列算法，配备 SM2 国密证书，支持多种密码设备签名验签，并实现对 OFD 格式电子公文的签章及验证。

在标准统一与兼容性上，系统既要保持签章格式的标准化，支持国家强制的 OFD 格式，兼容 PDF 等主流格式，还要能验证来自不同供应商但符合规范的国密印章。同时要全面适配信创体系内的国产软硬件环境，包括 CPU、操作系统、数据库、中间件、浏览器和办公软件。

在多环境支持上，系统要具备跨平台能力，支持接入 PC 端、云端及移动端，支持在线及离线验证，涵盖电子文件从起草、审批、定稿到签章、归档的全生命周期。

在管理机制上，系统实施三员管理模式，系统管理员、安全审计员和安全保密员分别承担不同的管理权限和职责。部署上采用「集中部署、统一管控」模式，签章系统部署在信息中心机房，签章密钥盘和用户印章信息由管理员统一授权和接口调用管理。

这个案例里最值得参照的一点是，需求是按场景拆的，不是按功能列功能。庭审、卷宗、公文三个场景各自需要什么签章能力、什么验证方式、什么权限控制，一条条对清楚，系统才能真的用起来。

落地时的推进顺序

司法系统的电子签章项目，推进顺序比功能多少更影响成败。

先定标准，把 OFD 格式、国密算法、SM2 证书这些技术要求落实成验收条款；再定管理机制，把三员角色和权限边界在制度层面写清楚，系统配置才有依据；最后才是场景铺开，从公文这类高频场景开始，逐步扩到庭审和卷宗。

e签宝在政务和司法场景里把 OFD 公文签章、国密算法支持、多场景批量盖章和三员管理机制做在同一套签章体系里，机构需要设计的是角色权限结构和场景规则，而不是为每个场景单独搭一套系统。