企业官网建设流程全解析

域名解析刚生效，浏览器地址栏左边那个"不安全"三个字就先跳出来了——这是很多新手第一次在1Panel上折腾SSL 证书的场景。有人照着教程点了几步，看着面板上绿色的"已部署"心里踏实了，结果第二天换个浏览器访问，报NET::ERR_CERT_AUTHORITY_INVALID；还有人图省事用了自动签发，三个月后证书到期没续上，站点直接白屏，被用户当成挂了。我在实际运维里见过太多类似事故，所以这篇不打算写成"点这里、点那里"的截图流水账，而是把1Panel 部署 SSL 证书这件事拆成几层讲清楚：证书在哪一层生效、自动签发和手动上传各自适用什么场景、反向代理链路里证书该怎么摆、续签为什么会失效、出错时用什么命令一行行查。适合刚接手一台云服务器、准备把个人站点或内部服务从 HTTP 迁到 HTTPS 的朋友，也适合已经会点面板但没弄明白原理、遇到报错只能重装的人。

1. 先把"证书在哪一层生效"想明白

1.1 证书不是"面板的一个开关"，而是绑定在监听端口上的

新手最容易踩的认知坑，是把 SSL 证书当成 1Panel 里的一个全局状态：点一下"申请"，好像整台机器就变安全了。实际上证书是绑在具体的监听地址和端口上的，同一台机器上不同网站、不同端口，完全可以用不同的证书，甚至有的站还是 HTTP。1Panel 本身是用 OpenResty 做 Web 服务的，每个网站在配置目录下会生成一份独立的 server 配置块，证书路径、私钥路径、TLS 版本、加密套件都写在这个块里。你在面板上点"选择证书"，本质是往这份配置里写入ssl_certificate和ssl_certificate_key两行。

理解这一点之后，很多现象就顺了：为什么面板上显示证书已部署，但我访问某个子域名还是报错？因为那个子域名压根没绑到这个网站，或者绑到了一个没配证书的 server 块。为什么我用 IP 访问会提示证书名称不匹配？因为证书是签给域名的，你拿 IP 去访问，浏览器比对的是"证书里的域名"和"地址栏里的地址"，天生对不上。证书永远服务于"域名 + 端口"这个组合，脱离这个组合谈"部署成功"没有意义。

所以动手前先画一张小表，把要上 HTTPS 的入口列清楚：主域名、带 www 的、API 子域、后台管理子域、面板自身。每一项对应哪份证书、走不走 CDN、是不是反向代理到内网端口，先写下来，后面按表推进就不会乱。

1.2 一张图理清三个位置：网站、面板、反代

实际要配 HTTPS 的地方通常有三处，很多教程混着讲，导致新手以为配一处就够了。

第三处最容易被忽略。很多人把业务站配得漂漂亮亮，运维面板还开着 HTTP，登录密码在公网明文传输。1Panel 的面板 SSL 支持上传自有证书，也支持自签，自签的话浏览器会警告，但至少链路是加密的，配合安全入口和 IP 白名单，风险能压下去一截。

至于反向代理的后端，绝大多数情况下不需要证书。反代流量在回环或内网里跑，加证书只是徒增一层握手开销和维护成本。我在某公司内网见过有人给每个 Node 服务都配了自签证书，结果到期时间各不相同，每隔一段时间就有一个服务 502，排查起来极其难受。除非你的后端要跨公网、或者有合规要求必须端到端加密，否则让反代终止 TLS 就够了。

1.3 证书类型怎么挑：别一上来就买最贵的

按验证等级分 DV、OV、EV，按覆盖范围分单域名、多域名、泛域名。对个人站和内部系统，DV 完全够用，浏览器显示的小锁和 OV 是一模一样的，区别只在证书详情里有没有组织信息。只有在需要对公展示资质、或者客户合同里明确要求时，OV 才有实际意义。EV 现在主流浏览器也不再给地址栏绿标了，性价比很低。

覆盖范围这块反而更值得算。假设你有a.example.com、b.example.com、api.example.com三个子域，且以后还会加。买单域名证书就要买三张、还要维护三个到期日；一张泛域名证书*.example.com全包，但注意泛域名不覆盖多级，x.y.example.com不在这张证书的范围内。另外泛域名通常只能走 DNS 验证，不能走 HTTP 文件验证，这一点直接决定了你后面在 1Panel 里该选哪种签发方式。

2. 部署前的准备：这几件事没做，后面全白搭

2.1 域名解析：A 记录、AAAA 记录和 TTL 的坑

证书签发的前提是验证方能确认"你确实控制这个域名"。HTTP 验证要求从公网访问http://你的域名/.well-known/acme-challenge/xxx能拿到指定内容，这就要求域名解析已经指向这台机器，且 80 端口通。所以解析必须提前做，最好提前半小时以上，因为 TTL 缓存不是瞬时生效的。

最常出问题的是 AAAA 记录。如果你的域名同时有 A 记录和 AAAA 记录，而机器只有 IPv4，验证方可能优先走 IPv6，连接失败，签发就卡住。我遇到过好几次"解析明明对、就是验证不过"，最后都是删掉 AAAA 记录解决的。实操建议：签发期间只保留 A 记录，等证书下来再按需补 IPv6。

另外 IPv4 地址填错一位、或者把域名解析到了 CDN 的 IP 上，也会导致验证失败。走 CDN 的情况需要特别处理，后面第 6 节会专门说。

2.2 端口放行：80 和 443 缺一不可

HTTP 验证依赖 80；访问走 443。面板的"主机"下面有防火墙管理，云厂商控制台还有一层安全组，两层都要放行。这一点新手经常只改一层就以为完事，然后对着超时干瞪眼。

# 在服务器上确认端口监听状态 ss -lntp | grep -E ':(80|443)\b' # 确认防火墙规则（firewalld 为例） firewall-cmd --list-ports

如果ss看不到 443 监听，说明 Web 服务没起来或者配置没生效；如果本机能看到监听但外网访问超时，八成是云厂商安全组没开。这两个方向必须分开判断，别一股脑去改 Nginx 配置。

2.3 面板版本、安全入口与一次完整备份

动手前先做两件事：升级面板到较新版本，做一次快照或备份。1Panel 的版本迭代里，证书管理模块有过功能调整，老版本可能没有某些验证方式的入口，照着新教程找按钮会找不到。

备份这块我强调一次：改 HTTPS 前一定要能回滚。最省事的做法是在云厂商那边打个快照，或者把网站配置目录整个打包。

tar czf /root/site-conf-backup-$(date +%F).tar.gz \ /opt/1panel/apps/openresty/openresty/conf/ 2>/dev/null

面板里的应用和网站数据目录也建议一并备份。配 HTTPS 本身不会动数据，但一旦你把强制跳转开上，又配错了证书，用户访问会直接 4xx，回滚速度决定故障时长。我个人的习惯是：任何涉及 443 的变更，先在低峰期做，改完立刻用手机流量（不走本地缓存）访问一遍验证。

3. 两条路线：自动签发和手动上传怎么选

3.1 自动签发：省心，但要选对验证方式

1Panel 的证书菜单里可以申请免费 DV 证书，走 ACME 协议。填写邮箱、域名，选择验证方式，等待签发。验证方式主要有三类，适用场景差别很大：

个人站首选 HTTP 验证，配置最简单。要多子域或者已经在 CDN 后面，就走 DNS 接口验证。手动 DNS 验证只适合一次性场景，续签时会很痛苦，因为自动续签流程没法替你加 TXT 记录。

还有一个细节：申请时填的邮箱最好用一个能长期收信的地址，证书机构在到期前会发提醒邮件。这个提醒曾经救过我一次——某台机器上的续签任务因为磁盘满了静默失败，就是靠邮件发现的。

3.2 手动上传：商业证书和云厂商证书的落地

如果你手上已经有证书文件，1Panel 支持直接上传。上传时要注意几个字段的对应关系，搞错了会签出"证书链不完整"的错误：

• 证书（CRT/PEM）：服务器证书，有的服务商给的文件里已经包含了中间证书。
• 私钥（KEY）：和证书配对的密钥，绝对不能泄露，也不要提交到代码仓库。
• 证书链/中间证书：部分场景单独提供一个文件。

判断是否完整，可以用在线工具，但更靠谱的是本地验证：

# 查看证书包含的域名和有效期 openssl x509 -in fullchain.pem -noout -subject -dates -ext subjectAltName # 验证证书链是否完整（需要系统根证书） openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt fullchain.pem

第二条命令返回OK才算链完整。如果报unable to get local issuer certificate，就是缺中间证书，需要把中间证书拼到服务器证书后面，顺序是服务器证书在前、中间证书在后，拼反了照样报错。

3.3 格式转换：pfx 转 pem 的两行命令

不少云厂商导出的格式是.pfx或.p12，1Panel 要的是 pem 文本格式，得转一下。转换时注意-nodes参数，它让私钥不加密输出，否则面板读取私钥时会因为要密码而失败。

# 导出证书链（包含服务器证书和中间证书） openssl pkcs12 -in cert.pfx -nokeys -out fullchain.pem -nodes # 导出私钥 openssl pkcs12 -in cert.pfx -nocerts -nodes -out privkey.pem # 如果 pfx 有密码，命令会提示输入

转换完先cat fullchain.pem看一眼，正常情况下应该能看到至少两段-----BEGIN CERTIFICATE-----。只有一段的话，说明这个 pfx 里没带中间证书，得找服务商要中间证书文件。

4. 真正把 HTTPS 跑起来：网站与反向代理配置

4.1 新建站点并绑定域名的完整顺序

正确顺序是：先建站、配好 HTTP 能访问，再上证书。反过来做，一旦 443 出问题你连 HTTP 都没得测，排查会陷入两难。

在网站菜单里创建网站，填主域名，选择运行环境（静态站选静态，PHP 选对应版本，Node 项目走反向代理或独立运行环境）。创建完成后先别急着开 SSL，用浏览器访问http://你的域名，确认能打开。这一步验证的是域名解析、端口放行、站点绑定三件事同时成立。

确认 HTTP 正常后，进入网站配置里的 HTTPS 页签，选择刚才签发或上传的证书，保存。此时 1Panel 会往 server 配置块里写入证书路径并重载 OpenResty。刷新页面，地址栏应该出现小锁。如果没有，先看第 6 节的排查表。

4.2 反向代理场景：证书放在哪一层

前后端分离或者把内网服务暴露出去，一般会建一个反向代理站点。这时候证书配置在代理层，也就是 1Panel 里的这个站点上，后端服务保持 HTTP 即可。原理很简单：外部浏览器和代理层之间是加密的，代理层和内网服务之间是明文，两段独立。

配置时注意几个容易出问题的点。第一，代理目标地址要用内网 IP 或回环地址，不要写公网域名，否则会绕一圈还可能被安全组拦。第二，Host头要正确传递，很多后端框架靠这个头做路由或生成链接，透传错了会生成http://开头的绝对链接，浏览器在 HTTPS 页面加载 HTTP 资源，直接触发混合内容拦截。第三，超时时间要按业务调，默认几十秒对普通页面够用，对大文件上传或长轮询就不够。

# 反向代理后常见问题：后端生成的绝对链接还是 http # 检查代理配置里是否传递了正确的协议头 curl -I https://api.example.com/health

如果后端框架需要知道"外部其实是 HTTPS"，通常要在代理层加上X-Forwarded-Proto: https这类头，具体写法取决于框架，这件事我在第 6 节会再展开。

4.3 强制 HTTPS、HSTS 与 TLS 参数的取舍

证书配好后，建议开启 HTTP 到 HTTPS 的跳转。1Panel 的 HTTPS 页面有这个开关，打开后所有 80 请求会 301 到 443。这一步能避免用户手打域名时走进明文通道。

HSTS 要不要开？它的作用是告诉浏览器"以后这个域名只许走 HTTPS"，浏览器会记住一段时间，期间即使用户输http://也会本地转成 HTTPS，且不再询问是否信任证书。好处是防降级攻击，代价是一旦你某天证书出问题，用户连"点继续访问"的选项都没有。所以我的建议是：先在测试域名上跑一两周，确认续签稳定，再逐步把 max-age 从几百秒加到一年。上线初期直接拉满一年，等于给自己埋雷。

TLS 版本方面，现在的合理选择是只保留 TLS 1.2 和 1.3。TLS 1.0/1.1 早已被主流浏览器标记为不安全，留着只会拉低评分。加密套件用面板默认的现代组合即可，除非你要兼容很老的嵌入式客户端，否则没必要手工指定一堆。

注意：修改 TLS 版本和加密套件后，务必用旧版客户端测一次。有些企业内部还有跑老系统的机器，一刀切禁用低版本会让这部分用户直接连不上。

4.4 面板自身的 HTTPS 也别落下

业务站配完，回头看看运维面板。在面板设置里有面板 SSL 相关选项，可以上传证书，也可以让面板自签一份。自签的缺点是浏览器会警告，但链路加密是实打实的。

我的常规做法是给面板单独用一个不容易猜到的子域，比如ops-随机字符串.example.com，配上正式证书，同时开启安全入口、限制访问 IP。这样做的收益不只是加密：面板一旦暴露在公网且用默认端口，扫描器几分钟就能发现，登录接口会被反复撞库。加密 + 隐藏 + 访问控制，三件事叠加才算及格。

改面板 SSL 有个坑要提前知道：改完端口或协议，当前会话可能直接断开，你需要用新的地址重新登录。所以不要在只有单一网络入口、且身边没有备用通道的时候改，我吃过一次亏，改完发现防火墙规则也顺手改了，最后从云厂商的远程连接救回来。

5. 续签与轮转：别让"到期日"变成事故日

5.1 自动续签为什么也会失败

免费证书的有效期现在普遍在 90 天左右，且趋势是越来越短。1Panel 会为自动签发的证书安排续签任务，正常情况不用管。但它失败的原因相当多样，我按遇到频率排一下：

• 验证方式失效：换了 DNS 服务商、API 密钥过期或被删权限，DNS 验证直接挂掉。
• 80 端口被占：装了别的服务抢了 80，或者防火墙规则被改。
• 域名解析变了：机器迁移后忘了改 A 记录，验证方打到旧 IP 上。
• 磁盘或权限问题：写不进证书目录，任务静默失败。
• CDN 拦截：站点挂在 CDN 后面，HTTP 验证请求被 CDN 接走了。

这些问题的共同点是不会主动通知你，只能靠到期日兜底。所以我从来不把"自动续签"当成免维护的承诺，而是当成一个需要定期抽查的机制。

5.2 手动证书的轮转清单

手动上传的证书不会自动续签，必须在日历上标记。我给自己定的规矩是：证书到期前 30 天开始处理，留出两周缓冲给可能出现的审批、采购、格式转换问题。

轮转的时候不是简单换个文件就完事。要做的事包括：确认新证书的域名列表和旧的一致（别漏了 SAN 里的子域）；确认私钥和证书配对；更新后重启或重载服务；清理旧文件但保留一份最近过期的做对照；记录新证书的到期时间。如果是多台机器共用一张证书，那每一台都要更新，漏一台就是隐患。我见过最典型的事故是多机部署，运维只更新了主节点，备用节点上的证书过期，切换流量时用户全部报错。

5.3 加一道外部监控，别只信任面板

面板显示"正常"不代表外部访问正常。最稳妥的是加一个外部可用性监控，从公网定时探测你的域名，同时检查证书剩余有效期。很多免费监控服务都支持证书到期提醒。

如果不想依赖外部服务，写个简单的脚本跑定时任务也够用：

#!/bin/bash # 检查证书剩余天数，低于 21 天报警 DOMAIN="example.com" END_DATE=$(echo | openssl s_client -servername "$DOMAIN" \ -connect "$DOMAIN:443" 2>/dev/null \ | openssl x509 -noout -enddate | cut -d= -f2) END_TS=$(date -d "$END_DATE" +%s) NOW_TS=$(date +%s) DAYS=$(( (END_TS - NOW_TS) / 86400 )) echo "剩余 $DAYS 天" [ "$DAYS" -lt 21 ] && echo "证书即将过期，请处理"

这个脚本的关键是从外部探测，而不是读本地文件——它能同时发现"证书没续上"和"服务根本没起来"两类问题。

6. 报错实录：从现象倒推原因

6.1 浏览器报错对照表

把常见报错和对因整理成表，遇到问题先查表定位方向，再去翻具体配置。

表格之外补一句：先用无痕窗口测。浏览器会缓存 HSTS 状态和证书信息，普通窗口里改了配置可能看不到变化，白白浪费排查时间。

6.2 三条命令定位大半问题

命令行比浏览器更能说明问题。第一条看握手和证书链：

openssl s_client -connect example.com:443 -servername example.com < /dev/null

输出里注意Verify return code，0 表示链完整，非 0 大多是缺中间证书。第二条看证书详情：

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

重点看 SAN 里到底列了哪些域名，很多"名称不匹配"就是这里少了一条。第三条确认跳转和响应头：

curl -I http://example.com curl -I https://example.com

第一条应该返回 301 且 Location 指向 https，第二条返回 200。如果第二条返回 502，问题在反代后端，跟证书无关，方向要立刻切换。

6.3 几个排查时容易走错的方向

误把 502 当证书问题。证书出问题，浏览器是拒绝建立连接，你根本收不到 HTTP 响应。能收到 502、504 这类状态码，说明 TLS 握手已经成功，问题在后端。这个判断非常重要，能省掉大量无用功。

忘了 CDN 这一层。站点挂 CDN 后，用户访问的是 CDN 节点，节点回源到你的服务器。这时候你本地证书配得再好，用户看到的还是 CDN 上的证书。要么在 CDN 侧上传证书，要么把 CDN 的回源协议改成 HTTPS 并信任源站证书。如果 CDN 的回源走 HTTP 文件验证被拦，就得改用 DNS 验证签发。

内网访问被证书拦住。用192.168.x.x访问配了域名证书的站点，必然报名称不匹配。规范做法是内网也走域名解析，或者接受这个警告仅在内部使用。

反向代理导致的重定向循环。开了强制 HTTPS，后端又自己判断协议做跳转，两边互相踢皮球，浏览器报"重定向次数过多"。解决办法是让代理层传递正确的协议头，或者只在一处做跳转。

7. 我在实际部署里攒下的几条经验

配置 HTTPS 这件事，技术门槛其实不高，难的是把边界情况想全。我总结几条自己反复验证过的心得。

第一，先把 HTTP 跑通再上证书。这个顺序看着笨，但能把"域名、端口、站点绑定"和"证书配置"两类问题彻底分开。反过来做，一旦不通，你面对的是三重变量的组合，排查时间会翻好几倍。

第二，每次变更只动一个变量。改证书、改跳转、改 TLS 版本、改反代，一次只做一件，做完立刻验证。我见过有人一次性全部改完，出问题后完全不知道是哪一步引起的，最后只能整体回滚重来。

第三，证书文件统一放一个固定目录并做好命名。1Panel 上传证书后会自己管理路径，但如果你手工维护文件，建议用域名-到期年月-fullchain.pem这种命名，一眼能看出新旧和有效期。轮转时最怕拿错文件，这种低级错误造成的线上故障并不少见。

第四，把"到期前 30 天"当成硬性检查点。不管是自动签发还是手动证书，都去检查一次。自动续签失败往往是静默的，而 30 天足够你从容处理；等到剩三天才发现，就只能在深夜救火了。

第五，测试要用外部视角。本机curl localhost通不代表公网通，本地浏览器正常不代表别人的浏览器正常。手机切到移动网络、用无痕窗口、换一个 DNS 解析器，这几个动作花不了两分钟，却能提前发现大部分问题。我现在每次改完 443，都会用手机流量访问一遍主域和一个子域，这已经成了肌肉记忆。