如何在不迁移旧证书的情况下创建新根CA并实现组织平稳过渡

老哥，我完全懂你现在的糟心情况——当年前任搞砸的根CA迁移留下烂摊子，缺证书、链问题一堆，现在想上Always On VPN还不敢用旧CA，还要顾及几万张旧证书和常年远程的半拉用户。下面是我踩过坑后总结的平稳过渡方案，尽量把麻烦降到最小：

一、先把新根CA的底子搭牢，别重蹈旧CA的覆辙 #

首先得把新CA的架构规划清楚，避免以后再出问题：

• 搞独立根CA（不要用企业根CA，独立的更安全，适合内部环境），和旧CA的命名、密钥参数彻底划清界限：比如用SHA-256+的哈希算法，密钥长度至少2048位（推荐4096），有效期设10年就行（太长的话未来密钥算法过时又要折腾）。
• 新根CA一定要离线部署！平时关机，只有签发子CA证书或者更新CRL的时候才开机，用完立刻断网封存，私钥绝对不能碰网络，备份到加密U盘或者硬件加密模块里，锁到公司保险柜。
• 配套建一个在线子CA，用来给业务签发证书（文档签名、WIFI、SSL这些都由子CA发），根CA只负责签子CA的证书，这样就算子CA出问题，根CA还安全，不用整个推倒重来。

二、新旧CA并行跑，分业务逐步切换，别一刀切 #

绝对不能直接停旧CA换新人，得让两者共存一段时间，按业务优先级慢慢转：

1. 先拿新业务开刀：Always On VPN直接用新CA的证书，完全和旧CA切割，这样新业务不受旧问题影响，也能先验证新CA的流程是否顺畅。
2. 再换更新频率高的业务：比如WIFI证书，用户每次连接都会校验证书，先把WIFI的证书模板换成新子CA签发的，然后通过组策略把新根CA的证书推送到所有客户端的「受信任的根证书颁发机构」里。对于远程用户，趁他们偶尔连VPN的时候强制同步组策略，或者把新根证书放到企业门户/共享盘，发邮件让他们手动导入（步骤写清楚：下载证书→右键→安装证书→选「本地计算机」→下一步到「受信任的根证书颁发机构」）。
3. 接着处理文档/代码签名：通知相关部门，设定一个切换日期，之后所有新的文档、代码都用新CA的签名证书。旧的签名证书只要还在有效期，就让它继续生效——毕竟旧根CA虽然有问题，但只要客户端还信任它，旧签名就依然有效，不用逼着大家重新签10年的旧文档。
4. 最后更内部SSL证书：给服务器分批换，先更非关键服务（比如测试环境、内部wiki），没问题再更核心服务（比如ERP、邮件服务器）。每次更新前提前通知运维，做好回滚预案，避免业务中断。

三、给旧CA留好后路，别让旧证书突然失效 #

几万张旧证书不可能一下子全换完，所以旧CA的信任必须维持到所有旧证书过期：

• 不要吊销旧根CA的证书！反而要确保所有客户端（包括远程用户）的信任存储里依然有旧根CA的证书，避免旧文档、旧WIFI证书突然失效。
• 对于长期不连VPN的远程用户，除了组策略，还可以在内部网站加个检测脚本：如果用户设备没装旧根CA，就弹出提示让他们下载安装；或者通过企业推送工具（比如Intune）强制部署旧根证书的信任。
• 定期更新旧CA的CRL（证书吊销列表），确保已经作废的旧证书能被正常识别，避免被滥用。

四、盯紧过渡过程，及时补漏 #

过渡期间肯定会有小问题，得有监控和支持机制：

• 开个专门的帮助台通道，专门处理证书相关的问题，比如远程用户WIFI连不上、文档签名报错，快速帮他们排查是没装新根CA还是旧证书失效。
• 监控新旧CA的证书请求量：新CA的请求应该越来越多，旧CA的请求逐渐减少，要是某个业务的请求没转过来，就去查模板配置或者组策略推送情况。
• 每两周抽查一批远程用户的设备，看看新旧根CA的信任都有没有到位，避免遗漏。

五、等彻底平稳了再退役旧CA #

等所有旧证书都过期或者被替换完（大概10年？别急，慢慢来），再做收尾：

• 先吊销旧根CA的证书，然后从所有客户端的信任存储里移除它。
• 把旧CA的所有数据（证书数据库、私钥备份、日志）打包加密，离线封存（比如存到磁带里，放到安全的仓库），之后再销毁旧CA的服务器。

几个关键提醒 #

• 给全公司发清晰的过渡通知，告诉大家什么时候换什么业务的证书，可能会遇到什么情况，该找谁求助，减少用户的恐慌。
• 先在测试环境模拟一遍整个流程，找几个远程用户测试新CA的信任、WIFI连接、文档签名，没问题再推到生产环境。
• 新根CA的备份绝对不能丢！多存几个副本，放到不同的安全地点。

备注：内容来源于stack exchange，提问作者naps1saps