“certificate doesn’t match private key”错误源于证书公钥与私钥数学不配对，需用openssl校验modulus一致性；中间证书不可单独配私钥，必须与服务器证书合并为fullchain.pem后一次性加载。
tls.LoadX509KeyPair 报 “certificate doesn’t match private key” 怎么快速定位
这错误不是证书“坏了”，而是 Go 在加载时发现 certFile 里的公钥和 keyFile 里的私钥数学上不配对。常见于拼错文件、用错中间证书、或私钥被意外替换。
先做三件事：
- 用
openssl x509 -noout -modulus -in cert.pem | openssl md5和openssl rsa -noout -modulus -in key.pem | openssl md5分别算两个 MD5，必须完全一致 - 确认
cert.pem是你的域名证书（leaf），不是中间证书或根证书；key.pem必须是你生成该证书时用的原始私钥 - 检查是否误把
fullchain.pem当作cert.pem传给了tls.LoadX509KeyPair——它只接受单张证书，不能是链
为什么中间证书单独配私钥一定会失败
tls.LoadX509KeyPair 的语义非常强硬：它要求传入的证书必须能用该私钥签名验证。中间证书（Intermediate CA）是 CA 签发的，它的私钥在 CA 手里，你手上的服务器私钥根本无法签名它。
典型误操作：
立即学习“go语言免费学习笔记（深入）”；
- 把
intermediate.crt和server.key一起传给tls.LoadX509KeyPair - 在代码里调两次
tls.LoadX509KeyPair，一次 load leaf，一次 load intermediate - 试图用
tls.X509KeyPair从内存字节构造中间证书 + 私钥
这些都会触发 x509: certificate specifies an incompatible key usage 或静默返回空 tls.Certificate{}，后续握手直接失败。
证书链不完整导致的“校验通过但客户端连不上”
服务端证书本身合法，tls.LoadX509KeyPair 也成功了，但 iOS、Java 或某些浏览器仍报 x509: certificate signed by unknown authority ——问题不在服务端证书，而在没把中间证书发给客户端。
正确做法是：把 leaf 证书和 intermediate 证书按顺序拼成一个 PEM 文件（如 fullchain.pem），再传给 http.ListenAndServeTLS("fullchain.pem", "key.pem") 或 tls.LoadX509KeyPair("fullchain.pem", "key.pem")。
注意点：
- 顺序必须是 leaf 在前、intermediate 在后；根证书（Root CA）**不能**放进这个文件
- 文件必须用 LF 换行，不能有 BOM、空行、注释或多余空格
- 私钥文件权限必须是
0600（Linux/macOS），否则 Go 直接拒绝读取
客户端证书校验失败的隐藏原因：CA 列表没发出来
服务端启用了 mTLS（ClientAuth: tls.RequireAndVerifyClientCert），客户端也配置了证书，但连接时服务端日志报 tls: client didn't provide a certificate，而 curl 却能通——大概率是服务端没把可信 CA 列表发给客户端。
Go 客户端默认行为很严格：只有收到服务端 CertificateRequest 消息里带了可识别的 CA Subject（DN），才会自动匹配并发送本地证书。Nginx 需要同时配置：
ssl_verify_client on-
ssl_client_certificate /path/to/ca-bundle.crt（必须是 CA 根或中间证书，且内容要能被 Go 解析出 DN）
否则 Go 不会主动发证，表现就是“没证书送上来”，而 curl 会强行发，掩盖了服务端配置缺陷。
最易被忽略的一点：tls.LoadX509KeyPair 成功只代表文件能解析、密钥能配对；它不保证链完整、不检查有效期、不校验 SAN 域名、也不验证 CA 可信度——那些都发生在 TLS 握手阶段，错误往往延迟暴露，排查时得往下游看。
