Go tls.Config.GetClientCertificate 怎样按请求选择客户端证书

在 Go 的双向 TLS 认证中，服务端会通过证书请求告诉客户端“我需要一张客户端证书”。如果客户端只有一套固定证书，可以直接设置 tls.Config.Certificates；如果要根据服务端给出的 CA、签名算法或 TLS 版本在多套证书之间做选择，就使用 tls.Config.GetClientCertificate。

官方文档：https://pkg.go.dev/crypto/tls#Config.GetClientCertificate

这个回调的关键不是自己重做 TLS 握手，而是读取 *tls.CertificateRequestInfo，从候选证书中选出兼容的一条并返回。回调返回错误会中止握手；返回一个内部证书链为空的 tls.Certificate，则表示本次不发送客户端证书，最终能否继续由服务端的认证策略决定。

先厘清回调解决的客户端认证问题

GetClientCertificate 是客户端侧的配置字段。它在服务端请求客户端证书时被调用，参数是 *tls.CertificateRequestInfo，而不是服务端选择证书时使用的 *tls.ClientHelloInfo。

两者可以这样区分：

所以，标题中的“按请求选择”指的是服务端的 CertificateRequest 形成的请求信息，而不是 HTTP 请求、SNI 或业务接口参数。需要先把这一层边界分清，后面的回调代码才不会放错位置。

CertificateRequestInfo 里有哪些筛选条件

官方类型 tls.CertificateRequestInfo 公开了几组与证书匹配相关的字段：

• AcceptableCAs：服务端希望证书由哪些根 CA 或中间 CA 签发，内容是 DER 编码的 X.501 名称；为空表示服务端没有 CA 偏好。
• SignatureSchemes：服务端愿意验证的签名方案。
• Version：这条连接协商出来的 TLS 版本。

证书选择逻辑可以先从“是否满足服务端声明的约束”开始，而不是按证书文件名猜测。对于候选证书，还可以调用 CertificateRequestInfo.SupportsCertificate 做兼容性判断；它返回非空错误时，就不应把该证书作为本次结果。

func chooseCertificate(info *tls.CertificateRequestInfo, candidates []tls.Certificate) (*tls.Certificate, error) {
	// 依次询问候选证书是否满足服务端声明的 CA、签名方案和版本条件。
	for i := range candidates {
		candidate := &candidates[i]
		if err := info.SupportsCertificate(candidate); err == nil {
			// 返回原切片中的证书，避免复制私钥和证书链。
			return candidate, nil
		}
	}

	// 一个候选都不兼容时，把原因交给 TLS 握手调用方处理。
	return nil, fmt.Errorf("no client certificate matches the server request")
}

上面的函数只表达选择策略。完整代码还需要导入 crypto/tls 和 fmt，并且候选证书必须提前从受信任的证书与私钥来源加载。不要在回调中临时读取不受控的文件或修改共享的 tls.Certificate，否则回调的耗时和并发行为会变得难以管理。

按请求返回兼容的 tls.Certificate

一个典型的配置方式是把证书加载和证书选择分开：初始化阶段准备候选证书，握手阶段只根据 CertificateRequestInfo 做匹配。

package main

import (
	"crypto/tls"
	"fmt"
)

func clientTLSConfig(candidates []tls.Certificate) *tls.Config {
	return &tls.Config{
		MinVersion: tls.VersionTLS12,
		GetClientCertificate: func(info *tls.CertificateRequestInfo) (*tls.Certificate, error) {
			// 让标准库按服务端声明的条件检查每条候选证书链。
			for i := range candidates {
				candidate := &candidates[i]
				if err := info.SupportsCertificate(candidate); err == nil {
					// 返回的证书不要在回调外继续修改。
					return candidate, nil
				}
			}

			// 没有可用证书时明确返回错误，避免把失败变成模糊的握手报错。
			return nil, fmt.Errorf("no compatible client certificate")
		},
	}
}

这里的 candidates 只是示意性的已加载证书集合。真正的项目通常会在启动阶段使用 tls.LoadX509KeyPair 或 tls.X509KeyPair 完成加载，并检查返回错误；回调不负责解析 PEM，也不负责从服务端下载证书。

空证书、错误和重复调用分别意味着什么

回调返回值有三个容易混淆的边界：

1. 返回非空错误：TLS 中止握手，并把这个错误返回给调用方。适合“没有任何证书满足服务端要求，连接就不应继续”的场景。
2. 返回非空 *tls.Certificate，但其 Certificate 字段为空：客户端不发送证书。服务端如果要求必须有有效客户端证书，可能随后中止握手。
3. 返回兼容的证书：TLS 使用这条证书链完成客户端认证；证书本身和私钥必须保持一致，返回后也不要修改。

官方文档还说明，这个回调可能因为重新协商或 TLS 1.3 的场景对同一连接被调用多次。因此回调应当是可重复调用的：读取只读候选集合、不要累加全局状态、不要把“第一次调用”当成永远成立的事实。如果需要记录选择原因，建议使用并发安全的日志或指标，并避免把私钥、完整证书内容写入日志。

GetClientCertificate 与 Certificates 怎么取舍

客户端做证书认证时，Certificates 和 GetClientCertificate 都能提供证书来源，但配置语义不同：

最小决策规则是：没有动态选择需求时，优先使用静态 Certificates；确实需要自定义选择时，再使用 GetClientCertificate，并在回调内把匹配失败处理成明确错误。不要同时设置两套配置后，再期待标准库把回调结果和 Certificates 自动合并。

常见问题

GetClientCertificate 能不能选择服务端证书？

不能。它属于客户端证书认证；服务端选择自己的证书使用 GetCertificate 或其他服务端配置入口。

AcceptableCAs 为空是不是代表任意证书都能用？

不是。它只表示服务端没有通过 CA 名称给出偏好，仍然要考虑签名方案、证书用途、私钥匹配和服务端最终认证策略。

回调里返回 nil, nil 可以吗？

不建议也不符合回调契约。没有可用证书时，应返回一个明确错误；如果业务允许不发送证书，应返回非空的 tls.Certificate，但让它的 Certificate 字段为空。

为什么不能在回调中修改共享证书？

同一配置可能被多个连接复用，而官方要求返回的证书不要再修改。把证书加载、候选集合和选择逻辑分成只读阶段，可以减少握手并发下的数据竞争和不可预测行为。

小结

GetClientCertificate 解决的是“服务端请求客户端证书后，客户端返回哪一条证书链”的问题。用 CertificateRequestInfo.SupportsCertificate 检查候选证书，可以把 CA、签名方案和 TLS 版本等条件交给标准库判断；匹配失败时返回明确错误，允许不发证书时返回空证书对象。若证书集合固定，就直接使用 Certificates，不要让回调和静态配置的职责混在一起。