启用mTLS需显式配置http.Server.TLSConfig.ClientAuth为RequireAnyClientCert或RequireAndVerifyClientCert，并设置ClientCAs；客户端需通过http.Client.Transport.TLSClientConfig注入证书链和RootCAs。

Go 的 http.Server 怎么启用双向 TLS（mTLS）

必须显式配置 TLSConfig.ClientAuth，否则服务端根本不会向客户端索要证书。默认值是 tls.NoClientCert，等于完全关闭双向验证。

• TLSConfig.ClientAuth 至少设为 tls.RequireAnyClientCert（验证书存在）或更严格的 tls.RequireAndVerifyClientCert（验签名+信任链）
• 同时必须提供 TLSConfig.ClientCAs —— 这是服务端用来验证客户端证书签发者的根证书池，不是“客户端该用哪个 CA 签发”，而是“我只认这些 CA 签的证书”
• 服务端自己的证书和私钥通过 http.Server.TLSConfig.Certificates 设置，和普通 HTTPS 一样
• 如果用 http.ListenAndServeTLS，它底层会新建一个 TLSConfig，你传进去的证书不会自动带上 ClientAuth 配置，所以必须手动构造 http.Server 实例

客户端怎么发起带证书的 HTTPS 请求

Go 的 http.Client 默认不发客户端证书，必须通过 Transport.TLSClientConfig 显式注入证书链和私钥。

• TLSClientConfig.Certificates 是一个 []tls.Certificate 切片，需用 tls.LoadX509KeyPair(<code>client.crt, client.key) 加载，注意顺序：证书文件必须包含完整链（leaf + intermediate），不能只放 leaf
• TLSClientConfig.RootCAs 必须设置，用于验证服务端证书；若服务端用的是自签名或私有 CA，这里就得填对应的根证书，否则连接直接失败（x509: certificate signed by unknown authority）
• 别漏掉 TLSClientConfig.InsecureSkipVerify = false（默认就是 false，但显式写上更安全），跳过验证会绕过整个 mTLS 信任机制

常见错误：x509: certificate signed by unknown authority 到底在哪出问题

这个错误不区分客户端还是服务端，两边都可能抛，关键看谁在做验证动作。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 服务端报？检查 TLSConfig.ClientCAs 是否加载了正确的根证书（不是客户端证书，是签发客户端证书的那个 CA 的公钥）
• 客户端报？先确认 Transport.TLSClientConfig.RootCAs 里有没有服务端证书的签发者；再检查服务端证书是否过期、域名是否匹配（CN 或 SAN）、是否被吊销
• 双方都用了私有 CA 却只互相给了 leaf 证书？这是最典型的配置遗漏 —— 服务端需要 client 的 root CA，客户端需要 server 的 root CA，二者不互通
• 用 openssl s_client -connect 测试时加 -showcerts，能直观看到对方实际发了哪些证书，比猜靠谱得多

mTLS 下如何获取真实客户端身份

证书验证通过后，客户端身份信息藏在 http.Request.TLS.PeerCertificates 里，但别直接读 [0].Subject.CommonName —— CN 已被现代标准弃用，应优先解析 Subject.Names 或 URISANs。

立即学习“go语言免费学习笔记（深入）”；

• PeerCertificates 是一个切片，索引 0 是客户端 leaf 证书，后面是中间证书；务必先校验 len(PeerCertificates) > 0，否则 panic
• 推荐用 cert.VerifyHostname(<code>"expected-identity") 做语义化校验，而不是硬拆 DN 字段；若证书含 URI SAN（如 spiffe://domain/workload），就该按 URI 规则解析
• 别在 handler 里重复调用 cert.Verify —— http.Server 已在握手阶段完成验证，这里只需提取身份字段
• 如果用 Gin/Echo 等框架，注意中间件里取 req.TLS 前确保请求确实走的是 TLS（req.TLS != nil），反向代理场景下容易为空

证书链完整性、CA 根证书的分发位置、以及哪一方负责验证哪一段，这三个地方最容易漏。写完记得用 openssl s_client -connect 和 curl --cert 交叉验证，光跑通 Go 代码不代表 mTLS 真通了。