浏览器红色“不安全”警告消除指南：SSL证书与TLS配置五个实操步骤

浏览器会检查几个东西：表单页面本身是否是HTTPS，表单的提交action地址是否是HTTPS，以及页面有没有其他不安全的脚本在监听表单操作。如果用户在这个页面输入密码、手机号、身份证号，而表单提交地址居然指向HTTP，或者页面在控制台报了混合内容错误，Chrome就会把责任怪罪到整个表单位置上，在地址栏亮出一个红底白字的“不安全”，提醒用户在这里输入信息有风险。对注册登录、下单支付页面来说，这个警告可以说是致命的。

2. 动手前的准备：把问题定位到具体错误码

没搞清楚具体错误码之前，不建议你直接改服务器配置。因为“不安全”警告可能来自五个完全不同的环节，你盲目去动证书，结果问题出在混合内容上，改一晚上也白搭。所以我强烈建议你按照下面三步，先完成问题定位。

2.1 自己怎么看浏览器报错详情

每个浏览器的查看路径大同小异，以Chrome为例：打开出问题的页面，点击地址栏左侧的图标（锁、感叹号或“不安全”字样），在弹出的面板里找到“连接是安全的”或“此网站不安全”区域的“证书无效”或“连接不安全”链接，点击后进入网络错误详情页。这里会显示具体的错误码，比如NET::ERR_CERT_DATE_INVALID、ERR_SSL_PROTOCOL_ERROR、ERR_SSL_VERSION_OR_CIPHER等。

这个错误码就是你排查的第一把钥匙。千万不要只看“不安全”三个字就关掉，错误码能把你直接带到问题的根源环节。我的习惯是把错误码复制到记事本，再对照本文后面的速查表，对号入座，效率会高很多。

2.2 用本地命令确认证书状态

除了浏览器，你还可以用OpenSSL命令在服务器本地直接探测证书信息，这一步能避免浏览器缓存干扰。

bash复制# 检测域名证书有效期和证书链
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# 查看服务器支持的TLS版本
openssl s_client -connect example.com:443 -tls1_2 2>/dev/null | grep "Protocol"

第一条命令会打印出证书的生效时间和过期时间，如果你怀疑证书到期了，这里一眼就能确认。第二条命令的意思是强制用TLS 1.2协议去连接服务器，如果能正常返回证书信息，说明服务器支持TLS 1.2；如果报错或挂起，说明服务器侧压根没开TLS 1.2，那就直奔协议配置问题。这比反复刷新浏览器好用得多。

2.3 判定问题类别：是证书、协议还是混合内容

我整理了一张对照表，你可以根据自己的错误提示快速定位问题类别：

看到这里，你现在脑袋里应该有个地图了：我的报错属于哪一类，我该动哪个部分。接下来进入正题，我按标题说的5个步骤，一步一步带你把警告消掉。

3. 五步实操，把红色警告逐个击破

下面的5个步骤，每一步对应一类“不安全”问题的核心成因。实际执行时，你不一定要全部走完，对着错误类型选做即可。但既然标题说了5步，我就按从证书、到内容、到交互、到协议的完整链路，依次讲清楚。

3.1 第一步：把证书和证书链配置完整

证书问题是最常见的，但也最好修。只要你不是刻意用自签名证书，修复路径无非三件事：续期、补全证书链、确保域名匹配。

先从续期说起。如果你的证书确实是过期的，登录你申请证书的CA平台（比如Let's Encrypt、腾讯云、阿里云）重新签发即可。Let's Encrypt证书有效期只有90天，我强烈建议你配置自动续期。用certbot的话，一条命令就能搞定：

bash复制# 安装certbot后，先手动续期测试
certbot renew --dry-run

# 配置crontab每两个月自动续期
crontab -e
# 添加一行，每月1号凌晨3点执行续期检查
0 3 1 * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"

再看证书链。很多朋友把证书文件从CA平台下载下来之后，只上传了服务器证书（domain.crt），漏掉了中间证书（chain.crt），导致部分浏览器不认。Nginx的正确写法是使用CA提供的fullchain文件，或者手动把证书和中间证书拼接：

nginx复制server {
    listen 443 ssl;
    server_name example.com;

    # 推荐使用fullchain，包含证书+中间证书链
    ssl_certificate     /etc/nginx/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;
}

配置改完后记得执行nginx -t检查语法，再systemctl reload nginx重载。做完这一步，用前面第2节的OpenSSL命令重新验证证书日期和证书链，看到“Verify return code: 0 (ok)”就说明证书链路通了。

3.2 第二步：把页面里的HTTP资源全部换成HTTPS

证书没问题但还提示“不安全”，十有八九是页面里残留了HTTP资源。这种问题排查起来最简单，但改起来可能最繁琐，尤其是老站、内容多的CMS站点。

打开出问题的页面，按F12进入开发者工具，切到Console面板，筛掉其他日志，重点看标红或带“Mixed Content”字样的报错。浏览器的控制台会非常贴心地告诉你，哪个URL被拦截了，完整地址都会列出来。你只需要顺着这些URL去页面模板、数据库或配置里找，把http改成https即可。

如果资源前后端写死了域名，比如JS里写了一个http://cdn.example.com，直接全局搜出来替换成https://cdn.example.com。如果有些资源是动态拼接的，最简单的方法是直接用相对协议，也就是把http://改成//，这样浏览器会自动沿用当前页面的协议，一劳永逸：

html复制<!-- 修改前 -->
<img src="http://cdn.example.com/images/banner.png">

<!-- 修改后，相对协议，自动适配http/https -->
<img src="//cdn.example.com/images/banner.png">

我自己处理过一个用帝国CMS搭建的十年老站，图片地址全是绝对路径写死在文章内容里的。这时候靠人眼一篇文章一篇文章改根本不现实，我是直接在数据库里执行了一条SQL，把所有文章内容里的http://替换成https://，几分钟就搞定了。不过动手前一定要先备份数据库，这个操作是全局的，一旦替换错，反悔成本很高。

3.3 第三步：让表单提交彻底走HTTPS通道

表单类提示“您要提交的信息不安全”通常包含两种情况。第一种是整个表单页面本身就是HTTP，这好办，直接配置站点强制跳转HTTPS，或者让用户通过HTTPS访问页面即可。第二种更隐蔽，页面是HTTPS，但表单的action地址指向了一个HTTP链接。

网上买的模板、老系统里经常能翻到这种代码。你打开页面源码，搜一下标签的action属性，看看是不是以https://开头。如果不是，直接改成当前站点的HTTPS地址。同时拿F12的Network面板实际提交一次表单，观察请求地址和响应状态，确保整个链路都是HTTPS。

如果你用的是Nginx，比较稳妥的办法是在server块里加一条HTTP到HTTPS的301跳转，让所有访问HTTP的请求自动转到HTTPS，从入口层面杜绝表单页面走HTTP的可能：

nginx复制server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

还有一个容易忽略的点：如果表单页面本身引入了外部统计脚本或客服系统脚本，而这些脚本是HTTP的，Chrome的“不安全”同样会被触发。这种第三方脚本的HTTP地址也要一并排查，改不了地址的，最好的办法是直接干脆去掉它，或者换一家支持HTTPS的服务商。

3.4 第四步：升级协议与加密套件，解决ERR_SSL_VERSION_OR_CIPHER

这个错误我个人认为是所有“不安全”里最有门槛的一个，因为它不是在页面内容层面，而是在服务器加密能力层面。前面提到过，2020年以后主流浏览器全面淘汰TLS 1.0和TLS 1.1，如果你的服务还在用这两个老版本，现代浏览器连门都不让你进。

先检查服务器上跑的是什么Web服务以及版本。Nginx、Apache、IIS的配置方法不一样，但核心思路都是把TLS版本下限调到1.2，并把不安全的加密套件禁用掉。以Nginx为例，前面配置文件里的ssl_protocols和ssl_ciphers这两行就是关键。

nginx复制ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;

这段配置的意思是只启用TLS 1.2和TLS 1.3，加密套件只保留目前公认安全的GCM和CHACHA20系列。你可能会问，那些老的AES-CBC套件呢？我建议统统关掉，它们已经不被主流浏览器信任了。改完配置同样要重载服务，然后回到第2节，用openssl s_client -connect 域名:443 -tls1_2验证一下，能正常握手就说明协议升级成功。

如果服务器系统版本特别老，比如CentOS 6上的老OpenSSL，可能压根不支持TLS 1.2配置，这时候就不是改配置能解决的了，得升级操作系统、升级OpenSSL版本，或者把站点迁移到新环境。这也是我这几年反复劝人的原因：服务器系统该升级就升级，别拖，拖到最后坑的是自己。

3.5 第五步：处理上传拦截和PDF“不安全脚本”问题

最后这步针对的是你搜到的那条：“PDF内容包含不安全脚本或自动执行特征，已拒绝上传”。这个提示其实是浏览器端的安全扫描机制在起作用。Chrome会对下载或上传的PDF做预处理分析，如果发现PDF里嵌入了JavaScript、自动执行动作、外部链接跳转之类的内容，就判定为“不安全附件”，直接拦下来。

解决这个问题要从三个层面入手。第一层，如果PDF是业务刚需上传的，建议在后端加上文件内容校验和清洗流程，比如用PDF处理库把文件里的JavaScript和动作脚本剥离掉，再重新生成一份干净的文件存储；第二层，在上传接口的响应头里加Content-Disposition: attachment，强制浏览器把PDF当作附件下载而不是在线预览，可以绕过一部分预览型拦截；第三层，配置Content-Security-Policy响应头，告诉浏览器允许和禁止哪些内容加载，把PDF里可能触发脚本的权限收窄：

nginx复制# 在Nginx里给PDF目录单独加响应头
location ~* \.pdf$ {
    add_header Content-Disposition 'attachment; filename="$1.pdf"';
    add_header Content-Security-Policy "default-src 'none'; sandbox";
}

这里配置的sandbox属性会把PDF里可能的脚本执行环境彻底隔离，浏览器看到这个响应头，就会按“无脚本、无弹窗、无重定向”的规格去处理文件，被拦截的概率大幅下降。当然了，如果你的业务并不需要用户在线预览PDF，直接在下载响应头里设置attachment，是最省事的做法，用户点击下载，浏览器不再尝试预览，也就不会触发PDF内容扫描。

4. 常见问题与排错速查

前5步执行完，九成以上的“不安全”警告已经可以消除。但实际运维中你还会遇到一些看似正确但仍出问题的边角情况。我把这些年踩过的坑集中放在这一节，给你做排错索引。

4.1 证书明明配置了，浏览器仍然提示证书无效

这种情况大概率是证书链没配全或者服务器上有多套证书残留。先说证书链，很多运维在Nginx里只配置了域名证书，漏了中间证书，Chrome在极少数情况下能自动补全，但Firefox和Safari会直接不认，报错信息里往往带着“无法将服务器证书链接到受信任的根证书颁发机构”。处理办法在前面已经写了，用CA给的fullchain文件即可。

还有一种是服务器上挂载了多套SSL配置，而默认server块引用了一个过期证书。你改了上半部分配置，但访问流量走的却是另一个server块。这时候用nginx -T命令把当前Nginx加载的所有server配置完整打印出来，逐一遍历server_name和ssl_certificate路径，确保你访问的域名实际指向的那一套SSL配置是正确的。

4.2 修改了配置浏览器还是旧的警告

配置重载后，浏览器不一定马上刷新。这里有三层缓存需要清理：浏览器缓存、CDN缓存、HSTS缓存。

Chrome的HSTS机制会强制浏览器在指定时间内只走HTTPS，并且记住这个约定。如果你之前用HTTP访问过该域名，且响应头里带过Strict-Transport-Security，那么浏览器在HSTS有效期内无论你怎么改，都会强制走HTTPS并拦截异常。想临时清理，可以在Chrome地址栏输入chrome://net-internals/#hsts，在Delete domain一栏输入你的域名并删除。但请注意，正式环境建议保持HSTS开启，它能提升安全性，只是排错时要特别留意它。

如果你套了CDN，还要检查CDN节点上的SSL配置。CDN回源到你的服务器可能用的是HTTP，但CDN对外暴露的证书和协议版本由CDN控制台决定。很多朋友源站配置得美美的，结果CDN那边证书过期了，用户访问的其实是CDN节点的证书，跟你源站没半点关系。

4.3 局域网IP和自签名证书的问题

你搜到的那条“此站点的连接不安全 192.168.0.247 使用不受支持的协议”其实可以拆成两个信息：一是连接源是内网IP，二是协议不被支持。

内网IP遇到证书警告，往往是设备自带的Web管理页面用了一个自签名证书，而且只支持TLS 1.0。比如老款的交换机、打印机、路由器管理后台，一打开就是这种红色警告。这属于设备固件太老的范畴，能升级固件就升，不能升级就只能在浏览器里手动点击“继续前往”，或者在受控环境里把该设备的IP加入浏览器“允许不安全内容”的例外列表。对企业内网来说，更标准的做法是自建一套内网CA，给内网所有设备签发证书，然后在域环境里批量下发信任。但这个方案配置成本高，适合有独立IT团队的企业，个人用户直接用例外即可。

4.4 排错清单速查表

我最后整理了一张完整的速查表，每一行对应一个你可能会在地址栏看到的提示或错误码，后面跟着直接的处理建议。你可以把它存成书签，下次遇到问题先对着查，比百度快得多。

写在最后的一个小提醒

做完上面所有步骤，我建议你最后用在线工具给站点打一次分，重点看证书链评分、协议版本、加密套件强度这几项。很多在线检测工具能直接把你证书的部署情况用ABCDE打分，低于A的基本都还有优化空间，按照提示一项项改就是了。

我个人在实际操作中的体会是，“不安全”警告这东西，最怕的不是技术难题，而是半懂不懂的时候瞎改一气。每次动手前一定先定位清楚错误码，确认问题属于证书、协议、混合内容还是表单链路，再按对应步骤处理，基本不会翻车。另外强烈建议把证书到期监控和自动续期这种基础运维做成常态机制，别等到浏览器变红才想起来处理，那时候用户早跑光了。希望这份经验能帮你在下一次被红色警告折腾的时候，少走几步弯路。