简介面向政务信息化建设者与安全方案设计人员的一份解决方案文档聚焦内外网OA系统中CA数字证书认证与电子签名落地。内容以某市实际项目为背景说明如何通过CA服务器、证书服务器密码机、一主两从LDAP目录、电子签名中间件、USB Key及SSL VPN等组件解决登录身份真实性、公文表单多领导会签的完整性、不可抵赖性问题并覆盖了内外网隔离与密钥安全等关键设计。文档从用户背景、具体需求、网络组件选型到部署效果逐层展开并针对会签场景、服务器证书双向验证、USB Key私钥存储等细节给出落地考虑可作为后续技术选型或方案评审的参考依据。资源为1个PDF文件压缩包大小122KB适合了解政府OA安全体系建设和等级保护合规改造的读者。已有86人学习下载对有电子签名和CA集成需求的项目成员具有一定参考价值。1. 某市 OA 的 CA 数字证书认证和电子签名方案从登录到表单会签的落地骨架某市 OA 系统上 CA 数字证书认证和电子签名真正的难点从来不是镶嵌在证书里的底层算法而是证书从签发、存储、验签、吊销到多领导会签这一整条链路如何在自己的网络环境里落地。这份 PDF 记录的是内蒙古一个人口三百多万的地级市把内外网 OA 从普通账号密码登录升级为 CA 证书认证的完整方案USB KEY 里放私钥Domino 表单上做电子签名签名中间件负责双向验签证书与 CRL 列表通过一主两从 LDAP 从内网同步到外网。方案同时覆盖了公文审批里“一个表单多个领导会签”的场景。适合正在做等保改造、想从口令认证换成证书登录、或需要在 Domino 架构 OA 上补电子签名的项目负责人和集成工程师。照着这个骨架去核对设备选型与签发策略会比从零摸国产化 CA 的坑省出大量时间。2. 先拆方案骨架内网自建 CA、证书服务器密码机、LDAP 一主两从、签名中间件如何拼装2.1 为什么政务 OA 要自建 CA而不是直接买第三方数字证书这份方案写的场景是政府单位网络要求内外网隔离OA 里的用户是公务员流通的是公文审批流程。如果用公共 CA 的证书每次登录都要依赖外部证书链的在线状态CRL 和 OCSP 都不在本地一旦链路不通或者外部证书中心服务波动OA 登录会直接被卡住。公文场景最怕的并不是证书本身廉价不廉价而是“吊销了一个人之后外网还能不能立刻让他失效”。自建 CA 之后证书的签发、吊销、续期都掌握在自己手里CRL 也能按自己的频率发布到内网 LDAP完整性和不可抵赖性这个目标才有根。内网建设 CA 服务器后密钥的生成和管理由证书服务器密码机负责。这是这套方案里很关键的一点CA 的私钥不是躺在应用服务器的磁盘上而是锁在密码机里管理员拿不到也不允许导出。实际操作中我会把根 CA 与签发 CA 分离根 CA 离线签发 CA 在密码机里跑这样即使内网被攻破根证书也不会被拖走。密钥用途也要分开服务器证书做 TLS 双向认证用户证书做数字签名不能一张证书既当身份凭证又做加密否则后续恢复和审计都说不清楚。选型上还要考虑国密改造的余量。政府项目现在普遍要求支持 SM2、SM3、SM4密码机最好同时支持 RSA 2048 和 SM2不要只买纯 RSA 的老型号。采购清单里除了 CA 服务器、密码机、LDAP还要留出至少一台专门跑证书下发和 CRL 发布的服务器这类机器不需要多高性能但必须稳定因为所有应用系统的证书状态都依赖它。2.2 一主两从 LDAP 的同步逻辑内网自动外网手工LDAP 在这套方案里不是可选的周边组件而是证书和 CRL 的发布中枢。用户证书、服务器证书、吊销列表都发布到 LDAP 目录上应用在验签时先去 LDAP 拿最新的 CRL再去确认证书是否有效。方案采用了“一主两从”的结构内网部署一主一从外网部署一从内网主 LDAP 自动把数据推送到内网从 LDAP外网从 LDAP 则采用手工导入。数据流向是单向的从内网主节点出发经过内网从节点再人工摆渡到外网从节点绝不允许外网反向连接内网。为什么外网从 LDAP 不直接和内网做自动复制我在解释这条链路时经常被问到。答案是内外网之间的数据通道一旦做成自动双向就等于把内网用户目录和证书目录暴露给了外网区域防火墙配置稍微出错就会出现数据外泄。手工导入虽然看起来原始但每次导入都有记录、有人审批是对“内外网隔离”这个要求最稳妥的让步。实际运营时不需要每次都人为做一遍导出导入可以写个定时任务在安全区内生成 LDIF 快照再由运维人员人工检查后拷贝到外网从 LDAP 服务器导入。证书与 CRL 列表定期发布到内网主 LDAP这个“定期”在政府项目里我一般设成每 24 小时强制发布一次同时做增量发布。如果某个领导调离、某个人证书被吊销撤销动作发生后要立即强制发布一次 CRL不能等第二天定时任务。外网从 LDAP 的 CRL 更新节奏可以慢一些但最长不能超过一周否则外网登录用户拿着已经被吊销的证书继续访问风险不可控。2.3 签名中间件和 USB KEY 的职责边界电子签名中间件部署在内网做的是双向签名和验签。所谓双向签名和验签一层含义是用户登录时用户和服务器互相验证身份另一层含义是业务方在表单上签名、验签方在后台验证签名两边都通过中间件完成。中间件是应用和底层密码设备之间的桥它把“签名动作”抽象成接口OA 系统不需要自己写 PKCS#1 的底层层拼接也不需要直接操作 USB KEY 驱动。Domino 这种非 Java 传统架构的 BS 系统集成起来最顺的就是通过中间件的 HTTP 或 SOAP 接口调用。USB KEY 是私钥的物理载体方案里明确要求存储容量大于等于 32K带密码算法芯片。这里“大于等于 32K”指的是 KEY 的可用存储空间用户证书、密钥对、可能还有个人数字签名相关的附加属性都要写进 KEY空间太小会限制证书链和多证书场景。内带的密码算法芯片保证私钥只能生成和使用在芯片内部私钥文件拿不出来即使拿到 USB KEY 也导不出私钥。这比把私钥放在浏览器证书库或服务器文件里安全得多。设计分工时我习惯把“签名”和“验签”拆开看签名一定是私钥持有者在 USB KEY 上完成验签一定是在服务器中间件上完成公钥可以到处分发私钥永远不离开 KEY。整个过程里USB KEY 只负责出结果不负责执行业务逻辑中间件只负责验签和证书状态检查不接触私钥。边界清楚了后面做表单会签才不会乱。3. 把证书用进 Domino OA双向登录、多领导会签的签名结构、金格控件的共存顺序3.1 登录阶段的双向认证Domino SSL 客户端证书验证BS 架构的 OA 是 Domino Notes 开发这类系统登录认证默认基于用户名密码改造 CA 之后要做的是把登录入口从口令换成证书。需要用到的证书有两类一类是发给 WEB 服务器的服务器证书另一类是发给用户的客户端证书。用户在浏览器里插入 USB KEY 访问 OA 时SSL/TLS 握手阶段双方互相验证客户端用服务器证书验证自己在访问的是真正的 OA 服务器服务器用客户端证书验证登录者是合法用户验证通过后Domino 把客户证书信息映射到 Notes 用户文档。Domino 的 SSL 配置有几个点容易忽略。第一服务器文档里必须启用 SSL协议建议只保留 TLS 1.2 以上第二服务器证书的私钥要和密钥库文件放好Domino 用的不是操作系统证书存储而是自己的密钥库第三客户端证书认证要设置为强制校验不能设置成可选否则浏览器不弹 USB KEY 也能继续访问。证书里的 DN 或者 UID 需要在 Domino 里映射到 Notes 用户名映射规则要提前设计通常用证书中的身份证号或工号避免同名用户错位。登录成功后并不意味着每步操作都安全。证书只在建立连接时被验证HTTP 会话的 Session Cookie 在有效期内依然能保持登录态。所以建议在 OA 里把鬼关键的审批动作如“提交”“签批”“退回”设置为二次签名或重新输入 USB KEY PIN这样证书的价值就不只是登录入口而是贯穿到业务动作。这个设计后期验证起来很舒服也符合电子签名不可抵赖性的预期。3.2 表单电子签名多领导会签时签名不能只存一个字段电子签名不是给整个 Word 文件盖个章而是对表单要素做摘要后再签名。一份公文表单包含标题、正文、附件、审批意见每个领导签批时中间件会提取当前表单的原文数据计算摘要再把摘要送到 USB KEY 里签名。签名结果会包含签名者证书信息、签名算法、签名时间和摘要值最终回写到表单中。验签时需要对表单重新提取同样的摘要再和签名里的摘要比对一致才能判定有效。多领导会签最容易犯的错是“后签覆盖前签”。很多 OA 在表单上只放一个签名字段领导 A 签完保存领导 B 再打开时签名字段被新值覆盖验签时只能看到 B 的签名A 的签名丢了。正确做法是把签名信息设计成可追加的结构每个领导一条记录顺序追加到一个签名列表字段中。我一般会在表单里增加一个隐藏字段结构类似每个签名项包含证书 DN、签名动作时间、摘要算法、签名值、被签内容的版本标识。验签时就遍历这个列表逐条用对方证书验一遍只要有一条不通过整份表单的签名状态就是失败。会签顺序也要提前定好。平行机构会签和自上而下会签在业务上语义不同技术上的差异在于每个签名是对哪个版本的摘要做签名。如果 B 在 A 之后修改了正文再签那么 B 的签名覆盖的是新摘要A 的签名验的是旧摘要两者之间没有继承关系所以必须在签名记录里带上“上一签名摘要”或“文档版本号”形成一条可追溯的签名链。满足“完整性”和“不可否认性”靠的就是这条链而不只是最后一个人的签名。3.3 金格痕迹保留控件与签名中间件的时序安排原文特别提到金格 word 控件主要做痕迹保留和系统登录无关。这句话容易让人误会金格控件和电子签名没有关系实际集成时它们的冲突恰恰最多。金格控件在 OA 里编辑 Word 正文时会在本地生成临时文件来保存修订痕迹和痕迹数据当页面里又同时调用签名中间件去取正文做摘要时两个控件就可能争抢同一个文件的访问权限表现是把文档锁死、保存失败或签名验签拿到旧内容。我的处理习惯是严格分时。先把 Word 正文编辑流程完整走完金格控件保存并释放文件锁之后再去触发签名动作签名动作执行期间页面上不再允许金格控件重新打开同一份文档。业务层面可以这样定规则表单状态为“编辑中”时不显示签名按钮只有点击“提交签批”后才进入锁定状态这个时候才允许调签名接口。这样既保留了金格控件的痕迹能力又不会让痕迹数据和签名数据互相污染。还有一点痕迹保留保存的是修订过程电子签名锁定的应该是最终版本所以签名时一定要以上一步保存后的文件内容来提取摘要不能拿正在编辑的未存档版本去签。否则保存后内容和签名内容对不上验签永久失败。4. CA 与 LDAP 部署实施证书模板参数、最小 POC、CRL 发布与手工导入4.1 部署前要锁定的证书与目录参数这套方案启动前我会先把下面这张参数表填完参数不定清楚后面签出来的证书五花八门应用侧根本没法统一校验。组件关键参数配置建议根 CA证书 DN、根证书有效期DN 用机构标准名有效期 20 年密钥长度 RSA 2048 或 SM2签发 CA签发算法、有效期有效期不超过 10 年每日签发量小的单位可以和根 CA 合一政府项目建议分离服务器证书密钥用法、有效期密钥用法选 digitalSignature、keyEncipherment有效期 1 到 2 年用户证书密钥用途、主题 DN必须带数字签名用途DN 里放工号或身份证号CRL发布周期、发布点全量每天发布一次吊销后立即额外发布一次LDAP主从节点、绑定账号内网一主一从自动同步外网一从手工导入USB KEY存储容量、密码算法存储量大于等于 32K带国密或 RSA 密码算法芯片政务场景里证书模板最好按角色划分普通用户、领导、管理员、服务器证书各一套模板有效期和密钥用途不同。用户证书有效期通常 2 到 3 年服务器证书 1 到 2 年不要统一设成 5 年证书过期回收不及时会导致大量 USB KEY 失效。CRL 发布周期 24 小时是个相对稳妥的值太短会增加 LDAP 压力太长则吊销响应不及时。4.2 用 OpenSSL 把证书链路先跑通商业 CA 设备的操作界面各不相同但在做功能验证时我习惯先用 OpenSSL 把证书签发和验签逻辑跑一遍确认业务方需要的签名链路长什么样再迁移到正式密码机上去。下面是一套最小可运行的本地根 CA 和服务器证书签发命令# 1. 生成本地根 CA 私钥和自签名根证书 openssl req -x509 -newkey rsa:2048 -keyout ca.key -out ca.crt -days 7300 \ -subj /CCN/OCityOA CA/CNCity Root CA # 2. 生成 Web 服务器私钥和证书签名请求 openssl req -newkey rsa:2048 -keyout server.key -out server.csr \ -subj /CCN/OCity Office/CNoa.example.local # 3. 用根 CA 给服务器证书签名 openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out server.crt -days 730第一条命令生成根 CA 私钥和根证书-days 7300表示 20 年有效期-subj指定证书主题生产上要用真实机构 DN。第二条命令生成服务器私钥和 CSR私钥如果是在密码机上这一步应该在密码机内部完成CSR 从密码机导出不落本地磁盘。第三条命令是根 CA 对 CSR 做签名输出服务器证书。这套流程在测试环境里非常有价值因为发证逻辑、CRL 吊销点配置、应用验签链路都可以先用 OpenSSL 调通再平移去商业 CA。生产环境换到密码机后唯一变化的只是私钥的生成和保存位置证书格式、验签接口完全一致。做 POC 时最好把 ca.crt 导入到测试机的信任证书库否则浏览器和中间件都会报“证书不受信任”容易被误判为证书签发失败。4.3 LDAP 主从复制与 CRL 发布节奏CA 签发出来的证书和 CRL 要发布到内网主 LDAP发布点通常是一个固定目录比如证书放在oucertificates,ocitycaCRL 放在oucrl,ocityca。CRL 的发布需要写进证书的 CRL Distribution Point 属性里应用验签时才能自动找到吊销列表。发布动作由 CA 服务的定时任务触发推荐每天凌晨执行一次同时生成一份 LDIF 变更文件用于同步。内网主 LDAP 会自动把数据推送到内网从 LDAP这个可以通过 LDAP 复制协议或目录服务自带的同步机制完成。重点在外网从 LDAP它必须走手工导入第一步在内网主或内网从节点上用工具导出 LDIF 快照第二步把 LDIF 文件拷贝到外网从节点的前置目录第三步执行导入命令一般是这样# 将导出的 CRL 与证书变更导入外网从 LDAP ldapadd -x -H ldaps://ext-from-server:636 -D cnadmin,ocityca -W -f update_crl.ldif这里-H指定外网从 LDAP 的地址必须用ldaps://保证导入通道加密-D是绑定管理员账号-W会提示输入密码-f指定 LDIF 文件。导入完成后用ldapsearch抽查几条记录确认外网从 LDAP 中 CRL 的最早更新时间是不是新的。手工导入不是问题问题是忘了按周期执行所以要在运维层面加一条固定提醒每周至少检查一次外网从 LDAP 的数据新鲜度。5. 排查与避坑CA 登录和电子签名上线后的五个典型问题5.1 拔掉 USB KEYDomino 会话仍然有效现象用户登录 OA 后把 USB KEY 拔走刷新页面依然能继续操作审批按钮也能点管理员很慌觉得证书认证形同虚设。原因Domino 只在建立 HTTPS 连接时验证客户端证书验证通过后就生成会话 Cookie。之后每次请求走的是 Cookie 会话不会再回查 USB KEY 是否还在证书吊销对已建立的会话没有即时作用。解决在 OA 的关键动作上强制二次验签。提交、审批、退回这些敏感按钮点击时再调用一次签名中间件要求用户输入 USB KEY PIN中间件会重新检查当前证书和 USB KEY 状态。如果证书被吊销或 KEY 被拔出这次调用就直接失败业务动作被中断。同时把 Domino 会话超时时间调短我一般设在 15 分钟以内进一步压缩拔掉 KEY 后的空窗期。5.2 外网从 LDAP 里的 CRL 过期导致登录验证失败现象外网用户用合法证书登录 OA页面报“证书已被吊销”或“证书状态未知”但按证书 DN 去查并没有吊销记录。原因外网从 LDAP 是手工导入导入周期没跟上CRL 里记录的 thisUpdate 时间超过了下一次更新周期中间件认为这份 CRL 已过期拒绝接受任何依赖它的验证结果。解决把 CRL 有效期监测做成一条监控项每天检查外网从 LDAP 里 CRL 对象的 nextUpdate 时间低于一天时自动告警。内网主 LDAP 的 CRL 发布任务也要稳定发布失败必须有人能看到。重点做好一次性强制发布发生吊销动作后不要再等第二天的定时任务直接在 CA 管理端触发增量发布然后把增量 LDIF 手动摆渡到外网从 LDAP。5.3 多领导会签时后签覆盖前面领导的签名现象领导 A 签署后文档进入下一级领导 B 打开表单完成自己的签署保存后再做验签只能通过 B 的签名记录A 的签名验不到。原因表单设计里只有一个签名字段B 签署时把 A 的签名值覆盖了或者每次签名都把整个文档作为摘要对象B 保存文档的动作改变了文档的二进制内容导致 A 的旧摘要永远验不过。解决改表单结构把单一签名字段换成签名列表每个领导签名写入一条独立记录。记录里要包含领导证书 DN、签名时间、摘要算法、签名值、被签内容版本号。同时控制会签过程中的文档编辑权限一旦有领导完成签名文档正文进入锁定状态后续领导只能附加签批意见不能修改正文。这些规则要在 OA 表单的权限配置里提前定义好。5.4 金格控件和签名中间件抢文件锁导致 Word 卡死现象用户编辑完正文点“签名”Word 进程卡住签完名后文档版本丢失后台拿到的还是签名前的旧文件。原因金格控件在编辑 Word 时会在本地临时目录生成副本文件句柄没有完全释放签名中间件这时候去读文件内容计算摘要两个进程对同一文件发生文件锁冲突。更像是控件集成问题但容易被误判成 CA 问题。解决把“编辑”和“签名”做成两个互斥阶段。页面设计上文档在编辑状态下不开放签名按钮点击“提交签批”后金格控件先执行保存并退出对文件的占用随后前端才调用签名中间件。如果业务上必须在签名后继续改动正文那签名的应当是附件版本正文版本需要重新走一遍签名绝不能允许已签名的内容继续被金格控件修改。5.5 国产化终端上 CA 客户端不识别 USB KEY现象用户从 Windows 换到麒麟系统 Kylin 或统信 UOS插入 USB KEY 打开 OA页面不弹出证书选择键盘中输入 PIN 的界面也不显示。原因老版 CA 客户端中间件是典型的 ActiveX 或 32 位 NPAPI 插件只兼容 Windows 上的旧版浏览器国产化操作系统和主流浏览器都不再支持这些接口客户端下载安装后可能名存实亡。解决选型阶段把国产化适配写进采购条款要求 CA 中间件提供麒麟 Kylin、统信 UOS 的原生客户端和国产浏览器的扩展支持。部署时第一件事是在系统证书库中导入 CA 根证书否则浏览器会认为服务器证书无效很多项目就是卡在这步看起来像“无法定位服务器”的操作上。部署完成后用国产浏览器单独做一轮登录和签章测试不要只在 Windows 上验证完就上线。6. 把 CA 当基础设施复用小步验证法与设备延伸6.1 上线后的三档验证证书体系上线别急着全量推广我习惯按三层做验证。第一层在测试环境只测登录链路用几张测试证书走通 HTTPS 双向认证和 Domino 用户映射第二层在准生产环境测电子签名和会签重点构造两个领导连续签批的文档验签时逐条发起签名验第三层做一次证书吊销演练把某张测试证书吊销并强制发布 CRL确认吊销后的用户马上无法登录同时验签接口对包含该证书签名的文档给出失败结果。三档走完再放开全量发证。验证结果要留痕。每次验签把中间件返回的验签报告、签名者 DN、时间戳存到独立日志库便于事后审计。不要只依赖 OA 数据库里的表单字段因为表单字段可能被误改日志库里的验签报告是对“不可抵赖性”更有力的补强证据。对外网从 LDAP 的手工导入建议把每次导入的 LDIF 文件按日期归档一旦外网平台出现数据不一致能快速定位是哪一次导入出的问题。6.2 安全设备复用到其他业务系统CA 服务器、密码机、USB KEY 和签名中间件这一套不需要只给 OA 用。业务侧常需要做身份认证和电子签章的可复用比如档案系统查阅留痕、邮件系统登录增强、预算审批电子签名都可以直接接入现有的 CA 和签名中间件设备投资的价值会放大。复用时的前提是统一证书策略所有系统使用同一套根 CA 和 CRL 发布点不能每套系统再建独立的证书体系否则会签和跨系统验证都会变得混乱。从那以后我每次接手证书类改造项目都会先核对 LDAP 复制方向和 CRL 刷新窗口再检查 Domino 的 SSL 客户端证书是否强制校验这四件事不确认完绝不推进上线整套证书验证链路才算真正闭环。希望帮到你。本文还有配套的精品资源点击获取