x509证书验证失败：192.168.100.42不在证书Subject或SAN中

Question

**问题描述：** 客户端访问服务端（IP：192.168.100.42）时，TLS握手失败，报错“x509: certificate is valid for example.com, not 192.168.100.42”。根本原因是该服务器证书的Subject Common Name（CN）未设为该IP，且证书扩展字段Subject Alternative Name（SAN）中未包含`IP:192.168.100.42`。自RFC 2818及现代浏览器/客户端强制要求起，仅依赖CN已不被信任；若需通过IP直连（如内网调试、K8s Pod通信或私有负载均衡），必须在签发证书时显式将目标IP加入SAN（类型为`IP Address`，而非DNS）。常见错误包括：使用OpenSSL默认配置生成证书时遗漏SAN、Kubernetes TLS Secret中引用了未含IP的证书、或Let’s Encrypt等公信CA拒绝为私有IP签发证书（因其不验证内网IP所有权）。解决方案是重签证书，确保`subjectAltName = IP:192.168.100.42`正确配置并启用X509v3扩展。

Answer 1

一、现象层：TLS握手失败的典型错误日志与表象特征

客户端（如curl -v https://192.168.100.42、Go HTTP client、Kubernetes kubelet）发起连接时，底层TLS库抛出明确校验失败错误：

x509: certificate is valid for example.com, not 192.168.100.42

该错误非网络连通性问题（TCP 443 可通），而是X.509证书身份绑定校验失败。现代TLS栈（OpenSSL 1.1.1+、BoringSSL、rustls、Go crypto/tls）均严格遵循RFC 6125（取代RFC 2818）——Subject CN 已被完全弃用作为主机名验证依据，必须依赖Subject Alternative Name（SAN）扩展字段进行精确匹配。

二、协议层：RFC演进与证书验证逻辑的强制变迁

RFC版本	关键要求	对IP地址的支持	现状兼容性
RFC 2818 (2000)	CN可作为默认主机名回退	未明确定义IP SAN语义	已废弃，仅历史兼容
RFC 5280 (2008)	定义SAN为标准扩展，支持dNSName、iPAddress等类型	iPAddress OID (172.16.31.10.5.2.1) 明确支持IPv4/IPv6字面量	现行X.509基础规范
RFC 6125 (2011)	废除CN用于服务器身份验证；强制要求使用SAN匹配	明确要求：若目标为IP，则必须存在匹配的iPAddress条目	主流客户端（Chrome/Firefox/curl/Go/Java 11+）强制执行

这意味着：即使证书CN设为192.168.100.42，只要SAN中缺失IP:192.168.100.42，所有合规TLS实现均拒绝建立连接。

三、生成层：OpenSSL签发中SAN被忽略的根本原因与修复路径

OpenSSL默认配置（openssl.cnf）中[req]段通常未启用subjectAltName扩展，且[req_extensions]未显式包含subjectAltName = @alt_names。更隐蔽的是：即使配置了subjectAltName，若未在[req]中设置req_extensions = req_ext，该扩展仍不会写入CSR或最终证书。

正确配置片段示例（需保存为san.cnf）：

[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
x509_extensions = req_ext

[req_distinguished_name]
C = CN
ST = Beijing
L = Haidian
O = MyOrg
CN = example.com

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.com
IP.1 = 192.168.100.42

签发命令必须显式引用该配置：

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout server.key -out server.crt \
  -config san.cnf -extensions req_ext

四、部署层：Kubernetes与私有CA场景下的典型误配模式

• K8s Ingress/TLS Secret误用：将仅含DNS:example.com的证书注入kubectl create secret tls my-tls --cert=server.crt --key=server.key，但Ingress后端Pod直连Service ClusterIP或NodePort时使用https://192.168.100.42:8443，触发IP SAN缺失报错。
• 私有CA自动化工具缺陷：Cert-Manager默认ClusterIssuer（如Vault或自建CFSSL）若未在solvers或usages中声明ip_sans，则无法为IP签发有效证书。
• Let’s Encrypt硬性限制：ACME v2协议明确禁止为私有IP（RFC 1918）签发证书，acme.sh --issue -x -d 192.168.100.42必然失败，必须转向私有PKI。

五、验证层：多维度确认证书SAN是否生效

使用以下命令交叉验证证书内容：

# 查看完整X.509结构（重点关注X509v3 Extensions）
openssl x509 -in server.crt -text -noout | grep -A1 "Subject Alternative Name"

# 检查是否为iPAddress类型（而非DNS）
# 输出应为：IP Address:192.168.100.42

# 验证TLS握手是否通过（模拟真实客户端行为）
echo | openssl s_client -connect 192.168.100.42:443 -servername 192.168.100.42 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

注意：-servername参数必须传入IP（SNI不推荐用于IP，但部分服务端仍需此字段避免ALPN协商失败）。

六、架构层：面向IP通信的零信任证书策略设计

graph LR
  A[客户端发起TLS连接] --> B{目标地址类型}
  B -->|DNS域名| C[验证SAN中dNSName匹配]
  B -->|IPv4/v6字面量| D[强制验证SAN中iPAddress精确匹配]
  C --> E[允许通配符*.example.com]
  D --> F[禁止通配符IP，必须显式列出每个IP]
  E & F --> G[双向mTLS场景：客户端证书也需含IP SAN]
  G --> H[证书轮换策略：IP变更时必须重签+滚动更新]

该流程图揭示：IP直连不是“临时调试手段”，而是生产级内网通信（如Service Mesh数据平面、裸金属API Server访问、边缘IoT设备管理）的核心路径，其证书策略必须纳入CI/CD流水线和PKI生命周期管理。