对于CI自动签名，硬件卡模式不仅不是必须的，反而会带来诸多麻烦；云端方案（SimplySign）才是更合适的选择，但需要一些额外的配置才能实现自动化。


硬件卡模式在CI中的现实困境


硬件卡模式在CI环境中会面临几个难以绕开的挑战：

物理连接要求：必须有一台自托管的GitHub/GitLab Runner，并物理连接USB硬件令牌。

远程操作限制：proCertum CardManager无法通过远程桌面运行，只能在机器控制台或VNC下操作，增加了管理复杂。

PIN码输入难题：CI自动化时，如何自动输入固定的PIN码是一个核心挑战。

驱动与配置繁琐：需要在每台构建机上安装驱动，并进行复杂的证书与私钥关联修复。


云端方案（SimplySign）：为CI/CD而生

Certum的云端方案SimplySign从设计上就对CI/CD更友好，它免去了物理读卡器和随身UKey的维护负担。

官方定位：Certum将SimplySign定位为“对CI/CD场景更友好”的解决方案，支持与自动化系统轻松集成。

工作原理：通过SimplySign Desktop在PC端模拟一个虚拟加密设备，签名时由云端HSM执行，signtool可自动调用其CSP驱动完成签名。


如何实现SimplySign的CI自动化


默认情况下，SimplySign需要手动输入手机App上的TOTP动态验证码，这确实会中断CI流程。但可以通过以下方法实现自动化：

核心思路：SimplySign的验证二维码本质是一个标准的otpauth:// URI，其中包含了TOTP密钥。

实现方法：可以将这个URI作为环境变量存储在CI系统中，在流水线中通过脚本（如PowerShell）程序化生成TOTP验证码并自动填入，从而完成认证。

替代方案：也可考虑搭建一个本地签名代理，在安全环境内手动完成一次SimplySign登录，再通过API为CI提供服务。


  

如何获取 TOTP 密钥？

方案一：激活环节提取 TOTP 密钥（推荐，CI/CD 全自动用）

  1. 证书审核通过，Certum 会发激活邮件，里面有链接，点开网页生成激活二维码（这个页面同时包含 TOTP secret）

  2. 不要直接拿手机 SimplySign 扫码，先用二维码解析工具读取这个 QR 码内容

    • QR 内容格式类似 otpauth://totp/xxx?secret=BASE32密钥

    • 把 secret= 后面那串 base32 字符串提取出来，这就是你的 TOTP 密钥

  3. 拿到密钥后，再用手机 SimplySign 扫描同一个二维码完成账号绑定

  4. 把这个 base32 密钥存入 CI 的安全 secret（GitHub Actions Secrets / GitLab CI 变量），脚本里用 pyotp、oathtool 等动态生成 6 位验证码

重要：这个二维码只能用一次，24 小时有效期；一旦扫码激活，密钥固定不变。如果密钥泄露，可联系ssldun重新发送激活邮件生成新二维码，旧密钥直接作废。

方案二：不提取 TOTP 密钥（不想动密钥，更安全，适合企业）

不拿 secret，用签名代理方案，不用在 CI 里自动生成 TOTP：

  • 一台常驻 Windows 机器，安装 SimplySign Desktop，手机 APP 保持登录授权（授权后保持 2 小时签名会话，可以定时续期）

  • 在这台机器搭建本地签名代理服务

  • CI 流水线只把待签名文件上传到代理服务器，由代理调用 signtool 完成签名 ✅ 优点：永远不用导出 TOTP 密钥，密钥不会泄露到 CI 环境； ❌ 缺点：需要长期在线 Windows 主机，多了一层运维。


硬件卡和云端方案对比

硬件卡模式：需要物理USB令牌并自托管Runner，远程操作受限，PIN码自动输入困难，适合低频手动签名。云端方案 (SimplySign)：无需物理硬件，官方支持CI/CD集成，可通过程序化TOTP实现自动化，适合高频自动化CI/CD。


总结与建议

如果你要在CI中实现自动签名，应优先选择云端方案（SimplySign）。硬件卡模式在自动化环境中会带来不必要的物理和管理负担。

对于云端方案，自动化TOTP验证是可行的，但务必妥善保管TOTP密钥，它等同于你的第二因素认证凭证。

d7a1a3891f6eb26c2b9489c7f3e98e3c.jpeg