K8s v1.22 Webhook报tls: bad certificate错误的版本差异原因咨询

问题背景 #

使用以下Helm配置生成证书用于Mutating Webhook时，在K8s v1.22版本出现错误remote error: tls: bad certificate，但该配置在v1.18.20版本可正常运行，推测为证书问题。

旧Helm证书生成配置：

# generate the certs
{{- if .Values.mutatingWebhook.enabled }}
{{- $cn := printf "%s.%s.svc" ( include "mutate.service.name" . ) .Release.Namespace }}
{{- $ca := genCA "mutate-admission-ca" 36500 -}}
{{- $cert := genSignedCert $cn nil nil 36500 $ca -}}

通过添加两个subjectAltNames修改配置后，实现了两个版本的适配：

# generate the certs
{{- if .Values.mutatingWebhook.enabled }}
{{- $name := printf "%s" (include "podinjector.service.name" .) }}
{{- $cn:= list ( printf "%s.%s" $name .Release.Namespace ) ( printf "%s.%s.svc" $name .Release.Namespace ) ( printf "%s.%s.svc.cluster.local" $name .Release.Namespace ) }}
{{- $ca := genCA "podinjector-admission-ca" 36500 -}}
{{- $cert := genSignedCert $name nil $cn 36500 $ca -}}

版本差异原因 #

• K8s TLS验证逻辑升级：在K8s 1.18及更早版本，API Server调用Webhook Service时，仅会使用service-name.namespace.svc这一个域名做TLS证书校验，旧配置中把CN设为该域名就能通过验证。但从K8s 1.20+开始，API Server对Service的访问会使用更完整的集群内部FQDN（service-name.namespace.svc.cluster.local），甚至在部分场景下会用短域名service-name.namespace访问，此时证书仅靠单个CN无法覆盖所有可能的验证域名，就会触发证书不匹配错误。
• SAN的必要性：TLS证书的Subject Alternative Names（SAN）是CN的扩展，用来指定证书可匹配的多个域名。K8s新版本中API Server会校验访问域名是否在证书的SAN列表（或CN）中，旧配置没有设置SAN，仅靠CN无法覆盖新版本中API Server使用的所有访问域名，导致验证失败。

关于兼容性改动的判定 #

这属于兼容性小改动：

• 改动仅扩展了证书的SAN条目，没有修改Webhook的核心逻辑、依赖或部署结构；
• 新增的SAN覆盖了新旧版本API Server可能使用的所有访问域名，既能适配K8s 1.22+的严格验证规则，也能兼容旧版本（旧版本API Server只要在证书中找到匹配的域名就会通过验证，多SAN条目不会影响旧版本的正常运行）。

内容的提问来源于stack exchange，提问作者moluzhui