Gin 不支持客户端证书校验，必须手动构造 http.Server 并配置 TLSConfig.ClientAuth 才能启用 mTLS；r.RunTLS() 仅支持单向 HTTPS，无法验证客户端身份。
Gin 本身不支持客户端证书校验，必须手动构造 http.Server 并配置 TLSConfig.ClientAuth 才能启用 mTLS。 直接调用 r.RunTLS() 只能做单向 HTTPS，无法验证客户端身份——这是最常被误以为“已开启双向认证”的根本原因。
为什么 RunTLS 不能用于 mTLS
RunTLS 是 Gin 对 http.ListenAndServeTLS 的简单封装，它内部硬编码了 TLSConfig 的初始化逻辑，且未暴露 ClientAuth、ClientCAs 等关键字段。即使你传入了客户端 CA 证书，也不会被加载或使用。
- 调用
r.RunTLS(":8443", "cert.pem", "key.pem")后，浏览器仍可无证书访问，Nginx 或其他反向代理看到的仍是普通 TLS 连接 - 若强行在
RunTLS后再改http.DefaultServeMux或试图 patchhttp.Server，会因监听已启动而 panic - 错误日志通常静默，或只报
accept tcp: use of closed network connection，掩盖真实问题
手动配置 http.Server 启用客户端证书验证
核心是设置 TLSConfig.ClientAuth 为 tls.RequireAndVerifyClientCert，并提供可信 CA 证书池（ClientCAs）。
-
ClientAuth必须显式设为tls.RequireAndVerifyClientCert（不能用tls.RequestClientCert，后者只请求不强制） -
ClientCAs需从 PEM 文件读取并解析为*x509.CertPool；若用crypto/tls自带的x509.NewCertPool()+AppendCertsFromPEM()，注意文件内容必须是纯 PEM 块（以-----BEGIN CERTIFICATE-----开头） - 服务端证书链必须完整：生产环境务必用
fullchain.pem（域名证书 + 中间 CA），否则客户端可能因信任链断裂拒绝连接 - 私钥权限必须为
0600，Linux 下若为0644，Go 会拒绝加载并报错tls: private key does not match public key（实际是权限检查失败）
srv := &http.Server{
Addr: ":8443",
Handler: r,
TLSConfig: &tls.Config{
MinVersion: tls.VersionTLS12,
ClientAuth: tls.RequireAndVerifyClientCert,
ClientCAs: caCertPool, // 由 x509.NewCertPool() + AppendCertsFromPEM() 构建
NextProtos: []string{"h2", "http/1.1"},
},
}
srv.ListenAndServeTLS("./fullchain.pem", "./privkey.pem")
如何在 Gin 中获取和验证客户端证书信息
启用 mTLS 后，客户端证书会自动出现在 http.Request.TLS.PeerCertificates 中，但 Gin 不会自动注入到 Context。你需要自己提取并校验。
-
PeerCertificates[0]是客户端终端证书，可从中提取Subject.CommonName、Subject.Organization或自定义SubjectAlternativeName字段作为身份标识 - 不要仅依赖 CN 做权限判断——CN 可被伪造，应结合证书签名、有效期、是否在吊销列表（CRL/OCSP）中综合验证（Go 标准库默认不做 OCSP 检查）
- 常见做法是在中间件中统一提取并写入
c.Set("clientCN", cert.Subject.CommonName)，后续 handler 可按需使用 - 若证书验证失败（如过期、签名无效），
PeerCertificates为空切片，此时应直接返回http.StatusUnauthorized
开发与生产环境的关键差异点
自签名 CA 在开发阶段方便，但上线前必须切换为受信任的 CA 或企业内网 CA，否则客户端（尤其是 iOS/macOS）会拒绝建立连接。
- 开发可用
openssl快速生成：先建自签 CA，再用该 CA 签发客户端证书；服务端证书也必须由同一 CA 签发，否则ClientCAs无法验证 - 生产环境禁用
tls.InsecureSkipVerify，且不应将 CA 证书硬编码进二进制；建议通过文件挂载或配置中心动态加载 - 若后端服务还需透传证书信息（如给下游 gRPC 服务做二次鉴权），需手动把
PeerCertificates序列化为 PEM 后通过 header 传递，注意长度限制和 Base64 编码 - Gin 默认不处理 HTTP 重定向，若需
http://→https://跳转，必须额外启一个http.Server监听:80并执行 301 重定向——这个 server 不能启用 mTLS
真正难的不是写那几行 TLSConfig，而是确保 CA 信任链闭环、客户端证书分发可控、吊销机制可落地。很多团队卡在“测试能通，上线就拒连”，问题往往出在证书链缺失或客户端没导入根 CA，而不是代码逻辑。
