企业官网建设流程全解析

现在很多人在浏览器里看到"不安全"三个字就慌了，第一反应是电脑中毒或者网站被黑，其实大部分情况没那么严重。地址栏左边那行小字、那个被划掉的锁头、还有跳出来拦你一面的红色警告页，背后是完全不同的两套机制，触发条件、报警原因、处理方式都不一样。我这些年帮人看过的网站，从个人博客到企业内部管理系统，出现"您与此网站之间建立的连接不安全"这类提示的场景少说也有几十种，真正属于被攻击的其实极少，绝大多数是配置漏了一行、证书忘了续、或者页面里混进了一个旧资源。这篇就把这件事从头到尾拆一遍：先分清浏览器到底在报哪种警，再讲证书校验的三道关卡是怎么卡的，然后给出用浏览器和命令行一步步定位根因的完整链路，最后落到Nginx、证书续期、混合内容这几个真实会动手改的地方。不管你是自己搭过站的开发者，还是只会点鼠标的普通访客，看完都能对号入座。

1. 地址栏的"不安全"和整页拦截的"连接不安全"，根本不是一回事

很多人把这两种情况当成同一个问题，其实它们连触发原理都不在一个层面上。搞清楚这个区别，排查方向立刻能省掉一半时间。

1.1 两种提示的触发条件完全不同

先说第一种，地址栏左侧显示"不安全"或者一个带感叹号的图标，但页面内容照常显示，你照样能看文章、能填表单、能登录。这种情况几乎只有一个原因：这个页面是通过 HTTP 明文协议加载的，压根没有启用 HTTPS。浏览器做的事情很简单，它看到协议是http://而不是https://，就知道你和服务器之间的所有数据——包括你输入的账号密码、搜索词、表单内容——在网络传输链路里是明文状态，任何中间节点理论上都能看到。所以它贴个标签提醒你，但不会拦你，因为技术上没有什么"错误"发生，只是不安全而已。

第二种是整页拦截，浏览器在你面前竖一块大红屏，写着"您的连接不是私密连接"或者"此网站无法提供安全连接"，下面有个"高级"按钮，点开才能继续访问。这一种是证书校验失败导致的。浏览器确实尝试建立了加密连接，但在握手阶段验证书的时候发现不对劲，于是主动中断。这两者的关系可以用一个类比说清楚：第一种是你家门没装锁，邻居路过提醒你一句；第二种是你装了锁，但锁芯被人换过、钥匙对不上、或者锁已经锈死打不开，开锁师傅干脆拒绝给你开门。

1.2 看懂地址栏那把小锁背后的三种状态

Chrome、Edge、Firefox 现在对地址栏图标做了简化，但状态其实分三档，值得记住：

还有一个容易被忽略的中间态：页面本身是 HTTPS 加载的，锁头也正常，但打开开发者工具会看到"此页面存在混合内容"的警告，某些资源被浏览器静默拦截了，导致页面样式错乱、图片不显示、按钮点了没反应。这种情况地址栏不会有明显提示，但功能已经坏了，属于比较隐蔽的一类。

提示：如果你只是想快速判断问题类型，先看地址栏图标。锁头正常但功能异常，往混合内容方向查；整页被拦，往证书方向查；只有"不安全"字样，直接查站点有没有 HTTPS。

我见过不少人一看到"不安全"就去检查服务器是不是被入侵了，这个方向基本是白费力气。真正要做的第一件事，是把提示文案和图标状态记清楚，再决定往哪个方向挖。

2. 证书校验到底在校什么：三道关卡，一道不过就报警

既然整页拦截是证书问题，那就得先弄明白浏览器验证书时具体在看什么。这块逻辑其实相当固定，理解之后你会发现所有报错都能归到三条线上。

2.1 有效期：为什么总有网站栽在这一关

每张 TLS 证书都有明确的有效期，签发的这一刻起算，到某个时间点自动失效。浏览器在校验时第一件事就是拿当前系统时间去和证书上的notBefore、notAfter做比较，只要当前时间落在区间外，直接判定无效。这类报错在 Chrome 里对应的错误码通常是NET::ERR_CERT_DATE_INVALID。

这个问题之所以高频，跟证书市场这几年的变化有直接关系。早些年很多人图省事买三年的证书，续一次管三年，忘记的概率低。后来主流 CA 机构为了推动自动化续期，把单张证书的最长有效期逐步压缩到一年以内，免费证书更是只有 90 天。周期一短，靠人工记日历就非常容易漏。我印象最深的一次是帮一个客户看他们的活动报名页，周日晚上八点突然全站报红，一查发现证书是九十个自然日前签发的，正好在当天下午到期，而负责续期的同事那天休假。

这里有个细节值得说清楚：证书过期不是"过了零点才失效"，而是精确到秒。而且客户端和服务端如果时间不同步，可能出现服务端认为还早、客户端认为已经过期的情况。所以排查时不要只看服务器时间，也要确认访问者本机时间是否正确。曾经有用户因为笔记本时间被手动改到了 2019 年，导致访问所有 https 站点都报错，最后查了半天才发现是自己系统时钟的问题。

2.2 域名匹配：证书是给谁签的，只能给谁用

第二道关卡是域名匹配。证书里有一个或多个被称为 SAN 的字段，列出的是这张证书被授权覆盖的所有域名。浏览器会拿你实际访问的主机名去和这张列表逐一比对，一个都对不上就报NET::ERR_CERT_COMMON_NAME_INVALID。

这里容易踩的坑集中在几种场景。第一种是裸域和带 www 的域没配全，证书里只有example.com，但你访问的是www.example.com，那就对不上。第二种是子域名没覆盖到，主域证书签的是example.com，但业务跑在api.example.com上，同样不匹配。第三种更隐蔽，是内部系统用 IP 地址直连，而证书是给域名签的，IP 和域名走的是两套匹配逻辑，直接失败。

还有一种情况是通配符证书的边界问题。形如*.example.com的证书只能覆盖一层子域名，a.example.com匹配，a.b.example.com不匹配。很多人以为带了星号就通吃，实际不是。

注意：域名匹配只看 SAN 字段，现代浏览器已经完全忽略早期的 CN 字段。所以如果你用工具生成证书时只填了 Common Name 没填 SAN，即使名字看着一样，照样报错。

2.3 信任链：从站点证书一路摸到根证书

第三道关卡是整个校验里最容易出问题、也最难直观理解的一环。浏览器并不直接信任任何一张站点证书，它信任的是一批预装在操作系统和浏览器里的根证书。站点证书要能通过校验，必须能沿着一条签名链一路回溯到某个受信任的根证书上。

这条链的典型结构是三层：根证书签发给中间证书，中间证书再签发给你的站点证书。服务器在 TLS 握手时应该把站点证书和所有中间证书一起发过来，客户端拿着这条链去和自己的根证书列表比对。如果服务器只发了站点证书、漏了中间证书，客户端就可能找不到通往根的路径，报NET::ERR_CERT_AUTHORITY_INVALID或者提示证书链不完整。

这个问题的迷惑性在于：有些浏览器能打开，有些打不开。因为不同平台、不同版本对链的拼接策略不一样，某些客户端会自己去下载缺失的中间证书补上，另一些则严格报错。于是你会在用户反馈里看到"我用 Chrome 能上，同事用某个内置浏览器就打不开"这种诡异现象，根源基本都在这里。

还有一类是自签名证书和内部 CA。企业内网系统为了省事，常常自己生成一张证书直接用，这张证书不在任何公共根证书列表里，浏览器自然判定不可信。这不一定意味着配置错了，而是信任范围的问题——要么把这张自签根证书手动导入到每一台客户端设备，要么老老实实走公共 CA 签一张。

把三道关卡放在一起看就清楚了：有效期看时间，域名匹配看名字，信任链看路径。任何一条不满足，浏览器都会中断连接。实际排查时，八成的问题落在第一和第三条上。

3. 五类高频报错的现场定位手法

知道了原理，接下来就是怎么快速判断你遇到的是哪一种。这部分给一套我平时实际用的定位流程，从浏览器界面开始，到命令行确认，最后把错误码和根因对上号。

3.1 用开发者工具的安全面板做初筛

第一步永远是打开浏览器的开发者工具，切到 Security（安全）面板。这个面板会直接告诉你当前页面的连接状态、用的什么 TLS 版本、证书是谁签的、有效期到哪天。

如果页面已经被拦截进不去，可以换个思路：先在能访问的环境里打开，或者直接看浏览器给出的错误码。Chrome 的错误码信息量很大，常见的几个对应关系如下：

这里特别提醒一句：看到ERR_CERT_AUTHORITY_INVALID不要下意识认定服务器被攻击或者证书被伪造。我处理过的案例里，这个错误绝大多数来自自签名证书和链不完整，真正涉及证书被替换的情况非常罕见。判断方法很简单，用下面这条命令直接看服务端返回的证书链，一眼就能看出问题在哪。

3.2 用命令行把证书链一层层剥开看

浏览器界面给的是结论，命令行给的是过程。我最常用来诊断证书问题的是这条：

openssl s_client -connect example.com:443 -servername example.com -showcerts

这条命令做的事是把 TLS 握手过程手动走一遍，然后把服务端返回的所有证书按顺序打印出来。几个关键看点：

• 输出里Certificate chain段落下面有几张证书。正常情况下应该至少两张：一张站点证书，一张中间证书。如果只有一张，链不完整的嫌疑就很大了。
• 注意s:和i:这两行，前者是 Subject，也就是这张证书是给谁的；后者是 Issuer，也就是谁签的。链的正确性就看下一张证书的 Subject 是否等于上一张的 Issuer，一层层接上去。
• 不看全文的话，可以直接加| openssl x509 -noout -dates -subject只看有效期和主体，速度快很多。

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

输出里notBefore和notAfter就是有效期，直接和当前时间对比即可。这一步能把"证书过期"和"域名不匹配"这两类问题一次性确认掉，比在浏览器里来回点快得多。

如果是内网 IP 直连的场景，-connect后面直接写 IP 加端口就行，但记得-servername参数就没意义了，因为 SNI 依赖域名。

3.3 从报错到根因的完整排查链路

我把平时的排查顺序整理成一条链路，照着走基本不会绕远路：

1. 确认提示类型。整页被拦，走证书方向；只有"不安全"字样，先确认站点是否启用了 HTTPS。
2. 记录错误码。浏览器拦截页通常会显示，或者在控制台里能看到。错误码是最直接的线索。
3. 本地快速验链。用上面的 openssl 命令看服务端到底发了什么证书，有效期、主体、链长度一目了然。
4. 对比域名。把访问的域名和证书 SAN 列表逐字对比，特别留意 www、子域名、端口这几个易错点。
5. 检查客户端时间。如果只有个别用户报错，先让对方看一眼系统时间。
6. 确认是否为自签名。看 Issuer 是不是某个公共 CA，如果不是，基本可以定性。

这条链路走下来，九成以上的证书问题能当场定位到具体原因。剩下的那一成，通常是服务端配置层面的问题，比如 TLS 版本和加密套件不匹配，这个就得去看服务器日志了。

4. 定位到根因之后，配置层怎么改才不再犯

知道自己踩的是哪一个坑之后，修复本身其实不复杂，难的是让它别反复出现。下面这几块是我改动最多、也最值得一次性做扎实的地方。

4.1 Nginx 上最容易配错的几行

用 Nginx 做反向代理的站点，证书配置一般就这几行，但细节特别多：

server { listen 443 ssl; server_name example.com www.example.com; ssl_certificate /etc/nginx/certs/fullchain.pem; ssl_certificate_key /etc/nginx/certs/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; } }

第一个也是最常错的地方：ssl_certificate指向的文件。很多证书签发工具会生成两个文件，一个是只含站点证书的cert.pem，一个是站点证书加中间证书拼在一起的fullchain.pem。必须用 fullchain 那个，因为 Nginx 只会把ssl_certificate指定的内容发给客户端。如果你填了只含站点证书的文件，链就断在这里了，客户端就会报不受信任。这就是前面说的链不完整问题的最常见来源。

第二个是server_name和证书覆盖域名的对应关系。如果证书只签了example.com，但server_name里写了www.example.com，访问 www 的时候就会报域名不匹配。要么把两个域名都签进证书，要么给 www 单独配一段跳转。

第三个是协议版本。TLSv1和TLSv1.1现在已经被主流浏览器全面弃用，如果你的配置里还留着它们，某些情况下会触发协议错误。直接只留TLSv1.2和TLSv1.3就好。

改完记得先跑一次配置检查，再平滑重载：

nginx -t && nginx -s reload

nginx -t会校验配置语法和证书文件能不能正常读取，这一步能挡掉相当一部分低级错误。

4.2 续期自动化和到期监控

证书过期是纯人为疏忽，靠记日历不靠谱，得靠自动化。现在主流的免费证书签发工具都自带续期能力，一般是通过一个定时任务在证书剩余有效期不足某个天数时自动重新签发，然后触发服务重载。

配置这套自动化时有几个点要注意：

• 续期任务本身要有日志。很多人的自动续期配了但失败了，因为没有任何输出，直到证书过期才发现。至少让任务把结果写进文件，定期看一眼。
• 续期成功不等于服务生效。新证书签发下来了，但服务还挂着旧证书，这是因为没触发重载。要在续期成功后自动执行重载，或者让服务自己定时重读证书文件。
• 单独加一层到期监控。不管自动化做得多完善，都应该有一个独立的外部检测：定期从外部请求你的站点，读取证书到期时间，剩余天数低于阈值就告警。这层和续期任务是解耦的，能兜住自动化本身挂掉的情况。

具体阈值我一般设成 30 天告警、14 天严重告警。对于 90 天有效期的证书来说，这个提前量足够处理各种意外。

4.3 混合内容的排查与收敛

混合内容这一类不出现在拦截页上，功能却坏了，排查起来更绕。它的定义是：页面通过 HTTPS 加载，但里面引用的某些资源仍然走 HTTP。浏览器为了保护用户，会把这些不安全的资源拦下来。

最典型的场景是文章里插入的图片、视频用的还是老地址，或者某个第三方脚本、统计代码、字体文件里写死了 http 链接。表现是页面能打开、锁头正常，但图片位置一片空白，或者控制台里刷出一堆警告。

排查手段很直接：打开开发者工具的控制台，过滤Mixed Content关键词，所有被拦的资源会一条条列出来，带上完整的 URL。看到之后把对应的 http 地址改成 https，或者改成不写协议的相对地址，让浏览器按当前页面协议自动补全。

对于那种历史包袱很重、资源地址散落各处、一时半会儿改不完的站点，可以先用一个折中方案：

add_header Content-Security-Policy "upgrade-insecure-requests" always;

这个响应头会让浏览器在加载页面时，自动把页面内的 http 资源请求升级成 https。它是个治标不治本的办法，只解决了"浏览器主动拦截"这一层，如果目标地址本身不支持 https，升级后请求会直接失败，那问题反而更明显了。所以它适合作为过渡，最终还是要老老实实把资源地址改干净。

提示：搜索类网站、统计类脚本、第三方评论系统是混合内容的高发区。接入这些外部服务前，先确认它们的资源地址是不是全站 https。

5. 几个我踩过和见过的坑，比原理更值得记住

前面讲的都是通用逻辑，但真正让人卡住的往往是些边角情况。这几个是我在实际处理中反复遇到的，单独拎出来说。

同一台服务器上多个站点，证书文件覆盖了。一台机器上跑了五六个站点，每个站点有自己的证书目录。某次续期脚本的路径变量写错，把所有站点都指向了同一个fullchain.pem，结果其中几个域名不匹配的站点集体报错。这类问题的表现是"只有部分站点出问题"，排查时要注意区分是配置问题还是证书本身的问题，别一上来就怀疑证书签发方。

CDN 回源配置导致证书来源不一致。站点前面套了一层 CDN，浏览器看到的是 CDN 节点上的证书，而源站上的证书配置完全是另一回事。这时候在源站上怎么改都看不到效果，因为用户根本不和源站握手。遇到"改了配置但没有任何变化"的情况，先确认是不是有 CDN 或其他代理层在中间。

手动导入自签根证书后，换设备又报错。内网系统的自签证书需要导入到每个客户端才受信任。很多人只在开发机上导过一次，换台电脑或者换个人访问就报AUTHORITY_INVALID。这种如果设备量大，运维成本很高，条件允许的话还是走公共 CA 签一张更省心。

系统时间错乱导致的假故障。前面提过，这里再强调一次。服务端和客户端的时钟都要看，尤其是虚拟机和容器环境，宿主机时间被改过之后，容器里的时间可能跟着漂移。表现就是所有 https 站点全部报错，这时候任何证书层面的排查都是白费力气。

协议版本和加密套件的兼容性问题。有一种情况是证书完全正常，链也完整，但就是连不上，报的还不是证书类错误。这通常是服务端只开了某些较新的加密套件，或者只允许某个 TLS 版本，而客户端恰好不支持。这类问题排查方向完全不同，看服务端的 TLS 配置和日志，而不是折腾证书。

地址栏提示和实际内容不匹配的迷惑现象。有个朋友遇到过：地址栏显示"不安全"，但页面内容完全正常，他以为只是显示问题没管，结果几天后发现有人在后台批量尝试登录。原因就是站点长期跑在 HTTP 上，登录表单提交的账号密码在网络里明文传输。这类情况下浏览器给的提示是准确的，别因为"功能没坏"就忽略它。

最后分享一个我自己常用的小习惯：任何站点上线之前，先让三四个不同设备、不同浏览器各访问一遍，重点看地址栏图标和控制台有没有警告。这一步花不了几分钟，但能挡掉绝大部分上线后才暴露的证书和资源问题。等用户来反馈的时候，往往已经影响了一批人。