很多工程师不知道，根证书也是会过期的，多数研发在客户端编码时也不会考虑这个因素，因为根本不知道自己不知道，只要解决了传输加密，剩下的就是SRE在服务端保证服务端证书的有效期，快速发版上线要紧。
其实在普通的互联网场景也没问题，比如说web 应用，浏览器直接有热更新机制，安卓客客户端应用，安卓底层也直接帮助解决，但在智能硬件IoT这个领域可就没那么容易了，比如说智能手表、音箱、电饭煲...系统越轻、越薄越好，仅仅为了完成有限的几个操作没必要在端上花高成本堆硬件和系统，系统能小就小，存储能省则省，都是钱啊，证书当然也就落在研发自己处理了，绝大多数的方案是把某家CA的根证书打到ROM里，测试没问题，交付。
当Mozilla发布新策略，"对全球所有CA的可信根证书最少15年更换一次，超时会被Mozilla停止信任，Digicert的部分老根证书将会在2023年07月01日左右逐步升级为Digicert Global Root G2"时，芭比Q了，对智能硬件来说无疑扔了一个核弹，处理不好设备直接变砖，考虑有多少技术方案是老师傅做的时候到了。
新签发的证书都是G2，客户端是G1，证书肯定握手失败，云端链接不上了，那还如何智能？电饭煲还能用，但像音箱这种设备呢，办法只能走ROM发版更新根证书这条路，但ROM更新何其艰难，有些设备可能根本就没办法OTA，有些厂商或许已经去世了(我家买了一个温度计，APP都下载不到了），秒变砖头。
就是这么脆弱，远在万里之外漂亮国厂商的一个决策，就毁掉了产品的使用，这是历史的必然性，想想第一个写IoT客户端的，谁会想到花钱买的证书，厂商会给自己留下这么个大坑（虽然从安全上看很合理），但太太太坑了。
也坑了SRE和整个技术团队，为了G1换G2，发现Android 5.0以前版本未集成Digicert Global Root G2证书、CentOS 6及以前版本系统未集成Digicert Global Root G2证书、JDK1.8u131以前版本未集成Digicert Global Root G2证书、某某客户端只支持G1根证书......这些都得排查处理，不处理，都是故障啊。
好在还给了我们一些处理时间，先把风险通知到所有业务对齐风险，再寻找证书厂商，沟通尽量延长G1签署时间，多一点时间业务就多一点从容，最后是沟通技术方案，基本上三个流派:
- 研发根证书热更新的方案
- 客户端内置多家CA厂商(总不能全过期吧）
- 走自签路线，过期时间自己控制(可以发挥想象力)
感受一下，技术上真不能走捷径，最后的债都得还，哪个行业也不能缺老师傅。
