凌晨两点多值班群里弹出一条告警Certificate for xxx.xxx.xxx.com doesnt match any of the subject alternative names: [xxx..com]。同一时间另外几台机器上的日志也在刷屏有no required ssl certificate was sent有curl: (60) ssl certificate problem还有一条更让人头大的unable to push signed certificate to host 192.168.2.222。看起来是四五个不同的毛病实际上它们大多指向同一件事——TLS 证书和实际访问入口之间对不上号而运维最容易忽略的那一环恰好就是证书里的 subject alternative names 列表。这篇东西写给谁看如果你正在被 HTTPS 握手失败、证书校验不过、证书推不到目标主机这类问题折腾不管是刚接手一台服务器的同学还是管着几十套业务域名和一堆内网系统的运维、后端、实施工程师都能直接拿去用。我会把这条报错的来龙去脉拆开讲清楚告诉你它到底是谁在校验谁、SAN 列表的匹配规则有哪些硬边界、三条命令怎么在五分钟内定位真相、四条修复路线怎么选最后把从生成 CSR 到推送部署的完整流程和踩坑清单摆出来。不聊虚的全是能上手的东西。1. 把报错原文拆开看先搞清楚谁在校验谁这条报错长得像服务端吐出来的其实不是。它来自客户端的主机名校验环节也就是发起 HTTPS 请求的那一方在握手拿到服务端证书之后拿自己心里想访问的那个名字去比对证书里写的名字。对不上就地抛错连接直接断掉请求根本发不出去。1.1 报错是客户端发出来的不是服务端很多人第一反应是证书没装好跑去目标服务器翻 nginx 配置、重启进程折腾半天没变化。原因就在这里证书本身可能装得好好的服务端也没写错是客户端拿着esign.example.com去敲 9100 端口而证书里只写了example.com两边谈不拢。这个区别决定了排查方向。服务端问题通常表现为端口不通、握手直接 reset、返回 502而 SAN 不匹配是握手能走到证书交换但校验阶段被拒服务端的访问日志里往往能看到请求进来了甚至是 200客户端却报错因为它压根没把请求发出去。所以只要看到doesnt match any of the subject alternative names这句话第一件事就是别动服务端先看客户端拿到的那张证书到底长什么样。还有一个容易被忽略的点同一个地址不同客户端的表现不一样。浏览器可能给你一个您的连接不是私密连接的页面Java 客户端抛javax.net.ssl.SSLHandshakeExceptionPython requests 说hostname doesnt matchGo 则告诉你x509: certificate is valid for ... not ...。措辞不同本质同一个。看到这些不同版本的说法别当成不同的故障处理。1.2 subject alternative names 才是今天的唯一裁判早年证书靠 Common Name 字段来标识域名CN 里写什么客户端就认什么。那套规则现在已经被彻底弃用。Chrome 从 58 版本起、Firefox 从 48 版本起都明确不再把 CN 当作域名标识只看 SAN 扩展。RFC 6125 和 RFC 2818 里把这件事写得很清楚主机的身份标识优先且仅从 subjectAltName 扩展里取。这就解释了一个非常经典的困惑——明明 CN 里写的就是访问域名为什么还报不匹配去把证书拖出来看多半是 CN 对了SAN 里没有或者 SAN 里写了另一个名字。尤其是签发流程里那一栏公用名填得漂漂亮亮SAN 那一栏空着或者随手填了个主域名签发出来就是坑。我见过最典型的一种情况老证书是单域名证书CN example.com没有任何 SAN。业务从example.com迁到esign.example.com证书没换客户端访问新域名直接撞墙。运维说我们证书明明还在有效期对有效期没问题问题是你访问的名字不在它认可的名单里。1.3 匹配规则的两条硬边界SAN 的匹配不是模糊搜索也不是包含关系它是逐条精确比对。这里有两类写法需要掰扯清楚。第一类是通配符。*.example.com只能靠一个标签去替换它能匹配esign.example.com、mail.example.com但匹配不了example.com本身也匹配不了a.b.example.com。通配符还必须出现在最左侧写成esign.*.com或者w*.example.com都是无效写法签发工具可能会直接拒绝也可能签出来但客户端不认。第二类是类型区分。SAN 是一个列表里面每一项都有类型常见的有 DNS 名、IP 地址、邮箱、URI。用域名访问客户端只会去匹配 DNS 类型的条目用 IP 访问只会去匹配 IP 类型iPAddress的条目。你用192.168.2.222去访问一张只写了域名的证书它当然找不到能对上的项——因为证书里根本没有 IP 类型的条目一个都没有。这不是没写全这是类型都没对上。同样的道理用内网短名esign、用localhost、用带后缀的 FQDN都属于不同的名字。证书是白名单思维写进列表里的才认没写的一律不认。理解这一点后面所有排查都会顺很多。2. 三类高发根因对号入座报错信息只有一句话背后的成因却分好几个流派。我按这些年遇到的频率排了个序你可以先对号入座再去验证。2.1 域名换了、入口加了证书还停在上一代这是出现次数最多的一类。业务扩容、系统更名、从单一域名变成多域名对外、新增了一个移动端入口配置全改完了证书还是当初那一张。以前只有www和裸域现在多出来esign、api、m证书里一个都没有。还有一种变体是端口升级。原本 HTTP 的 8080 换成了 HTTPS 的 9100证书是从别的系统里借用过来的。借来的证书当然只认它原来的主人新系统访问必然报错。这种借证书的操作在内部系统里特别常见尤其是测试环境往生产环境搬的时候顺手复制了一份证书文件域名对不上也没人注意。判断方法很简单把证书的 SAN 列表打印出来和实际会用到的所有访问入口做一次差集。差出来的那些就是这次报错的直接原因。2.2 用 IP、内网短名、localhost 去访问第二类是访问方式本身就有问题。这种情况在部署脚本、健康检查、监控探针里特别多。写脚本的人图省事直接curl https://192.168.2.222:9100/health证书里只写了域名探针就天天报错。还有一类是反向网关做了 Host 头改写。客户端访问域名 A网关把请求转发到后端的域名 B后端服务用 B 的证书响应客户端拿到的是 B 的证书校验的是 A 的名字一样对不上。这种情况排查起来最容易跑偏因为你在客户端这一侧怎么测都是失败的必须去网关上看转发规则。2.3 通配符证书的覆盖盲区第三类是通配符的边界问题。买了*.example.com以为全站通吃结果访问a.b.example.com就翻车。也有反过来证书是*.b.example.com但配置里的入口写成了b.example.com差一个层级照样不匹配。还有一种坑是大小写和尾点。Example.com.这种带尾点的写法在某些 DNS 配置里合法但证书匹配时可能会出问题。规范上匹配是大小写不敏感的但中间如果有自定义网关做字符串比较就可能翻车能统一成小写、去掉尾点就别给自己找麻烦。下面这张表把常见报错和真实原因对照一下遇到问题可以先扫一眼报错原文片段出现层真实含义优先排查方向doesnt match any of the subject alternative names客户端主机名校验访问名不在证书 SAN 列表里打印 SAN与实际入口做差集no required ssl certificate was sent服务端双向认证客户端没带证书或证书未被信任检查双向认证配置与客户端证书curl: (60) ssl certificate problemcurl证书链校验失败可能是链不全或不受信打印整条链检查中间证书fatal alert: bad_certificateTLS 握手层对端认为收到的证书不可用检查证书完整性、格式、双向认证配置unable to get local issuer certificateopenssl verify找不到签发者缺中间证书或根证书拼接 fullchain更新本地信任库unable to push signed certificate to host证书管理平台推送或重载环节失败登录方式、目标路径、reload 命令、时间这张表可以当速查用但别把它当结论。同一句报错在不同环境里含义会有偏移最终还是要靠下面这几条取证命令落锤。3. 五分钟取证三条命令看清证书真面目排查这类问题最忌讳的是猜。你猜是链不全他猜是网关改写讨论半小时不如敲一条命令。下面这几条我基本是条件反射遇到 HTTPS 问题先跑一遍。3.1 openssl s_client 直接拉取链上实体第一条命令用来把服务端真正吐出来的证书抓下来openssl s_client -connect esign.example.com:9100 \ -servername esign.example.com /dev/null 2/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName这条命令有三个关键点。-servername一定要加它模拟 SNI告诉前置服务我要访问的是这个域名多域名共用同一 IP 的场景下不加这个参数拿到的可能是默认站点的证书看到的 SAN 和你实际请求的完全不是一回事。/dev/null是为了让 s_client 读完就退出不然它会一直挂着等输入。最后接一段openssl x509做解析只输出你要的几项。输出里重点看三行subject 里的 CN 现在只是人类可读的标签不用太较真dates 的 notBefore 和 notAfter 用来确认有效期遇到过服务器时间偏差导致证书还没生效的情况报错会写 not yet valid也很容易被误判成 SAN 问题subjectAltName 那一行才是关键把里面的每一项抄下来跟你实际要用的访问入口逐条比。如果输出里压根没有 subjectAltName 这一行那基本可以确定问题所在了这是一张纯 CN 证书现代客户端一律不认。3.2 curl 的几种失败面貌与含义对照第二条命令用 curl 复现它能给出更贴近真实业务的反馈curl -vI https://esign.example.com:9100/ 21 | grep -iE subject|issuer|SSL certificate|CN-v打开详细输出-I只发 HEAD 请求减少干扰。grep 后面那串是为了把证书相关信息从一大堆输出里挑出来。curl 的报错文本其实很有信息量。curl: (60) ssl certificate problem: unable to get local issuer certificate说的是链不完整或者本地没有根证书跟 SAN 没关系curl: (51)是证书不受信curl: (60)后面跟的是证书已过期这是另一条路径。只有明确提到 hostname 或者 subject alternative names 的才是本文讨论的这个问题。想跳过 DNS 和网关的干扰直接用--resolve把域名绑到指定 IP 上测curl -vI --resolve esign.example.com:9100:192.168.2.10 https://esign.example.com:9100/这一招在排查网关改写 Host 头的时候特别好用。如果--resolve直连源站成功走正常域名失败问题就在网关那一层不在证书本身。3.3 换个网络位置测区分证书问题和链路问题第三条不是命令是习惯。同一个地址从办公网、从服务器本地、从另一台同网段机器各测一次。三次结果一致问题大概率在证书或者配置结果不一致就要怀疑网络路径上有没有别的东西在做 TLS 拦截或者证书替换。顺手再确认两件事目标主机的系统时间和时区date -u看一眼时间偏差超过几分钟证书的生效时间判断就会出错目标域名的 DNS 解析dig short esign.example.com确认是不是解析到了你以为的那台机器。我曾经花了一晚上排查一个证书不匹配的问题最后发现是某台机器上的 hosts 文件把域名指到了另一台老服务器上老服务器上的证书还是两年前的。命令跑得再多也抵不过先看一眼解析结果。4. 四条修复路线与取舍逻辑定位清楚之后就是选方案。这四条路线我按推荐程度排序实际选择要结合业务量、客户端的可控程度和停机窗口来定。4.1 重新签发把 SAN 列表一次性做全首选最干净的做法就是重新签一张证书把当前和未来一段时间内会用的所有名字都放进 SAN 列表。域名、必要的 IP、内网短名如果确实有客户端在用一次性列齐。这里说的列齐不是随便堆。SAN 列表越长签发时的验证成本越高某些签发方式对每个条目都要做校验。合理的做法是把当前真实在用的入口全覆盖再加上已经立项、三个月内会上线的入口留一档缓冲。别为了以后可能用把三十个域名全塞进去管理成本会反过来咬你。如果预算允许直接上通配符加多域名组合比如*.example.com配上几个跨域名的条目。但要记住通配符只覆盖一级跨层级的需求得单独列出来。4.2 保留证书、改访问入口统一域名收口有时候证书动不了比如是外部签发的、走流程要两周那就反过来源头改访问方式。把所有调用方的地址统一成证书里已经覆盖的那个域名。具体做法包括改应用的配置文件、改健康检查脚本、改监控探针的目标、改网关的转发规则。这一条听起来简单实际工作量往往比重新签证书还大尤其是调用方分散在十几个系统里的时候。但它有个好处是治本——把域名收口之后以后再也不会出现某个脚本偷偷用 IP 访问这种事。做这一步的时候一定要把调用方清单列出来别改了一半。我见过改完主应用忘了改定时任务结果白天一切正常凌晨批处理全线报错。4.3 Java/Python 客户端侧的额外处理与 keystore 同步Java 生态有个特别容易踩的坑证书换了服务端生效了Java 应用还在用旧的信任库。这时候报的错可能不是 SAN 不匹配而是PKIX path building failed或者unable to find valid certification path但根子上还是证书问题。如果服务端证书是从公有签发机构签发的Java 一般不用额外操作。如果是内部签发机构签发的就得把根证书和中间证书导入到 JVM 的信任库或者导入到应用自己的 keystore 里keytool -importcert -alias esign-internal-ca \ -file internal-ca.crt \ -keystore /opt/app/conf/truststore.jks \ -storepass changeit -noprompt导入之后还要确认应用启动参数里指定了正确的信任库路径java -Djavax.net.ssl.trustStore/opt/app/conf/truststore.jks \ -Djavax.net.ssl.trustStorePasswordchangeit \ -jar app.jarPython 这边相对宽松如果有内部签发机构certifi包里没有对应根证书就会报SSLCertVerificationError。稳妥的做法是维护一份自有的 CA bundle通过环境变量指过去而不是在代码里写verifyFalse。后者在测试环境用惯了很容易被带到生产环境去那就等于把校验彻底关了。4.4 不建议的三种临时手段与它们的后果第一个是关掉校验。curl -k、Python 的verifyFalse、Java 里自定义一个永远返回 true 的 TrustManager这些手段确实能让请求通但等于把中间人攻击的大门敞开了。生产环境用这个跟把数据库密码贴在公告栏上差不多。第二个是改 hosts 把域名指到别的机器上。这招在临时联调时偶尔用用还行一旦写进部署脚本就会变成那种半年后没人知道为什么这台机器访问的证书和别人不一样的历史遗留问题。第三个是硬编码证书指纹做校验。指纹校验本身没错但用在证书轮换频繁的系统里每次换证书都得改一遍代码属于给自己挖坑。5. 从 CSR 到推送主机完整实操讲完思路来一遍完整流程。以一张包含域名和 IP 的内部证书为例走一遍生成、校验、部署、推送的链路。5.1 生成带完整 SAN 的 CSR先生成私钥和配置文件。用配置文件的方式比命令行传参更清晰也方便复用openssl genrsa -out esign.key 2048 chmod 600 esign.key配置文件san.cnf这样写[req] default_bits 2048 prompt no default_md sha256 distinguished_name dn req_extensions req_ext [dn] O Example Org OU Platform CN esign.example.com [req_ext] subjectAltName alt_names [alt_names] DNS.1 esign.example.com DNS.2 esign.example.org DNS.3 api.example.com IP.1 192.168.2.222几个细节值得说。CN 字段现在只作为标签保留写主域名即可别指望它起作用。req_extensions必须指到req_ext否则生成出来的 CSR 里根本没有 SAN签出来的证书也就没有。IP 条目要用IP.1这种写法不能写成DNS.x两者类型不同。生成 CSRopenssl req -new -key esign.key -out esign.csr -config san.cnf生成完先自检一下看看 SAN 有没有真的写进去openssl req -in esign.csr -noout -text | grep -A3 Requested Extensions这里的输出如果看不到 subjectAltName就回去检查配置文件的段落名有没有对上。这一步省了后面签发出来的证书就得从头再来一遍。5.2 证书链拼接与顺序校验拿到签发机构返回的证书之后第一件事是确认链的完整性。绝大多数证书装上了但还是报错的情况都出在这一步。完整链的顺序是服务器证书在最前然后是中间证书最后是根证书根证书通常不放因为客户端自己持有。拼接命令很简单cat esign.crt intermediate.crt esign.fullchain.crt拼完验证一下顺序和数量openssl crl2pkcs7 -nocrl -certfile esign.fullchain.crt \ | openssl pkcs7 -print_certs -noout输出里会按顺序列出每个证书的 subject 和 issuer。检查两点第一个证书的 subject 应该是你的域名后面每个证书的 issuer 应该等于下一个证书的 subject链条首尾相接。如果断在某个位置说明中间证书漏了。顺便用签发机构的根证书验证一遍openssl verify -CAfile root-ca.crt -untrusted intermediate.crt esign.crt返回OK才算过关。如果返回unable to get local issuer certificate说明中间证书没带上或者顺序不对跟 SAN 没关系但同样会让客户端握手失败。5.3 部署到前置服务与进程重载证书文件放好之后配置要指向 fullchain 而不是单独的服务器证书。以常见的七层入口为例server { listen 9100 ssl; server_name esign.example.com; ssl_certificate /etc/nginx/certs/esign.fullchain.crt; ssl_certificate_key /etc/nginx/certs/esign.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; location / { root /opt/esign/web; } }改完先做配置检查再重载顺序别反nginx -t nginx -s reloadnginx -t通过再 reload能挡掉大部分手误导致的配置事故。重载之后立刻用第三节那条openssl s_client命令拉一遍确认生效的确实是新证书。文件权限也别忽略。私钥建议600属主设成运行前置服务的账号。有的环境开了 SELinux证书文件从别的目录拷过去会带上错误的上下文标签进程读不到日志里报的却是 permissions denied容易被误认为证书格式问题。遇到这种情况用restorecon -Rv /etc/nginx/certs修一下上下文。5.4 unable to push signed certificate to host 排查清单这条报错大多出现在证书管理平台或者自动化部署工具里它只告诉你推失败不告诉原因。我整理过一份排查顺序按这个走基本能覆盖九成情况。检查项具体动作常见结果登录通道用同一套凭据手动登录目标主机密钥权限过宽、账号被锁、端口被封目标路径确认证书目录存在且可写目录被删、磁盘满、只读挂载重载命令手动执行一次 reload 命令看退出码配置语法错误、进程未启动系统时间目标主机date -u与源端对比时间偏差导致证书未生效文件权限检查私钥属主与权限位属主错误、权限过宽被拒安全策略查看安全模块日志上下文标签不匹配进程读不到文件批量场景确认是哪一台失败是否整体回滚单机网络抖动导致整批失败我遇到过一次特别隐蔽的某台主机的磁盘根分区只剩 30MB证书文件写进去了一半进程重载时报文件格式错误。这条报错在平台上显示的和推送失败混在一起很不容易分辨。后来在推送流程里加了一步写后校验把文件大小和指纹比对一遍才把这类问题拦下来。6. 常见问题速查表与避坑清单排查到最后我把这些年高频出现的问题整理成几个小节遇到类似的可以直接对照。6.1 十类报错对照速查现象最可能的原因一句话验证SAN 不匹配域名写法正确证书本身没有 SAN 或 SAN 里是旧域名打印 subjectAltName 逐条对比用 IP 访问报 SAN 不匹配证书里没有 iPAddress 条目看 SAN 里有没有 IP 类型通配符证书仍不匹配跨层级访问通配符只覆盖一级数一数域名有几段证书在哪都报错访问名与证书名根本不是一个域名对比访问地址与 SAN换个网络就正常路径上有 TLS 拦截或网关改写直连源站与走网关各测一次报链不完整只部署了服务器证书漏了中间证书拼接 fullchain 后重测双向认证场景报未带证书客户端没配证书或服务端要求过严检查双向认证开关和客户端证书推送失败但手动能登自动化工具的凭据或权限不对用同凭据手动跑一遍重载后仍然是旧证书有多份配置或多个进程监听全局搜 9100 端口配置时间相关报错主机时间偏差证书未生效或已过期对比两端 UTC 时间6.2 我踩过的三个坑第一个坑是只看 CN 不看 SAN。刚入行那会儿排查一个证书问题CN 字段写得完全正确我死活想不通为什么浏览器不认。后来才知道现代浏览器早就把 CN 忽略了。从那以后我看证书第一眼就是找 SAN找不到 SAN 直接判定问题。第二个坑是忽略 SNI 参数。多域名共享同一 IP 的场景下不加-servername拿到的可能是默认站点的证书你照着默认站点的 SAN 去排查方向从一开始就偏了。这个坑我在同一个项目里踩过两次第二次是因为换了台机器忘了。第三个坑是改了配置没做语法检查。有一次在高峰期直接 reload配置里少了个分号服务直接起不来五分钟的业务中断。从那以后我给自己定了条死规矩任何前置服务的配置改动先-t再 reload两步之间的间隔不超过五秒但顺序绝不能反。还有个心得值得一提把排查过程截图存下来。证书这东西有效期动辄一年一年后遇到同一个系统的同类问题谁也想不起当初是怎么解决的。留下几张关键命令的输出截图配上日期和当时的配置摘要下次能省好几个小时。7. 长效治理让证书问题不再半夜找你救火救得再熟练也不如让火别烧起来。这一节聊聊怎么把证书从出事再修变成例行检查。7.1 资产清单与到期预警先得有清单。把所有对外和对内的 HTTPS 入口列出来包括域名、端口、证书文件路径、签发机构、有效期截止日、责任人。这份清单不用多复杂一张表格就够关键是有人维护、有地方查。清单建好之后到期预警至少设两道提前 45 天提醒一次用来走审批和签发流程提前 15 天再提醒一次用来安排部署窗口。自动化证书续期的方案现在很成熟但自动化只解决签发部署这一环还是得有人确认。我见过续期成功但没重载进程证书文件是新的内存里跑的还是旧的最后照样过期。监控这边可以加一条主动探测定期用openssl s_client拉取每个入口的证书把有效期和 SAN 列表存下来和清单做比对。SAN 变了、有效期少于 30 天就发告警。这条探针比单纯的端口存活检查有价值得多。7.2 变更流程里加一道证书卡点很多证书事故的源头不是证书本身而是变更。新增一个域名入口、改一次网关转发规则、把某个服务从 HTTP 换成 HTTPS这些变更做完之后没人去核对证书问题就埋下了。做法是在变更单里加一栏必填项本次变更是否涉及访问入口的域名或端口变化如果是证书的 SAN 列表是否已覆盖。这一栏看起来是形式主义但确实能拦住大部分低级失误。再进一步把校验做成流水线里的一步。部署完成之后自动跑一遍openssl s_client把拿到的 SAN 列表和本次部署声明的域名清单做差集有差异就报警甚至回滚。这一步加进去之后我们这边因为证书问题导致的夜间告警降了八成还多。成本不高一个几十行的脚本收益却非常直接。整套东西做下来你会发现证书问题的本质其实不复杂访问用什么名字证书就得写什么名字两边必须逐条对上。真正麻烦的是信息不对称——谁知道系统里到底有哪些入口、谁记得证书是什么时候换的、谁确认部署完之后进程真的重载了。把这几件事用清单、探针和流程固定下来剩下的就是常规操作了。最后再分享一个小技巧。我现在排查任何证书问题第一步永远是这三条命令连跑拉证书看 SAN、看图看链接验证链接、用--resolve直连源站排除干扰。三条跑完问题在哪基本就清楚了。比起跟人开会讨论半小时这三条命令加起来不超过两分钟而且结论是硬的不靠猜。