证书颁发机构退出全球SSL/TLS市场的决定,暴露出许多企业鲜少审视的一个薄弱环节:组织机构对复杂PKI信任链的深度依赖。

由于旗下八个中级证书颁发机构的私钥遭到泄露,eMudhra宣布退出全球SSL/TLS证书业务,并为客户提供由Sectigo颁发的替代证书。然而,分析人士警告称,企业可能会发现自己对支撑关键业务服务的证书层级结构缺乏足够的了解。

eMudhra在一份新闻公告中表示,公司董事会决定“自愿退出全球SSL/TLS证书业务”。公告补充说,数据主权和合规要求增加了该业务的复杂性和成本。

eMudhra董事长V·斯里尼瓦桑在公告中表示:“围绕此事件的社交媒体放大效应所带来的关注度,与SSL/TLS业务在我们整体业务中的地位严重不成比例。”

该公司表示,将联系受影响的客户免费更换证书。公司还表示,将持续运行吊销和证书状态服务,直到所有已签发的证书到期或被替换为止。

在客户更新通告中,eMudhra表示将向所有客户提供由Sectigo签发的证书。

该公司在更新通告中表示:“我们的G1根证书仍然有效,并将继续获得全面支持。”10月22日发布的声明称,G1 RSA根证书“将继续为客户提供服务,直至此次迁移完成”。

eMudhra表示,将通过合作伙伴免费提供替代证书,并持续运行吊销和证书状态服务,直至其签发的所有证书到期或被替换。CertiNext用户可通过账户申请Sectigo证书,其他客户可联系eMudhra支持团队,声明中补充道。

高德纳首席分析师Niyati Daftary表示,各组织应将G1根证书“视为可能的过渡方案,而非自动默认的最终归宿”。

Daftary说:“鉴于该公司正在退出全球SSL/TLS业务,且其剩余根证书仍受浏览器厂商审查,稳妥的做法是在期限允许的情况下,将关键业务迁移至独立且完全受信任的证书颁发机构。”

如果使用G1根证书是为了防止服务立即中断,她建议设定明确的截止日期,并制定后续迁移计划文档。

她建议在第三方风险评估中纳入签发机构、中级证书与根证书、交叉签名安排、吊销基础设施以及浏览器信任状态等因素。

Security Brigade联合创始人兼首席技术官Yash Kadakia表示,迁移至由同一家公司运营的另一个根证书,并不必然能解决信任与治理方面的担忧。

Kadakia说:“各组织最不希望发生的事情就是被迫迁移两次。”

Sectigo未立即回应置评请求。

IDC研究总监Sakshi Grover表示,更换网站证书可能无法解决企业环境中的所有依赖关系。她指出,剩余的风险暴露点在于那些维护自有信任库、且更新节奏与浏览器不同步的系统。这些系统包括Java密钥库、语言运行时环境、容器镜像、双向TLS配置、代理服务器、负载均衡器、VPN及安全设备,以及嵌入式设备。

Grover在谈到浏览器和操作系统之外的证书信任决策场景时表示:“对许多组织而言,更棘手的发现是它们根本无法回答这些问题。”

Grover指出,谷歌报告称,在相关中级证书被屏蔽之前,证书透明度日志中未发现任何链接至受影响中级证书的证书。她表示,这对执行证书透明度检查的客户而言是一个令人安心的消息,但部分非浏览器应用程序和设备并不执行此类检查。她还指出,攻击者若要实施利用,还需具备拦截流量的有利位置,因此她将剩余风险描述为有限且具针对性,而非大范围风险。

Java供应商Azul在一份声明中表示,Java默认不检查证书吊销状态。因此,如果相关信任链仍被信任,未打补丁的Java开发工具包(JDK)可能会继续接受使用已泄露中级密钥签名的伪造证书。

Azul表示,已发布更新版本的Azul Zulu Builds of OpenJDK和Azul Prime。该公司称,此次更新将受影响的八个证书加入了JDK的证书阻止列表。

Grover建议,安全团队应首先识别浏览器和操作系统之外的证书信任决策发生位置,优先关注接受外部连接的系统以及双向TLS端点。随后,团队应确定哪些系统可以更新,以实现对特定中级证书或公钥的不信任设置。

Mozilla已将签发那八个受泄露影响的中级证书的根证书emSign ECC Root CA – G3从其信任库中移除。谷歌在一篇博客文章中表示,该根证书从Chrome根证书库中移除的操作预计将于太平洋时间10月27日上午推送至所有设备。

谷歌在文章中表示:“为避免服务中断,证书链接至emSign ECC Root CA – G3的网站运营商必须立即获取并安装新的TLS证书。”

Daftary表示,企业通常了解自己的证书经销商,但对支撑其信任关系的证书颁发机构层级结构却知之甚少。

她说:“这就造成了一种未被察觉的第四方风险,有可能同时影响成千上万项服务。”她补充说,首席信息安全官应将签发证书颁发机构、根证书、交叉签名安排以及吊销基础设施纳入其第三方网络风险评估范畴。Kadakia表示:“你可以将某项服务外包出去,但无法外包相应的责任。”

本文原载于ComputerWorld。

InfoWorld