登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  Golang >  Go问答

Go 1.27 tls.Config 的 LocalCertificate 到底是谁的证书:握手观测字段边界

来源:17golang原创

时间:2026-09-04 01:47:57 218浏览 收藏

排查 HTTPS 双向认证时,最容易看错的不是证书内容,而是证书属于哪一端。Go 1.27 给 tls.ConnectionState 增加了 LocalCertificate,正好能把“本端在握手中呈现了什么”记录下来;它和原有的 PeerCertificates 方向相反,不能互换。还要留意会话恢复:恢复连接不重新呈现证书链,LocalCertificate 为空并不代表证书配置丢失。

记忆方式很简单:LocalCertificate 看自己发给对端的链,PeerCertificates 看对端发来的链;先看 DidResume,再解释空值。

要点速览
  • Config.Certificates 是本端候选链,握手后用 LocalCertificate 看实际呈现链。
  • PeerCertificates[0] 是对端叶子证书,VerifiedChains 是本端完成验证后得到的链。
  • DidResume=true 时不要用空的 LocalCertificate 判断证书选择失败。

握手现场先分清“本端”和“对端”

先把字段放回 TLS 的两端。客户端或服务端通过 tls.Config.Certificates 提供一组本端证书链,Go 会根据对端能力选择合适的一条;服务端也可能通过 GetCertificate 动态返回链。握手结束后,ConnectionState 是连接视角的结果,不是配置对象的回显。

字段它描述谁主要用途
LocalCertificate本端查看握手中呈现给对端的原始链
PeerCertificates对端查看对端发送的已解析证书,第一张是叶子证书
VerifiedChains对端验证结果查看从叶子到信任根的验证链

因此,客户端日志里“服务端证书不对”应先看 PeerCertificates[0];服务端日志里“我到底发了哪张客户端证书”才适合看 LocalCertificate[0]。这一步能排除大量把观察方向写反的误诊。

LocalCertificate 返回什么,什么时候为空

LocalCertificate 的类型是 [][]byte,每个元素是一张 DER 编码证书,顺序就是本端在握手中呈现的证书链。它不是 []*x509.Certificate,需要用 x509.ParseCertificate 解析后再读取 Subject、DNSNames 等字段。

Go 1.27 TLS 本端配置、握手连接与 LocalCertificate 证书链的边界关系
图1:查看配置候选链、TLS 握手和 LocalCertificate 的静态关系,判断记录到的是本端呈现链还是对端证书。

空值有一个关键解释:官方文档规定,恢复会话时 DidResume 为 true,LocalCertificate 不填充。也就是说,下面的判断顺序比“空就报警”可靠:

cs := tlsConn.ConnectionState()
if cs.DidResume {
    log.Printf("resumed TLS session; local chain is not repopulated")
} else {
    log.Printf("local certificates presented: %d", len(cs.LocalCertificate))
}

非恢复连接仍然为空时,再检查本端是否真的走了客户端认证、服务端是否选中了证书,以及动态回调是否返回有效链。不要把 Config.Certificates 的候选数量直接当成实际发送数量。

用 ConnectionState 做一次可验证的字段核对

观测代码只需保留端点、恢复状态和叶子证书三个层次。解析本端链时读 LocalCertificate[0],解析对端链时读 PeerCertificates[0];两张叶子证书的 Subject 不同是正常现象,不能因此判定握手异常。

ConnectionState 中 LocalCertificate、PeerCertificates、VerifiedChains 与 ServerName 的核对关系
图2:对照本端链、对端链、验证链和 ServerName,判断证书主体与主机名核对是否落在正确字段上。
cs := tlsConn.ConnectionState()
log.Printf("resume=%t local=%d peer=%d verified=%d server=%s",
    cs.DidResume, len(cs.LocalCertificate), len(cs.PeerCertificates),
    len(cs.VerifiedChains), cs.ServerName)
if len(cs.LocalCertificate) > 0 {
    localLeaf, err := x509.ParseCertificate(cs.LocalCertificate[0])
    if err == nil { log.Printf("local leaf=%s", localLeaf.Subject.String()) }
}
if len(cs.PeerCertificates) > 0 {
    log.Printf("peer leaf=%s", cs.PeerCertificates[0].Subject.String())
}

ServerName 是 SNI/主机名相关信息,适合和对端叶子证书的 SAN 一起看;它不是证书颁发者。VerifiedChains 为空也要结合配置解释:跳过默认验证,或服务端没有要求验证客户端证书时,都可能没有验证链。

常见问题:恢复会话和双向认证如何处理

恢复会话为什么看不到 LocalCertificate?

恢复连接复用既有会话状态,不重新呈现证书链,所以按 DidResume 分支记录;若必须每次握手都做检查,应把策略放进 VerifyConnection 或连接外部的会话指标。

服务端的 PeerCertificates 为空是不是客户端证书失效?

不一定。服务端只有在客户端发送证书时才会有对端证书;ClientAuth 为默认的 NoClientCert 或客户端未被要求认证时,空值可能就是正常结果。

LocalCertificate 能不能直接当作验证结果?

不能。它回答“本端呈现了什么”,不回答对端是否信任;验证对端要看 PeerCertificatesVerifiedChains 和实际校验错误。

把日志按 DidResumeLocalCertificatePeerCertificatesVerifiedChains 四个字段分层记录,基本就能把“证书没发出去”“对端证书不对”和“恢复连接没有重新填充”区分开。Go 1.27 的新增字段解决的是观测缺口,不能替代证书验证策略本身。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>