1. 问题背景与核心痛点拆解1.1 为什么浏览器总给 ESXi 打上“不安全”标签只要你在浏览器地址栏里敲下 ESXi 主机的管理地址大概率会看到那个刺眼的红色警告——您的连接不是私密连接或者此网站无法提供安全连接。点开高级选项底下还藏着一行小字大意是证书不受信任。很多人第一次遇到这个场景会心里一紧以为自己的虚拟化平台被攻击了其实绝大多数情况下这只是自签名证书在作祟。ESXi 出厂时为了让你能立刻通过 Web 界面管理主机会自动生成一张自签名 SSL 证书。这张证书的问题在于它不是由任何受信任的证书颁发机构签发的浏览器内置的信任链里根本没有它的位置。浏览器看到一张来路不明的证书出于安全策略就会拦截并提示风险。这跟证书本身有没有加密能力是两回事——加密照样在做只是身份没法被验证。理解这一点很关键因为它决定了你后续所有操作的方向。你要解决的不是加密坏了而是信任链断了。把这两个概念分清楚后面选方案的时候就不会走弯路。我见过不少人一上来就怀疑是端口配置错了、防火墙拦了折腾半天发现证书问题根本没动过。1.2 这个警告到底影响哪些实际使用场景表面上看点一下继续前往就能进管理界面好像没什么大不了。但实际用下来这个警告会在好几个地方给你添堵。最直接的是每次访问都要手动跳过拦截一天登录十次就要点十次烦不胜烦。其次是部分浏览器的严格安全模式会直接禁止你继续访问连高级里的跳过链接都不给。再往深了说如果你在 ESXi 上跑了一些依赖 HTTPS 回调的服务比如某些监控面板、自动化运维脚本、API 调用工具它们可不会像人一样点继续前往。这些程序遇到不受信任的证书通常会直接抛异常、拒绝连接导致采集不到数据或者任务中断。还有一类场景是团队协作你把管理地址发给同事对方看到红色警告第一反应是这地址是不是有问题沟通成本白白增加。所以这个问题的解决价值不只是看着舒服而是让 Web 管理通道回到一个干净、可预期、可自动化的状态。对于个人实验室环境它省的是每次点击的几秒钟对于有自动化需求的环境它决定的是整条链路能不能跑通。1.3 解决思路的整体分层从临时绕过到彻底替换面对这个警告业界常见的处理方式大致可以分成三个层次复杂度依次上升适用场景也各不相同。第一层是浏览器端临时信任也就是手动把当前证书加入例外列表。操作最快三十秒搞定但只对当前这台机器、当前这个浏览器生效换台电脑又得重来属于治标不治本。第二层是替换为受信任的正式证书让 ESXi 使用一张由公共证书机构签发、或者由你自建的内网证书机构签发的证书。这样浏览器天然信任一劳永逸适合长期使用、多人访问的环境。第三层是在客户端导入自建根证书把 ESXi 自签证书的签发根导入到操作系统的受信任根存储里。这样既保留了自签的灵活性又让浏览器认账适合内网规模较大、不想依赖外部机构的场景。下面我会把这三条路都拆开讲清楚重点放在第二层和第三层因为这两条才是真正能解决问题的方案。第一层虽然简单但作为应急手段也值得知道怎么操作。2. 方案选型背后的逻辑与取舍2.1 临时例外最快但最不持久的做法先说最省事的。在 Chrome 或 Edge 里看到警告页面后点击高级然后点继续前往不安全就能进入管理界面。Firefox 稍微麻烦一点需要在警告页点高级再点接受风险并继续。这个操作的本质是把当前这张证书的指纹临时记在浏览器的例外名单里下次访问同一地址时不再拦截。它的优点是零成本、零配置适合你只是临时登一下、马上就走的情况。但缺点同样明显例外名单是跟着浏览器配置文件走的你换浏览器、换电脑、清了缓存例外就没了。而且有些企业环境会通过策略强制禁用例外功能这时候你连跳过的按钮都看不到。提示临时例外只建议作为应急手段。如果你的 ESXi 是长期在用的管理入口别指望靠这个过日子早晚会被反复打扰。我个人的习惯是临时例外只在排查故障、手头没有其他工具的时候用一下用完就清掉。把它当成正式方案时间长了你会被那种每次都要点两下的琐碎感磨得没脾气。2.2 正式证书替换长期使用的正解真正能一劳永逸的是给 ESXi 换一张受信任的证书。这里又分两条岔路用公共机构签发的证书还是用自建内网机构签发的证书。公共机构签发的证书好处是任何设备、任何浏览器天然信任不需要在客户端做任何额外配置。但它的前提是你得有一个能解析到这台 ESXi 的域名因为公共机构签发证书时要验证域名所有权纯 IP 地址是签不出来的。对于家里实验室、内网环境来说专门为 ESXi 搞一个公网域名并做解析成本和复杂度都不低而且把管理界面暴露在公网本身也不是个好主意。所以更现实的选择是自建内网证书机构。你自己当一回发证机关生成一套根证书和中间证书然后用它给 ESXi 签发一张服务器证书。接着把这套根证书导入到你需要访问 ESXi 的每台客户端的受信任根存储里。这样浏览器看到 ESXi 的证书时能顺着签发链一路追到你导入的根证书信任链就闭合了。这个方案的优势在于不依赖外部机构、不要求公网域名、证书有效期可以自己定设个十年八年都行、内网所有设备可以共用同一套根证书。代价是你得在每台客户端上做一次根证书导入设备多了会有点繁琐但这是一次性工作。2.3 自签证书直接导入轻量但边界清晰还有一条介于两者之间的路不搞完整的证书机构直接拿 ESXi 自己生成的那张自签证书把它的公钥部分导入到客户端受信任根里。这样浏览器也会认这张证书。这条路的好处是不用重新签发证书省掉了生成和替换的步骤。但它的局限也很清楚ESXi 每次重新生成证书比如重置配置、升级大版本时证书指纹会变你就得重新导入一遍。而且自签证书的字段往往比较简陋有些严格的客户端校验会挑毛病。我的建议是如果你只有一两台客户端要访问且不介意偶尔重导一次这条路够用。但如果你希望一次配置管很久还是走自建证书机构那条路更稳。下面实操部分我会重点讲自建机构加签发替换的完整流程因为它是覆盖面最广、最经得起时间考验的方案。3. 自建证书机构与证书替换实操全流程3.1 准备工作确认 ESXi 版本与访问方式动手之前先把基础信息摸清楚。登录 ESXi 的 Web 管理界面就是那个带警告的页面先临时跳过进去在主机选项卡里能看到版本号。不同大版本的证书替换路径略有差异但核心逻辑一致把新的证书文件和私钥文件放到指定位置然后通过命令行或界面触发重新加载。访问方式上你需要能通过 SSH 登录到 ESXi 主机。默认情况下 SSH 服务是关闭的在管理界面的操作菜单里找到服务把 SSH 启动起来。同时确认你有 root 权限证书替换涉及系统目录写入普通账户做不了。另外准备一台用来生成证书的工作机Linux、macOS 或者装了 OpenSSL 的 Windows 都行。我习惯在 Linux 上操作命令行顺手脚本也好写。确认工作机上的 OpenSSL 版本不要太老1.1.1 以上比较稳妥新版本对证书扩展字段的支持更完整。注意整个操作过程中 ESXi 的管理服务会短暂重启Web 界面会断一下这是正常现象。别在业务高峰期做也别在远程且没有带外管理的情况下做万一服务起不来你会失去访问入口。3.2 生成根证书与服务器证书的完整命令先在工作机上建一个工作目录把所有证书文件都放里面方便管理。下面这套命令是我反复用过、比较稳的流程。第一步生成根证书的私钥和自签根证书。根证书的有效期设长一点比如 3650 天省得年年折腾。openssl genrsa -out ca.key 4096 openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \ -subj /CCN/STLab/LLab/OHomeLab/CNHomeLab Root CA \ -out ca.crt这里-subj里的字段可以按自己喜好填CN 就是这张根证书的名字客户端导入后显示的就是它。-nodes表示私钥不加密方便后续自动化使用但你要保管好这个ca.key它相当于你内网的公章泄露了别人就能签任意证书。第二步生成 ESXi 服务器证书的私钥和证书签名请求CSR。关键点在于CN 必须填你访问 ESXi 时用的地址。如果你用 IP 访问CN 就填 IP如果用域名访问CN 填域名。同时建议在 SAN主题备用名称里把 IP 和域名都写上这样两种访问方式都能通过校验。openssl genrsa -out esxi.key 2048 openssl req -new -key esxi.key -out esxi.csr \ -subj /CCN/STLab/LLab/OHomeLab/CN192.168.1.100第三步用根证书给这张 CSR 签名生成服务器证书。注意要带上 SAN 扩展否则现代浏览器会认为证书缺少必要字段而拒绝。cat san.cnf EOF subjectAltName IP:192.168.1.100, DNS:esxi.lab.local EOF openssl x509 -req -in esxi.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out esxi.crt -days 1825 -sha256 \ -extfile san.cnf把192.168.1.100和esxi.lab.local换成你自己的实际地址。-days 1825是五年有效期够用了。签完之后你会得到esxi.crt和esxi.key两个文件这就是要往 ESXi 上放的东西。3.3 把证书推送到 ESXi 并完成替换证书生成好了接下来要把它送到 ESXi 上并让它生效。ESXi 的证书文件位置在/etc/vmware/ssl/目录下文件名固定为rui.crt证书和rui.key私钥。替换的思路就是先把原文件备份再把新文件传上去覆盖最后重启管理服务。用 SCP 把文件传过去命令大概是这样scp esxi.crt root192.168.1.100:/etc/vmware/ssl/rui.crt scp esxi.key root192.168.1.100:/etc/vmware/ssl/rui.key传之前先 SSH 登录上去备份原文件这一步千万别省cp /etc/vmware/ssl/rui.crt /etc/vmware/ssl/rui.crt.bak cp /etc/vmware/ssl/rui.key /etc/vmware/ssl/rui.key.bak覆盖完成后重启管理服务让新证书加载。ESXi 上对应的服务是hostd用下面这条命令重启/etc/init.d/hostd restart等服务起来后刷新浏览器访问管理地址。如果一切顺利警告应该消失了地址栏显示正常的锁标志。如果还是警告先别急打开浏览器开发者工具的安全面板看看证书链到底断在哪一环——大概率是你还没把根证书导入客户端或者 CN/SAN 跟实际访问地址对不上。提示替换证书后如果 Web 界面打不开先通过 SSH 确认hostd服务状态必要时用备份文件还原再排查。备份文件就是你的后悔药别嫌占地方。3.4 客户端导入根证书让信任链闭合证书替换完服务端这一侧就搞定了。但浏览器还不认因为它不认识你自建的那个根证书。最后一步是把ca.crt导入到客户端的受信任根证书存储里。Windows 上的操作路径是双击ca.crt文件点安装证书选择本地计算机需要管理员权限然后选将所有的证书都放入下列存储浏览到受信任的根证书颁发机构一路下一步完成。导入后重启浏览器再访问 ESXi 就不会有警告了。macOS 上双击ca.crt会打开钥匙串访问找到导入的证书双击它展开信任选项把使用此证书时设为始终信任关闭窗口时输入密码确认即可。Linux 上把ca.crt复制到/usr/local/share/ca-certificates/目录Debian 系然后执行update-ca-certificates。Firefox 有自己的证书存储需要在设置里的隐私与安全→证书→查看证书→证书颁发机构里单独导入。这一步做完整条信任链就闭合了浏览器信任你的根证书根证书签发了 ESXi 的服务器证书ESXi 出示的证书就能被验证通过。整个过程的核心就是让签发关系可追溯这也是所有证书信任机制的底层逻辑。4. 常见问题排查与避坑经验实录4.1 替换后仍然报警告的排查顺序证书替换完还是看到警告别慌按下面的顺序逐项排查基本能定位到问题所在。先看证书是否真的生效了。在浏览器里点开警告页的证书信息对比一下序列号或者有效期确认显示的是不是你新签发的那张。如果还是旧证书说明文件没覆盖成功或者服务没重启回到上一步检查。再看CN 和 SAN 是否匹配访问地址。这是最常见的坑。你用 IP 访问但证书 CN 填的是域名或者 SAN 里漏了 IP浏览器就会判定主机名不匹配。解决办法是重新签发一张 SAN 里包含实际访问地址的证书。然后看根证书是否导入到了正确的位置。Windows 上要区分当前用户和本地计算机两个存储导入到当前用户存储的话其他用户登录还是报警告。Firefox 要单独导入它自己的证书库导入到系统存储它不认。最后看证书链是否完整。如果你用了中间证书服务端要把中间证书和服务器证书一起提供否则客户端追不到根。自建单层机构的话一般不存在这个问题但如果你搞了多层结构就要注意。4.2 一张表看懂典型症状与对应处理症状表现可能原因处理方式警告页显示的还是旧证书信息文件未覆盖或服务未重启检查/etc/vmware/ssl/下文件时间戳重启 hostd提示证书与主机名不匹配CN/SAN 与实际访问地址不一致重新签发SAN 里补全 IP 和域名导入根证书后其他浏览器仍警告根证书只导入了单一浏览器存储按浏览器分别导入系统存储和浏览器存储都要覆盖部分自动化工具仍拒绝连接工具使用独立的证书校验库在工具的配置里指定 CA 文件路径或导入到系统信任库重启后证书恢复成自签配置未持久化或被重置确认替换流程完整避免触发配置重置操作这张表是我在实际操作中慢慢攒出来的基本上遇到问题对着查一遍就能找到方向。尤其是第一行那个文件时间戳的检查看起来简单但能快速排除掉一半的假故障。4.3 几个容易踩的坑和我的处理习惯第一个坑是私钥权限。传到 ESXi 上的rui.key权限如果不对服务可能读不到导致证书加载失败。传完之后顺手看一眼权限确保 root 可读。我一般传完就执行一次chmod 600保险。第二个坑是证书有效期设太长反而出问题。有些客户端对超长有效期的证书有额外校验设个五年左右比较稳妥别一上来就填五十年。第三个坑是忘了更新所有客户端的根证书。你在这台电脑上配好了换台电脑访问又报警告然后怀疑是不是服务端又出问题了。其实只是新客户端没导入根证书。我的习惯是把ca.crt放在内网共享目录里新设备接入时第一件事就是导入它。第四个坑是在错误的时机做替换。前面提过替换过程会重启管理服务如果你正通过 Web 界面做重要配置中途断开会前功尽弃。我一般选在维护窗口做做完立刻验证一遍再收工。注意自建证书机构的根私钥ca.key一定要离线保管别跟证书文件混在一起放在共享目录。它一旦泄露别人就能签发被你的客户端信任的任意证书整个信任体系就形同虚设了。4.4 关于自动化脚本访问的额外说明如果你的环境里有脚本或工具需要通过 HTTPS 访问 ESXi 的 API光在浏览器里配好还不够。这类工具通常有自己的证书校验逻辑有的读系统信任库有的读自己配置里的 CA 路径。以常见的 Python 请求库为例可以在调用时通过参数指定 CA 证书文件路径让它用你导入的根证书来校验。import requests resp requests.get( https://192.168.1.100/api/endpoint, verify/path/to/ca.crt, auth(root, your_password) )这样写的好处是校验逻辑明确不依赖系统全局配置换台机器跑脚本只要带上ca.crt就行。我一般会把ca.crt跟脚本放同一个目录用相对路径引用迁移起来方便。如果工具不支持指定 CA 路径那就只能把根证书导入到运行它的那台机器的系统信任库里思路跟浏览器导入是一样的。5. 方案对比与长期维护建议5.1 三种方案横向对比把前面讲的三种思路放在一起对比方便你按自己的实际情况选。对比维度浏览器临时例外自签证书直接导入自建机构签发替换配置耗时几十秒十分钟左右半小时左右持久性仅当前浏览器配置证书重生成后失效长期有效多客户端支持每台单独配每台单独导入导入根证书即可自动化工具友好度差一般好维护成本高反复操作中低适用场景临时应急少量固定客户端长期多人多设备从表里能看出来自建机构签发替换在持久性和维护成本上优势明显前期多花的那点时间很快就能从后续的省心中赚回来。临时例外适合救急自签导入适合小规模规模一上来还是得靠机构签发。5.2 证书到期前的续期与轮换自建证书虽然有效期可以设很长但总有到期的一天。到期前如果不处理浏览器又会开始报警告而且这次是因为证书过期比不受信任更直接。我的做法是在日历里给证书到期日提前一个月设个提醒到期前重新签发一张替换上去客户端那边因为根证书没变不需要重新导入。轮换的时候注意一点新证书的 CN 和 SAN 要跟旧证书保持一致否则客户端校验会失败。签发命令可以直接复用之前的只改一下输出文件名和有效期就行。替换流程跟第一次完全一样备份、覆盖、重启服务三步走完。如果你管理的 ESXi 主机不止一台可以考虑把签发和替换的步骤写成脚本批量执行。脚本里把主机地址、证书路径做成参数跑一遍就能把一批主机的证书都换掉。这种批量操作尤其要注意先在一台上验证通过再推到全部别一上来就全量执行。5.3 我个人在实际操作中的体会这套流程我前后在不同环境里走过很多遍最大的感受是证书问题的本质是信任关系问题而不是技术难题。很多人被那一堆命令和文件吓住其实拆开看就是生成一对密钥、签一张证书、放到指定位置、让客户端认识签发者这四件事。把这四件事的顺序和因果关系理清楚操作起来就不会乱。另一个体会是备份的重要性怎么强调都不过分。我见过不止一次因为覆盖文件前没备份出问题后只能重装或者重置配置的情况。那两张.bak文件平时看着没用关键时刻能救你一整个下午。养成动手前先备份的习惯比记住任何一条命令都值钱。最后一点别把这件事想得太复杂。第一次做可能要对着步骤慢慢来做完一遍之后你会发现整个流程其实很线性没有什么分支和陷阱。真正花时间的往往不是操作本身而是排查那些因为地址填错、文件没传对导致的小问题。把 CN 和 SAN 这两个字段填准能省掉一大半的返工。 
长河君 · 2026/11/2 8:55:49 · 阅读 1.2k ESXi自签名证书警告解决：自建CA替换证书全流程
1. 问题背景与核心痛点拆解1.1 为什么浏览器总给 ESXi 打上“不安全”标签只要你在浏览器地址栏里敲下 ESXi 主机的管理地址大概率会看到那个刺眼的红色警告——您的连接不是私密连接或者此网站无法提供安全连接。点开高级选项底下还藏着一行小字大意是证书不受信任。很多人第一次遇到这个场景会心里一紧以为自己的虚拟化平台被攻击了其实绝大多数情况下这只是自签名证书在作祟。ESXi 出厂时为了让你能立刻通过 Web 界面管理主机会自动生成一张自签名 SSL 证书。这张证书的问题在于它不是由任何受信任的证书颁发机构签发的浏览器内置的信任链里根本没有它的位置。浏览器看到一张来路不明的证书出于安全策略就会拦截并提示风险。这跟证书本身有没有加密能力是两回事——加密照样在做只是身份没法被验证。理解这一点很关键因为它决定了你后续所有操作的方向。你要解决的不是加密坏了而是信任链断了。把这两个概念分清楚后面选方案的时候就不会走弯路。我见过不少人一上来就怀疑是端口配置错了、防火墙拦了折腾半天发现证书问题根本没动过。1.2 这个警告到底影响哪些实际使用场景表面上看点一下继续前往就能进管理界面好像没什么大不了。但实际用下来这个警告会在好几个地方给你添堵。最直接的是每次访问都要手动跳过拦截一天登录十次就要点十次烦不胜烦。其次是部分浏览器的严格安全模式会直接禁止你继续访问连高级里的跳过链接都不给。再往深了说如果你在 ESXi 上跑了一些依赖 HTTPS 回调的服务比如某些监控面板、自动化运维脚本、API 调用工具它们可不会像人一样点继续前往。这些程序遇到不受信任的证书通常会直接抛异常、拒绝连接导致采集不到数据或者任务中断。还有一类场景是团队协作你把管理地址发给同事对方看到红色警告第一反应是这地址是不是有问题沟通成本白白增加。所以这个问题的解决价值不只是看着舒服而是让 Web 管理通道回到一个干净、可预期、可自动化的状态。对于个人实验室环境它省的是每次点击的几秒钟对于有自动化需求的环境它决定的是整条链路能不能跑通。1.3 解决思路的整体分层从临时绕过到彻底替换面对这个警告业界常见的处理方式大致可以分成三个层次复杂度依次上升适用场景也各不相同。第一层是浏览器端临时信任也就是手动把当前证书加入例外列表。操作最快三十秒搞定但只对当前这台机器、当前这个浏览器生效换台电脑又得重来属于治标不治本。第二层是替换为受信任的正式证书让 ESXi 使用一张由公共证书机构签发、或者由你自建的内网证书机构签发的证书。这样浏览器天然信任一劳永逸适合长期使用、多人访问的环境。第三层是在客户端导入自建根证书把 ESXi 自签证书的签发根导入到操作系统的受信任根存储里。这样既保留了自签的灵活性又让浏览器认账适合内网规模较大、不想依赖外部机构的场景。下面我会把这三条路都拆开讲清楚重点放在第二层和第三层因为这两条才是真正能解决问题的方案。第一层虽然简单但作为应急手段也值得知道怎么操作。2. 方案选型背后的逻辑与取舍2.1 临时例外最快但最不持久的做法先说最省事的。在 Chrome 或 Edge 里看到警告页面后点击高级然后点继续前往不安全就能进入管理界面。Firefox 稍微麻烦一点需要在警告页点高级再点接受风险并继续。这个操作的本质是把当前这张证书的指纹临时记在浏览器的例外名单里下次访问同一地址时不再拦截。它的优点是零成本、零配置适合你只是临时登一下、马上就走的情况。但缺点同样明显例外名单是跟着浏览器配置文件走的你换浏览器、换电脑、清了缓存例外就没了。而且有些企业环境会通过策略强制禁用例外功能这时候你连跳过的按钮都看不到。提示临时例外只建议作为应急手段。如果你的 ESXi 是长期在用的管理入口别指望靠这个过日子早晚会被反复打扰。我个人的习惯是临时例外只在排查故障、手头没有其他工具的时候用一下用完就清掉。把它当成正式方案时间长了你会被那种每次都要点两下的琐碎感磨得没脾气。2.2 正式证书替换长期使用的正解真正能一劳永逸的是给 ESXi 换一张受信任的证书。这里又分两条岔路用公共机构签发的证书还是用自建内网机构签发的证书。公共机构签发的证书好处是任何设备、任何浏览器天然信任不需要在客户端做任何额外配置。但它的前提是你得有一个能解析到这台 ESXi 的域名因为公共机构签发证书时要验证域名所有权纯 IP 地址是签不出来的。对于家里实验室、内网环境来说专门为 ESXi 搞一个公网域名并做解析成本和复杂度都不低而且把管理界面暴露在公网本身也不是个好主意。所以更现实的选择是自建内网证书机构。你自己当一回发证机关生成一套根证书和中间证书然后用它给 ESXi 签发一张服务器证书。接着把这套根证书导入到你需要访问 ESXi 的每台客户端的受信任根存储里。这样浏览器看到 ESXi 的证书时能顺着签发链一路追到你导入的根证书信任链就闭合了。这个方案的优势在于不依赖外部机构、不要求公网域名、证书有效期可以自己定设个十年八年都行、内网所有设备可以共用同一套根证书。代价是你得在每台客户端上做一次根证书导入设备多了会有点繁琐但这是一次性工作。2.3 自签证书直接导入轻量但边界清晰还有一条介于两者之间的路不搞完整的证书机构直接拿 ESXi 自己生成的那张自签证书把它的公钥部分导入到客户端受信任根里。这样浏览器也会认这张证书。这条路的好处是不用重新签发证书省掉了生成和替换的步骤。但它的局限也很清楚ESXi 每次重新生成证书比如重置配置、升级大版本时证书指纹会变你就得重新导入一遍。而且自签证书的字段往往比较简陋有些严格的客户端校验会挑毛病。我的建议是如果你只有一两台客户端要访问且不介意偶尔重导一次这条路够用。但如果你希望一次配置管很久还是走自建证书机构那条路更稳。下面实操部分我会重点讲自建机构加签发替换的完整流程因为它是覆盖面最广、最经得起时间考验的方案。3. 自建证书机构与证书替换实操全流程3.1 准备工作确认 ESXi 版本与访问方式动手之前先把基础信息摸清楚。登录 ESXi 的 Web 管理界面就是那个带警告的页面先临时跳过进去在主机选项卡里能看到版本号。不同大版本的证书替换路径略有差异但核心逻辑一致把新的证书文件和私钥文件放到指定位置然后通过命令行或界面触发重新加载。访问方式上你需要能通过 SSH 登录到 ESXi 主机。默认情况下 SSH 服务是关闭的在管理界面的操作菜单里找到服务把 SSH 启动起来。同时确认你有 root 权限证书替换涉及系统目录写入普通账户做不了。另外准备一台用来生成证书的工作机Linux、macOS 或者装了 OpenSSL 的 Windows 都行。我习惯在 Linux 上操作命令行顺手脚本也好写。确认工作机上的 OpenSSL 版本不要太老1.1.1 以上比较稳妥新版本对证书扩展字段的支持更完整。注意整个操作过程中 ESXi 的管理服务会短暂重启Web 界面会断一下这是正常现象。别在业务高峰期做也别在远程且没有带外管理的情况下做万一服务起不来你会失去访问入口。3.2 生成根证书与服务器证书的完整命令先在工作机上建一个工作目录把所有证书文件都放里面方便管理。下面这套命令是我反复用过、比较稳的流程。第一步生成根证书的私钥和自签根证书。根证书的有效期设长一点比如 3650 天省得年年折腾。openssl genrsa -out ca.key 4096 openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \ -subj /CCN/STLab/LLab/OHomeLab/CNHomeLab Root CA \ -out ca.crt这里-subj里的字段可以按自己喜好填CN 就是这张根证书的名字客户端导入后显示的就是它。-nodes表示私钥不加密方便后续自动化使用但你要保管好这个ca.key它相当于你内网的公章泄露了别人就能签任意证书。第二步生成 ESXi 服务器证书的私钥和证书签名请求CSR。关键点在于CN 必须填你访问 ESXi 时用的地址。如果你用 IP 访问CN 就填 IP如果用域名访问CN 填域名。同时建议在 SAN主题备用名称里把 IP 和域名都写上这样两种访问方式都能通过校验。openssl genrsa -out esxi.key 2048 openssl req -new -key esxi.key -out esxi.csr \ -subj /CCN/STLab/LLab/OHomeLab/CN192.168.1.100第三步用根证书给这张 CSR 签名生成服务器证书。注意要带上 SAN 扩展否则现代浏览器会认为证书缺少必要字段而拒绝。cat san.cnf EOF subjectAltName IP:192.168.1.100, DNS:esxi.lab.local EOF openssl x509 -req -in esxi.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out esxi.crt -days 1825 -sha256 \ -extfile san.cnf把192.168.1.100和esxi.lab.local换成你自己的实际地址。-days 1825是五年有效期够用了。签完之后你会得到esxi.crt和esxi.key两个文件这就是要往 ESXi 上放的东西。3.3 把证书推送到 ESXi 并完成替换证书生成好了接下来要把它送到 ESXi 上并让它生效。ESXi 的证书文件位置在/etc/vmware/ssl/目录下文件名固定为rui.crt证书和rui.key私钥。替换的思路就是先把原文件备份再把新文件传上去覆盖最后重启管理服务。用 SCP 把文件传过去命令大概是这样scp esxi.crt root192.168.1.100:/etc/vmware/ssl/rui.crt scp esxi.key root192.168.1.100:/etc/vmware/ssl/rui.key传之前先 SSH 登录上去备份原文件这一步千万别省cp /etc/vmware/ssl/rui.crt /etc/vmware/ssl/rui.crt.bak cp /etc/vmware/ssl/rui.key /etc/vmware/ssl/rui.key.bak覆盖完成后重启管理服务让新证书加载。ESXi 上对应的服务是hostd用下面这条命令重启/etc/init.d/hostd restart等服务起来后刷新浏览器访问管理地址。如果一切顺利警告应该消失了地址栏显示正常的锁标志。如果还是警告先别急打开浏览器开发者工具的安全面板看看证书链到底断在哪一环——大概率是你还没把根证书导入客户端或者 CN/SAN 跟实际访问地址对不上。提示替换证书后如果 Web 界面打不开先通过 SSH 确认hostd服务状态必要时用备份文件还原再排查。备份文件就是你的后悔药别嫌占地方。3.4 客户端导入根证书让信任链闭合证书替换完服务端这一侧就搞定了。但浏览器还不认因为它不认识你自建的那个根证书。最后一步是把ca.crt导入到客户端的受信任根证书存储里。Windows 上的操作路径是双击ca.crt文件点安装证书选择本地计算机需要管理员权限然后选将所有的证书都放入下列存储浏览到受信任的根证书颁发机构一路下一步完成。导入后重启浏览器再访问 ESXi 就不会有警告了。macOS 上双击ca.crt会打开钥匙串访问找到导入的证书双击它展开信任选项把使用此证书时设为始终信任关闭窗口时输入密码确认即可。Linux 上把ca.crt复制到/usr/local/share/ca-certificates/目录Debian 系然后执行update-ca-certificates。Firefox 有自己的证书存储需要在设置里的隐私与安全→证书→查看证书→证书颁发机构里单独导入。这一步做完整条信任链就闭合了浏览器信任你的根证书根证书签发了 ESXi 的服务器证书ESXi 出示的证书就能被验证通过。整个过程的核心就是让签发关系可追溯这也是所有证书信任机制的底层逻辑。4. 常见问题排查与避坑经验实录4.1 替换后仍然报警告的排查顺序证书替换完还是看到警告别慌按下面的顺序逐项排查基本能定位到问题所在。先看证书是否真的生效了。在浏览器里点开警告页的证书信息对比一下序列号或者有效期确认显示的是不是你新签发的那张。如果还是旧证书说明文件没覆盖成功或者服务没重启回到上一步检查。再看CN 和 SAN 是否匹配访问地址。这是最常见的坑。你用 IP 访问但证书 CN 填的是域名或者 SAN 里漏了 IP浏览器就会判定主机名不匹配。解决办法是重新签发一张 SAN 里包含实际访问地址的证书。然后看根证书是否导入到了正确的位置。Windows 上要区分当前用户和本地计算机两个存储导入到当前用户存储的话其他用户登录还是报警告。Firefox 要单独导入它自己的证书库导入到系统存储它不认。最后看证书链是否完整。如果你用了中间证书服务端要把中间证书和服务器证书一起提供否则客户端追不到根。自建单层机构的话一般不存在这个问题但如果你搞了多层结构就要注意。4.2 一张表看懂典型症状与对应处理症状表现可能原因处理方式警告页显示的还是旧证书信息文件未覆盖或服务未重启检查/etc/vmware/ssl/下文件时间戳重启 hostd提示证书与主机名不匹配CN/SAN 与实际访问地址不一致重新签发SAN 里补全 IP 和域名导入根证书后其他浏览器仍警告根证书只导入了单一浏览器存储按浏览器分别导入系统存储和浏览器存储都要覆盖部分自动化工具仍拒绝连接工具使用独立的证书校验库在工具的配置里指定 CA 文件路径或导入到系统信任库重启后证书恢复成自签配置未持久化或被重置确认替换流程完整避免触发配置重置操作这张表是我在实际操作中慢慢攒出来的基本上遇到问题对着查一遍就能找到方向。尤其是第一行那个文件时间戳的检查看起来简单但能快速排除掉一半的假故障。4.3 几个容易踩的坑和我的处理习惯第一个坑是私钥权限。传到 ESXi 上的rui.key权限如果不对服务可能读不到导致证书加载失败。传完之后顺手看一眼权限确保 root 可读。我一般传完就执行一次chmod 600保险。第二个坑是证书有效期设太长反而出问题。有些客户端对超长有效期的证书有额外校验设个五年左右比较稳妥别一上来就填五十年。第三个坑是忘了更新所有客户端的根证书。你在这台电脑上配好了换台电脑访问又报警告然后怀疑是不是服务端又出问题了。其实只是新客户端没导入根证书。我的习惯是把ca.crt放在内网共享目录里新设备接入时第一件事就是导入它。第四个坑是在错误的时机做替换。前面提过替换过程会重启管理服务如果你正通过 Web 界面做重要配置中途断开会前功尽弃。我一般选在维护窗口做做完立刻验证一遍再收工。注意自建证书机构的根私钥ca.key一定要离线保管别跟证书文件混在一起放在共享目录。它一旦泄露别人就能签发被你的客户端信任的任意证书整个信任体系就形同虚设了。4.4 关于自动化脚本访问的额外说明如果你的环境里有脚本或工具需要通过 HTTPS 访问 ESXi 的 API光在浏览器里配好还不够。这类工具通常有自己的证书校验逻辑有的读系统信任库有的读自己配置里的 CA 路径。以常见的 Python 请求库为例可以在调用时通过参数指定 CA 证书文件路径让它用你导入的根证书来校验。import requests resp requests.get( https://192.168.1.100/api/endpoint, verify/path/to/ca.crt, auth(root, your_password) )这样写的好处是校验逻辑明确不依赖系统全局配置换台机器跑脚本只要带上ca.crt就行。我一般会把ca.crt跟脚本放同一个目录用相对路径引用迁移起来方便。如果工具不支持指定 CA 路径那就只能把根证书导入到运行它的那台机器的系统信任库里思路跟浏览器导入是一样的。5. 方案对比与长期维护建议5.1 三种方案横向对比把前面讲的三种思路放在一起对比方便你按自己的实际情况选。对比维度浏览器临时例外自签证书直接导入自建机构签发替换配置耗时几十秒十分钟左右半小时左右持久性仅当前浏览器配置证书重生成后失效长期有效多客户端支持每台单独配每台单独导入导入根证书即可自动化工具友好度差一般好维护成本高反复操作中低适用场景临时应急少量固定客户端长期多人多设备从表里能看出来自建机构签发替换在持久性和维护成本上优势明显前期多花的那点时间很快就能从后续的省心中赚回来。临时例外适合救急自签导入适合小规模规模一上来还是得靠机构签发。5.2 证书到期前的续期与轮换自建证书虽然有效期可以设很长但总有到期的一天。到期前如果不处理浏览器又会开始报警告而且这次是因为证书过期比不受信任更直接。我的做法是在日历里给证书到期日提前一个月设个提醒到期前重新签发一张替换上去客户端那边因为根证书没变不需要重新导入。轮换的时候注意一点新证书的 CN 和 SAN 要跟旧证书保持一致否则客户端校验会失败。签发命令可以直接复用之前的只改一下输出文件名和有效期就行。替换流程跟第一次完全一样备份、覆盖、重启服务三步走完。如果你管理的 ESXi 主机不止一台可以考虑把签发和替换的步骤写成脚本批量执行。脚本里把主机地址、证书路径做成参数跑一遍就能把一批主机的证书都换掉。这种批量操作尤其要注意先在一台上验证通过再推到全部别一上来就全量执行。5.3 我个人在实际操作中的体会这套流程我前后在不同环境里走过很多遍最大的感受是证书问题的本质是信任关系问题而不是技术难题。很多人被那一堆命令和文件吓住其实拆开看就是生成一对密钥、签一张证书、放到指定位置、让客户端认识签发者这四件事。把这四件事的顺序和因果关系理清楚操作起来就不会乱。另一个体会是备份的重要性怎么强调都不过分。我见过不止一次因为覆盖文件前没备份出问题后只能重装或者重置配置的情况。那两张.bak文件平时看着没用关键时刻能救你一整个下午。养成动手前先备份的习惯比记住任何一条命令都值钱。最后一点别把这件事想得太复杂。第一次做可能要对着步骤慢慢来做完一遍之后你会发现整个流程其实很线性没有什么分支和陷阱。真正花时间的往往不是操作本身而是排查那些因为地址填错、文件没传对导致的小问题。把 CN 和 SAN 这两个字段填准能省掉一大半的返工。