mTLS在普通TLS服务器身份验证之外，还要求客户端在握手阶段提供证书并证明持有对应私钥。经过代理后，问题的核心不是“有没有证书文件”，而是TLS在哪里终止、谁验证客户端证书、上游是否重新建立另一条TLS连接。
三种常见代理架构
| 架构 | 客户端证书由谁验证 | 上游看到什么 |
|---|---|---|
| 正向代理CONNECT隧道 | 目标服务 | 端到端客户端TLS身份 |
| 反向代理TLS透传 | 上游服务 | 原始TLS握手 |
| 反向代理终止TLS | 反向代理 | 代理发起的新连接与代理身份 |
CONNECT为什么通常不改变mTLS
HTTP正向代理收到CONNECT后只转发加密字节，客户端在隧道里与目标完成TLS握手。客户端证书仍由应用或系统证书库提供，代理账号与mTLS客户端证书是两套身份。若代理限制目标端口或CONNECT失败，甚至还没有进入TLS阶段。
TLS终止后身份怎样传给上游
反向代理验证客户端证书后，上游连接是新的会话。若应用需要客户端身份，可以由代理传递经过清洗的证书主题、指纹或身份头，但上游必须只信任来自该代理的连接，并防止外部请求伪造。更强隔离场景可在代理到上游之间建立独立mTLS。
SNI错误为何会拿到错误证书
同一IP承载多个TLS服务时，客户端通过SNI指定主机。代理若连接上游IP却没有发送正确SNI，可能获得默认站点证书或路由到错误服务。HTTP Host不能替代TLS握手中的SNI，应分别配置。
客户端证书链需要包含什么
客户端通常发送叶子证书和必要中间证书，但不应发送私钥。服务端根据受信CA验证链，并检查有效期、撤销策略和扩展用途。只导入叶子证书而缺少中间证书，常导致某些客户端成功、某些失败。
私钥不匹配怎样识别
证书和私钥必须属于同一密钥对。权限过严、格式不兼容、加密私钥无法解锁或硬件密钥接口异常都会阻止客户端签名。日志中只记录证书指纹和错误类型，绝不能输出私钥内容。
常见错误分层
- 407：正向代理认证，还未进入目标mTLS；
- unknown_ca：一方不信任对方证书签发链；
- bad_certificate：证书格式、用途、有效期或签名问题；
- certificate_required：客户端没有提供证书；
- hostname mismatch：客户端验证的服务端主机不匹配；
- 握手超时：网络、代理、OCSP/CRL或服务资源。
证书轮换为什么容易中断
客户端证书、服务端证书和信任CA的有效期不同。轮换应允许短暂双CA或双证书过渡，先更新信任，再切换签发，最后移除旧CA。代理实例和应用节点需全部同步，避免随机握手失败。
撤销检查经过代理会发生什么
证书验证可能访问OCSP或CRL端点。运行环境若无法联网，检查可能超时或按策略失败。应明确撤销策略、缓存与可用性，不要无声关闭。外部端点也需符合组织代理与隐私要求。
调试需要哪些证据
记录TLS版本、Cipher、SNI、客户端证书指纹、签发者、有效期、代理节点和握手错误即可。不要把完整证书链、私钥或业务请求体公开到工单。通用证书检查可参考HTTPS代理证书与SNI排查。
排查顺序
- 画出客户端、代理和上游TLS终止点；
- 确认CONNECT或TCP路径先可达；
- 验证服务端证书、SNI与CA；
- 验证客户端证书、私钥和完整链；
- 检查代理到上游的身份传递；
- 模拟证书轮换与撤销端点故障；
- 清理调试材料并限制证书文件权限。
结论
mTLS代理故障必须先确定TLS终止位置。隧道、透传和终止代表三种不同身份模型；正确处理SNI、证书链、私钥和上游信任，才能保留双向认证的安全意义。
