企业官网建设流程全解析

HTTPS证书验证失败这个报错，做内网服务的人基本都遇到过。尤其是在内网部署大模型接口、模型网关这类服务时，客户端会直接甩一句SSL certificate problem: self-signed certificate，网上搜一圈，要么让你直接加-k跳过校验，要么让你去买昂贵的外网证书——根本都不适合内网环境。我最近刚趟完一遍完整的自签名证书方案，从生成、签发到挂载、验证，全部跑通没花多少时间，今天就把这套实操流程完整写出来。

这套方案适合谁呢？一是公司内网部署了大模型推理服务，要给多个客户端提供 HTTPS 接口的场景；二是团队内部搭建模型网关、算法平台时需要快速启用认证的场景；三是个人在局域网内做开发调试，想用更接近生产环境的 HTTPS 而不是 HTTP 的场景。核心思路就一句话：自己搭一个私有 CA，用它签发服务端证书，再把 CA 根证书导入到各客户端的信任区。这样内网接口也能走合法的 HTTPS，而不是用跳过验证这种高风险方式。

1. 先搞清楚证书为什么会验证失败

1.1 内网大模型接口的真实困境

内网部署的模型推理服务一般跑在 8000、8080、8443 这类端口上，我见过不少团队最开始图省事直接开了 HTTP，对外说“内网无所谓”。等联调大模型接口的时候，问题就来了。某些内部系统策略只允许 HTTPS 请求，某些超 Fusion 的客户端框架默认对非 HTTPS 地址拒绝发包，更别提浏览器里那些安全策略。于是被迫切到 HTTPS，结果又冒出来证书验证失败的怪问题。

证书验证失败的根因，说白了是客户端操作系统或应用运行时根本不认识你这张证书。浏览器、Python 的 requests、Java 的 HttpClient，甚至 curl，都有自己内置的 CA 证书库，它们只信任由这些 CA 签发的证书。内网自签证书的签发者不在信任列表里，验证必然失败。这个逻辑可以类比门卫认访客——门卫只认他名单上的熟人，你拿一张陌生公司的工作牌去刷，当然进不去。

1.2 自签名证书方案适用边界

自签名证书有两种玩法。一种是直接用 OpenSSL 生成一张孤立的自签证书，装到 Nginx 上，客户端得手动信任这张证书。另一种是先生成一个自建的 CA 根证书，然后用这个 CA 去签发服务端证书，再把 CA 根证书分发到各客户端信任区。我更推荐第二种。

第一种方式问题很明显：每台客户端都得信任那张服务端证书，证书一旦更换就得重新分发。第二种方式里，CA 是固定的，服务端证书可以随便签发、过期了重新签，客户端只要信任 CA 根证书，就会自动信任所有由这个 CA 签发的服务端证书。这套结构学名叫 PKI（公钥基础设施），内网玩 HTTPS 就得按这个路子走，否则后面运维就是给自己埋雷。

注意：自签名证书的加密强度和正式 CA 签发的证书并无本质差别，差别只在于信任关系。自签名证书用于内网完全没问题，前提是你严格控制好私钥的保管权限。

2. 生成证书前必须懂的几个概念

2.1 数字证书信任链与 CA

证书信任链可以想象成一个树状结构。最顶层是根 CA 证书，它下面签发的所有证书都挂在它底下。客户端验证一张服务端证书的时候，会往上找签发者，如果签发者是受信任的根 CA，那就一路追溯成功，验证通过。

自己搭内网 CA 体系，一共需要三个角色：

CA 私钥是整个信任体系的核心。它一旦泄露，别人就能用它伪造任意证书，你的内网 HTTPS 防线直接崩塌。所以这个私钥文件存放的路径、权限，都要比普通服务端私钥更严格。我习惯把 CA 相关文件单独放一个目录，权限设成 700，并且不做任何备份复制。

2.2 为什么 SAN 字段直接决定成败

SAN（Subject Alternative Name，主题备用名称）是证书里的一个扩展字段，用来声明这个证书到底是为哪些域名、IP 服务。没有 SAN 字段的证书，在现在的主流客户端里基本没法用。

为什么这么说？从 Chrome 58 开始，浏览器就不再显示没有 SAN 的证书了，Python 3.7 以上的 ssl 模块也强制校验 SAN。更关键在于，你用 IP 直接访问接口的情况下，证书里必须明确写上这个 IP 地址。比如模型服务在192.168.10.20，那 SAN 里不加这个 IP，客户端就会报IP address mismatch。

我在这上面栽过跟头。第一版生成的证书只写了 Common Name（CN）字段，以为就够了，结果所有客户端全部验证失败。把 SAN 加进去重新签发，立刻就好了。所以这篇文章里你会看到，我在生成证书的配置文件里专门加了subjectAltName，这是整个流程成败的分水岭。

2.3 OpenSSL 环境准备与版本确认

第一步是确认 OpenSSL 装好了没。大多数 Linux 发行版默认带 OpenSSL，版本新一点体验更好。我机器上用的是 3.x 版本，如果你还在用 1.1.1，也没关系，下面的命令两种版本都兼容。

openssl version

如果没安装，在 Debian 系的系统上执行：

sudo apt update && sudo apt install -y openssl

RedHat 系则用：

sudo yum install -y openssl

Windows 环境下，可以用 Git Bash 自带的 OpenSSL，或者单独安装一个编译好的 OpenSSL 二进制，命令语法一样。我建议优先用 Linux 机器操作，密钥文件的属主和权限管理更方便，后面要踢出生成过程也更顺手。

3. 完整实操：五分钟生成可信自签名证书

3.1 第一步：创建私有 CA 与根证书

建一个专门的工作目录，所有证书操作都在这个目录里进行，避免文件散落在系统各处。

mkdir -p ~/ssl-lab/ca cd ~/ssl-lab/ca

先生成 CA 私钥。这里用-aes256给私钥加密，每次用私钥签署证书的时候都要输入口令，多一步操作但更安全。如果你嫌麻烦想省掉口令，去掉-aes256参数即可，但工作环境里的 CA 私钥建议还是加上口令。

openssl genrsa -aes256 -out ca.key 4096

接下来生成 CA 根证书。自签根证书用req子命令一步到位，-x509表示直接输出自签名证书，-days 3650表示有效期十年，-subj指定证书基本信息：

openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \ -subj "/CN=Internal-Lab-CA/O=Internal Lab" -out ca.crt

验证一下根证书内容：

openssl x509 -in ca.crt -text -noout

关注输出里的Issuer和Subject字段，自签证书两者内容一致。另外确认CA:TRUE扩展存在，没有的话后面签发不了证书。到这里，私有 CA 就绪。

3.2 第二步：生成服务端证书与 SAN 扩展

服务端证书的生成分两步：先产生私钥和证书签名请求（CSR），再用 CA 私钥对这个请求签名。

cd ~/ssl-lab mkdir -p server openssl genrsa -out server/server.key 2048

生成 CSR。CN 字段可以写成服务域名，但这个字段在现代客户端中已经不作为主机名校验依据了，真正的校验看 SAN，所以 CN 写什么不太重要：

openssl req -new -key server/server.key -subj "/CN=model-server" -out server/server.csr

接着创建 SAN 配置文件，这是整个流程中最关键的一步。假设模型接口部署在内网地址192.168.10.20，同时需要支持局域网机器名model-server.local访问，配置文件内容如下：

cat > server/server.ext <<EOF subjectAltName = DNS:model-server.local, IP:192.168.10.20, IP:127.0.0.1 extendedKeyUsage = serverAuth basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment EOF

DNS部分写你访问服务用的域名，IP部分写内网 IP，多个地址用逗号分隔。凡是你可能用来访问这个服务的地址，都要写进去，宁可多写几个也别漏。

现在用 CA 私钥签发服务端证书：

openssl x509 -req -in server/server.csr \ -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial \ -out server/server.crt -days 825 \ -extfile server/server.ext

-CAcreateserial会生成一个ca.srl序列号文件，记录签发了多少张证书。-days 825是证书有效期，这个数值约等于两年三个月，很多正式 CA 现在签发的证书上限就是这个时间。

3.3 第三步：Nginx 挂载证书与强制 HTTPS

服务端证书生成后，需要把它挂到入口服务上。内网大模型接口最常见的入口是 Nginx，因为既能做反向代理、又能做 TLS 卸载，还能处理大请求体和超时时间。

先在 Nginx 的配置目录里放好证书和密钥：

sudo mkdir -p /etc/nginx/ssl sudo cp server/server.crt /etc/nginx/ssl/ sudo cp server/server.key /etc/nginx/ssl/

Nginx 配置参考：

server { listen 8443 ssl; server_name model-server.local; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; ssl_protocols TLSv1.2 TLSv1.3; charset utf-8; client_max_body_size 100M; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 600; } }

大模型接口有几个特殊点值得注意。一是响应可能很长，proxy_read_timeout要调大，别用默认的 60 秒，否则推理跑慢了 Nginx 先把连接断了。二是有时会有 SSE 流式输出，必须关掉代理缓冲，或者至少要配置合理的缓冲策略。三是大模型接口的请求体可能很大，client_max_body_size要放宽。

改完配置，校验并重载：

nginx -t && sudo nginx -s reload

3.4 第四步：客户端信任导入与验证

服务端配置完成，客户端必须把 CA 根证书导入信任区，否则照样验证失败。各客户端的导入方式不同，这块我把常见的几个平台全列出来。

macOS 上用以下命令导入系统钥匙串：

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca/ca.crt

Linux 上有 Debian/Ubuntu 系的标准做法：

sudo cp ca/ca.crt /usr/local/share/ca-certificates/internal-lab-ca.crt sudo update-ca-certificates

Windows 上通过图形界面操作：双击 ca.crt 文件，选择“安装证书”，存储位置选“本地计算机”，然后选择“将所有证书放入下列存储”，点击浏览并选择“受信任的根证书颁发机构”。

完成导入后，用 curl 做一次完整验证：

curl --cacert ca/ca.crt https://192.168.10.20:8443/v1/models

如果输出正常响应而不是报 SSL 错误，整个链路就算通了。

4. 验证方法与客户端代码对接

4.1 curl 验证的三种姿势对比

curl 是验证 HTTPS 链路最直接的工具。我习惯按不同阶段使用三个命令。

最严格、最推荐的方式是显式指定 CA 文件：

curl --cacert ca/ca.crt https://192.168.10.20:8443/v1/models

这个命令告诉 curl 用我们自己的 CA 去校验服务器证书。验证通过就代表整个信任链是完好的，这是最有价值的测试。系统全局导入了 CA 之后再跑一条不带参数的：

curl https://192.168.10.20:8443/v1/models

如果这条命令也没报错，说明系统信任库已经生效。最后提一下那个危险的-k参数，不少教程上来就叫你加-k跳过验证。-k确实能立刻绕过去，但它同时关闭了 TLS 的安全保障，你没法确定连到的服务器是不是被劫持的，更没法确定数据有没有被中间人读取。建议只在临时手工调试的时候用，不要写进任何自动化脚本和客户端代码里。

4.2 客户端代码对接注意事项

内网大模型接口的调用方，最常见的是 Python 和 Java。

Python 的requests库直接支持通过verify参数指定 CA 文件：

import requests url = "https://192.168.10.20:8443/v1/completions" payload = {"model": "your-model", "prompt": "hello"} resp = requests.post(url, json=payload, verify="/path/to/ca.crt", timeout=30) print(resp.status_code) print(resp.json())

如果用系统信任库，只需要把verify设为True。但要小心，requests底层用的是 certifi 自带的证书库而不是系统库，所以系统导入的 CA 对 requests 不一定生效。最稳妥的做法永远是显式传verify指向你的 CA 文件。

Java 侧的处理方式更繁琐。JVM 有自己独立的信任库（cacerts），默认不读取系统信任库。导入命令：

keytool -import -trustcacerts -alias internal-lab-ca \ -file ca.crt -keystore $JAVA_HOME/lib/security/cacerts

执行时会提示输入密钥库口令，默认是changeit。也可以在启动参数里指定一个独立的信任库：

java -Djavax.net.ssl.trustStore=/path/to/truststore.jks -jar app.jar

4.3 常见报错排查速查表

实操中肯定会在某个环节卡住。我把几个高频报错和排查思路整理成了表格，按这个顺序逐个排除，基本都能解决。

提示：遇到任何证书验证问题，先用openssl s_client直连服务端口查看服务端实际返回的证书链，这个命令比 curl 更能定位问题所在。

5. 内网 HTTPS 方案的进阶建议

5.1 服务端证书按环境分开签发

如果你有多个环境分别部署大模型服务（测试环境、预发环境、正式环境），我建议每个环境分开签发服务端证书，而不是所有环境共用一张。隔离的逻辑和隔离账号权限实际上是一样的，也方便按环境独立更新证书。

操作上不需要重复创建 CA，同一个 CA 可以签多张服务端证书。只要 SAN 对应各自环境的访问地址即可。我自己习惯在 CA 目录下维护一个issued/子目录，每张签出的证书按“环境-服务名-日期”命名归档。业务多了以后这个习惯会让你少很多麻烦。

5.2 过期监控与自动化续期

自建 CA 签发的证书不像商业 CA 有临近过期提醒服务，过期之后也不会自动更新。内网服务一旦证书过期，表现的错误非常隐蔽——大模型接口请求直接失败，日志里只有 SSL 握手异常，没有其他提示。

所以建议把证书到期时间管理起来。定期列出所有证书的有效期：

openssl x509 -enddate -noout -in server/server.crt

结果会有明确的可读时间输出，例如notAfter=May 3 12:00:00 2026 GMT。再进一步，可以写个简单的 cron 脚本，每月扫描一次证书目录，将到期时间在 30 天内的证书列出来，邮件或企业微信机器人通知。这一步在证书数量少的时候可能觉得没必要，但一旦超过十张，而且使用人不止自己的时候，价值非常大。

5.3 密钥轮换与安全保管

这里单独强调一下私钥安全。内网环境里，运维人员和开发人员往往都有服务器访问权限，密钥文件的权限控制和审计非常重要。

两个基本要求：一是ca.key这类 CA 私钥文件的权限至少设为600，且不要让不相关的人接触到；二是引入一个“密钥轮换”意识，比如服务端证书每半年主动换一次，即使还没到期，也当作演练操作熟练度。内网证书过期不可怕，可怕的是大家不熟悉续签流程，等到真过期了才手忙脚乱开始百度。

最后再分享一个使用技巧：内网接口加入自签名证书之前，先找一台干净的最小化测试客户端，把 curl 验证跑通，再复制这份 CA 到其他机器。这样可以避免反复分发错误文件，环境越杂越有必要坚持这个流程。