【导读】Service Mesh实施失败率超60%，主因是mTLS证书链不可靠。本文基于真实生产案例，解析SSL证书在Sidecar注入、CA信任锚绑定、双向认证握手阶段的关键作用。
新网SSL证书已适配主流Mesh平台API接口，为企业提供符合PCI DSS与等保2.1要求的加密凭证基础设施。

Service Mesh中mTLS为何依赖强SSL证书体系

mTLS不是功能开关，而是运行态前提条件。当Envoy代理启动时，若缺失有效客户端证书或无法验证上游服务端证书签名，则连接立即拒绝并记录x-envoy-upstream-service-timeout错误。

- Istio默认使用自建Citadel CA颁发短期证书（最长30天），导致滚动更新期间频繁触发证书吊销校验延迟
- Linkerd v2.11+强制启用cert-manager集成，但多数企业缺乏PKI治理能力，误配Intermediate CA路径引发ChainVerifyFailed异常
- 多租户场景下，命名空间隔离不等于证书域隔离；未约束SAN扩展属性会导致跨环境证书滥用

三大典型故障归因与新网实践对策

通过对37家金融、政务类客户的诊断发现，以下三类问题占比达79%

- Sidecar容器冷启耗时超标：根源在于私钥解密慢（RSA-2048 > 3s）。推荐切换为ECDSA P-256算法，新网全量支持国密SM2双模证书交付
- 控制平面下发证书后仍报UntrustedRootCertificate：实测显示Kubernetes Secret挂载存在Base64编码截断，应改用ConfigMap+initContainer预加载方式
- 自动轮换窗口期不足造成服务雪崩：建议设置minValidityPeriod=72h，并配合新网SSL证书到期前15日主动推送告警Webhook

构建可持续演进的Mesh证书治理体系

单一工具链难以覆盖DevOps全流程。我们提出三层协同模型：

- 底层：对接HashiCorp Vault PKI引擎，复用新网OV/EV级SSL证书作为Trust Anchor Root
- 中台：通过Operator封装CSR模板、OCSP Stapling参数及CRL Distribution Point地址
- 上层：CI流水线嵌入curl -v https://api.example.com --cacert $(cat /tmp/ca-bundle.pem)健康探针

常见问答

Q：能否用Let's Encrypt免费证书替代内部CA？
A：不可以。LE仅签发DNS验证型公信域名证书，不支持SPIFFE ID映射与IP SAN扩展，违反Mesh最小权限原则。

Q：现有Java应用接入mTLS是否需要重写HTTPS Client代码？
A：无需修改业务代码。只需调整JVM系统属性-Djavax.net.ssl.trustStore=/etc/certs/trusted.jks即可完成透明接管。

*本文由新网（Xinnet）内容中心编辑整理，转载请注明出处。