1. 课程导入与全景认知

在软件交付链条中，用户真正关心的往往不是“这个程序是谁写的”，而是“它是否可信、是否被篡改、能否安全运行”。代码签名（Code Signing）正是回答这一问题的核心技术：它用数字证书对可执行文件、脚本、驱动、安装包等代码对象进行签名，使操作系统和用户能够验证发布者身份与内容完整性。而企业证书工程，则是围绕企业级证书的申请、签发、分发、使用、轮换、吊销与审计所建立的一整套工程体系。两者结合，构成了软件供应链信任的基础设施。

一、代码签名到底解决了什么问题

代码签名并不是“加密软件”，它的核心价值在于三个可验证属性：身份真实性、内容完整性和行为不可否认性。发布者用私钥对代码摘要签名，验证者用证书公钥验证签名。一旦文件被修改，摘要变化，签名验证失败；一旦证书不受信任，系统会直接拦截或给出警告。

以 Windows 平台为例，未签名的驱动程序通常无法在 64 位系统上加载；未签名的 PowerShell 脚本在默认执行策略下会被拒绝；浏览器下载未签名安装包时可能触发 SmartScreen 警告。这些机制背后，都是代码签名在起作用。企业若忽视代码签名，轻则用户安装受阻，重则软件被恶意替换、品牌受损，甚至触发合规风险。

二、企业证书工程的全景视图

企业证书工程不是“买一张证书”这么简单。它覆盖证书生命周期管理、密钥保护、签名流水线、时间戳服务、吊销与审计等多个环节。下图展示了从代码提交到终端验证的完整信任链，以及企业证书工程中的关键对象与关系。

三、典型应用场景与合规要求

代码签名的应用场景远比“给 EXE 签名”广泛。在 Windows 生态中，驱动程序必须经过 WHQL 或 Attestation 签名才能加载；在 Java 生态中，JAR 包签名用于 Applet 和 WebStart 的安全沙箱；在 Android 中，APK 签名是安装和更新的前提；在容器与云原生领域，镜像签名（如 Cosign）用于保证供应链安全；在固件与 IoT 设备中，签名用于防止固件被替换。

合规方面，企业需要关注几个关键要求。第一，证书类型选择：OV 证书验证企业身份，EV 证书提供更高保障并支持即时 SmartScreen 信誉；第二，私钥保护：CA/Browser Forum 要求代码签名私钥必须存储在 FIPS 140-2 Level 2 或更高等级的硬件中；第三，时间戳：签名必须附带可信时间戳，否则证书过期后签名失效；第四，审计与吊销：企业需保留签名日志，并在私钥泄露时及时吊销证书。

四、整体学习路线

本课程将沿着“概念—技术—工程—实战”的路径展开。前几章建立代码签名与 PKI 基础，理解证书链、摘要算法、非对称加密与签名格式；随后进入 Windows Authenticode、Java JAR、Android APK、容器镜像等具体平台的签名实践；再深入企业证书工程，包括 HSM 集成、CI/CD 签名流水线、密钥轮换、吊销与合规审计；最后通过综合案例，完成从证书申请到多平台签名、验证与故障排查的完整闭环。

五、关键概念速查