eMudhra 将退出全球 SSL/TLS 证书业务

事件与退出 SSL/TLS 业务

• eMudhra 宣布将退出全球 SSL/TLS CA 市场，并将此描述为一次战略调整，因为该业务线仅贡献约 1% 的收入。
• 许多评论者认为这更像是“你不能炒了我，是我辞职”：并非主动转向，而是因为浏览器或操作系统再也不会信任他们。
• 有人认为印度监管机构已展开调查，但也有人怀疑不会有严重的本地后果。

技术故障：“4” 作为私钥

• 核心问题是：多个 EC CA 私钥只是极小的整数（例如 4、56、115），可在毫秒级从公开证书中恢复。
• 评论者解释说，如果密钥生成正确，这种情况在统计上几乎不可能；共识是密钥生成/封装脚本严重出错（例如只用了一个字节，或把测试密钥和正式密钥混淆了）。
• eMudhra 的解释（HSM 密钥封装脚本 bug、人工误选了错误文件）被广泛视为深层流程和工程失效的证据，而不是一次偶发失误。

对新闻稿与可信度的反应

• 这份新闻稿受到严厉批评，被认为闪烁其词且带有防御性：把问题归咎于“社交媒体放大”，强调“基础设施没有被破坏”，并强调其他业务线“不受影响”。
• 许多人认为，这是在淡化一家品牌核心就是“数字信任”的公司所发生的系统性失败。
• 多位评论者表示，在这之后，他们不会信任 eMudhra 任何剩余的 PKI、身份或 OTP 产品；有人指出他们的 OTP 实现看起来也很薄弱。

CA 生态、治理与责任

• 批评也延伸到了 CA/浏览器生态系统：
  • 根程序（Mozilla、Google、Apple、Microsoft）以及 CAB Forum 流程被指责接纳并交叉签署了一个明显不成熟的 CA。
  • Sectigo 对 eMudhra 的交叉签名也受到质疑；有人认为交叉签名方也应承担责任。
  • 另一些人指出，审批严重依赖第三方审计，而不是实际的运营审查。

吊销、缓解与平台行为

• Chrome 和 Firefox 因快速吊销而受到称赞；Apple 在 iOS/macOS 上较慢且略显不透明的反应引发担忧，人们用公开检查站点测试设备时有时会看到不一致的结果。
• 许多人意识到信任处理是多么碎片化：语言和运行时（Python、Node、Java、Go）、操作系统证书库以及应用程序常常各自携带 CA bundle，迫使进行大量独立更新。
• 有人认为，任何无法快速不信任某个 CA 的技术栈本身就是疏忽；也有人指出，大规模 CA 吊销在全球范围内带来的工程成本巨大。

替代方案与改革建议

• 反复出现的建议包括：
  • 按地理范围或命名空间限制 CA（例如，国家 CA 只用于其 ccTLD）。
  • 使用 DNSSEC/DANE 或类似机制将密钥直接绑定到 DNS，从而减少 CA 的权力。
  • 让证书固定（pinning）或更强的 CAA/DNS 约束更普遍。
• 有人主张应当只保留少数非营利或受到严格审查的 CA（例如“类似 Let’s Encrypt”），但也有人指出，即便运营良好的 CA 也出过问题；目前尚无明确替代方案取得共识。

文化、国家与组织层面主题

• 许多评论把责任归因于印度企业和监管文化（例如“保全面子”、“izzat”、裙带关系、低薪以及走过场式合规）。
• 也有人反驳，认为类似的企业否认和监管失败在全球各地都会发生，真正的问题是机构、审计和激励机制薄弱，而不仅仅是国别因素。
• 几条评论指出，eMudhra 的领导层似乎缺乏技术背景，而开发者薪资偏低被视为能力投入不足的症状。

更广泛的结论

• 普遍的感受是：
  • 无论如何包装，eMudhra 的 CA 业务实际上已经死了。
  • 这一事件是一次“名人堂级”的 PKI 失败，将推动更严格的要求（例如经证明的 HSM 密钥生成、更好的仪式自动化、更积极的监控）。
  • Web PKI 模型依然脆弱：任何受信任 CA 的灾难性错误或被攻破，都会带来巨大的全球成本，而这一事件重新引发了重新思考，或至少显著加固这一信任模型的呼声。