Chrome 证书错误绕过指南：thisisunsafe 与启动参数实战

1. 那个红色警告页到底在拦什么做内网开发、测试环境部署或者本地联调的时候你大概率见过那个页面浏览器地址栏左边挂着红色三角页面正中一行大字“您的连接不是私密连接”下面跟着NET::ERR_CERT_AUTHORITY_INVALID或者NET::ERR_CERT_COMMON_NAME_INVALID之类的错误码最底下藏着一个“高级”按钮点开才有“继续前往”的小链接。很多人第一反应是点高级、点继续但有些版本的 Chrome 把这个入口收得更深甚至直接不给点于是就有了thisisunsafe这个口口相传的“咒语”。这篇东西就是围绕这个场景展开的Chrome 提示连接不是私密连接时怎么用thisisunsafe临时绕过以及怎么通过启动参数--ignore-certificate-errors从根上让浏览器不再拦你。适合谁看做前后端联调、内网系统维护、自签名证书测试、老旧设备管理页访问的从业者。如果你只是普通上网遇到这个提示那要警惕可能是真的证书有问题但如果你明确知道自己访问的是自己搭的服务、用的是自签名证书那下面的内容就是给你准备的。先把话说在前面这两个手段都是降低浏览器安全校验的操作只应该用在你自己可控的、明确信任的环境里。公网访问、涉及账号密码和支付的页面绝对不要用这套方法去“硬闯”。这不是危言耸听浏览器拦你是有理由的绕过它等于你自己承担中间人攻击的风险。2. 先搞懂 Chrome 为什么拦你2.1 证书校验这条链到底怎么走的要理解怎么绕过得先知道它在校验什么。HTTPS 握手的时候服务器会把自己的 SSL 证书发给浏览器浏览器拿到证书后要做几件事第一看这张证书是不是由它信任的根证书颁发机构CA签发的也就是顺着证书链往上追能不能追到一个系统或浏览器内置信任的根第二看证书上的域名跟你访问的地址对不对得上第三看证书有没有过期、有没有被吊销。自签名证书的问题就出在第一步。你自己用工具生成的那张证书签发者就是你自己这个“你自己”不在 Chrome 的信任列表里所以链条追到一半就断了浏览器直接判定NET::ERR_CERT_AUTHORITY_INVALID。内网系统常见的情况还有域名对不上比如证书是给192.168.1.10签的你却用localhost访问那就是NET::ERR_CERT_COMMON_NAME_INVALID。2.2 为什么 Chrome 越来越不让你“点继续”早些年 Chrome 的警告页上“继续前往”是个显眼的按钮点一下就进去了。后来 Google 逐步收紧把这个入口改成藏在“高级”折叠面板里的小链接再后来对某些高危错误码干脆不给继续的选项。这个演变的逻辑很简单绝大多数普通用户遇到证书错误是真的遇到了风险让他们轻易点过去是不负责任的。但对开发者来说这就很烦。你明明知道对面是自己刚起的 Nginx证书是自己五分钟前用 openssl 生成的浏览器却一副如临大敌的样子。于是社区里就流传开了thisisunsafe这个键盘输入的后门以及启动参数这种更彻底的办法。理解了这个背景你就明白为什么这两个方法有效——它们本质上都是在告诉 Chrome“我知道风险放我过去”。3. thisisunsafe 的正确打开方式3.1 它不是输入框是键盘直接敲很多人第一次听说thisisunsafe会去找输入框结果找不到。这个命令的关键在于它没有输入框你需要在警告页面上直接用键盘盲打这串字符。对就是页面处于焦点状态时直接敲t-h-i-s-i-s-u-n-s-a-f-e这十二个字母不需要点任何地方不需要按回车。敲完之后页面会立刻刷新并跳转到目标地址。原理是 Chrome 在这个错误页面上挂了一个隐藏的键盘事件监听当你连续输入这串特定字符串时就触发“用户已知晓风险并坚持继续”的逻辑。这个设计挺巧妙的普通用户不可能碰巧敲出这串字符只有知道这个技巧的人才用得了等于变相做了个“开发者口令”。3.2 操作步骤和几个容易踩的坑完整流程是这样的访问目标地址出现红色警告页鼠标在页面上随便点一下确保页面有焦点有时候从别的窗口切过来焦点不在然后直接敲thisisunsafe。敲的过程中页面上不会有任何输入框显示你敲了什么这是正常的别以为没生效就停下来。几个实测下来的坑输入法必须是英文状态。中文输入法下敲出来的是拼音Chrome 收不到那串字符。这是最常见的失败原因我见过太多人卡在这里。大小写不敏感但建议全小写。实测ThisIsUnsafe也能触发但为了稳妥就全小写。只对当前这个错误页有效。你绕过一次换个端口、换个域名下次还得重新敲。它不是一个全局开关。某些 Chrome 版本对特定错误码禁用了这个后门。比如 HSTS 强制 HTTPS 的站点或者证书被明确吊销的情况敲了也没用。提示thisisunsafe是临时手段刷新页面、关掉标签页再打开警告还会回来。它适合“我就看一眼这个页面”的场景不适合长期开发。3.3 它和 badidea 的关系顺带提一句早期 Chrome 用的是badidea这个字符串后来改成了thisisunsafe。如果你在网上看到老教程说敲badidea那是过时的信息现在的版本不认了。这个细节说明 Chrome 团队是有意在轮换这个口令避免它被滥用得太厉害。所以哪天thisisunsafe突然失效了也别惊讶去社区看看是不是又换新词了。4. 启动参数方案一劳永逸但更危险4.1 --ignore-certificate-errors 到底做了什么如果你要长期在自签名证书环境下开发每次敲thisisunsafe显然不现实。这时候就该上启动参数了。核心参数是--ignore-certificate-errors顾名思义让 Chrome 忽略所有证书错误。加上它之后不管证书是自签名的、过期的还是域名对不上的浏览器都不再拦截直接放行。这个参数的威力比thisisunsafe大得多因为它是个全局开关对所有站点生效。这也正是它危险的地方——你在这个浏览器实例里访问任何 HTTPS 站点都不会再有证书校验的保护。所以我的建议是专门开一个带这个参数的 Chrome 实例用于开发不要用它日常上网。4.2 各平台配置启动参数的具体做法不同系统下给 Chrome 加启动参数的方式不一样这里把常用的几种列出来。Windows 下最直接的是改快捷方式。右键 Chrome 快捷方式属性在“目标”那一栏的末尾加上参数。注意路径和参数之间要有空格参数要加在引号外面C:\Program Files\Google\Chrome\Application\chrome.exe --ignore-certificate-errors如果你不想动原来的快捷方式可以复制一个出来专门做开发用改个名字叫“Chrome-Dev”这样两个实例互不干扰。macOS 下从命令行启动最方便/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --ignore-certificate-errors想做成常驻的话可以写个 shell 脚本或者用 Automator 包一个应用。Linux 下同理直接命令行带参数启动或者改.desktop文件里的Exec行。4.3 配套参数组合与用户数据目录隔离单独一个--ignore-certificate-errors有时候还不够实际开发中我通常会配一组参数一起用。下面这个组合是我用得最顺手的chrome --ignore-certificate-errors \ --ignore-certificate-errors-spki-list \ --user-data-dir/tmp/chrome-dev-profile \ --allow-running-insecure-content逐个说下为什么加它们。--user-data-dir指定一个独立的用户数据目录这是关键——它让你的开发实例和日常实例完全隔离书签、登录状态、扩展都不共享避免污染你正常用的浏览器。--allow-running-insecure-content解决的是混合内容问题HTTPS 页面里加载 HTTP 资源时不再拦截内网系统经常有这种历史遗留。--ignore-certificate-errors-spki-list是针对特定证书指纹放行的更精细的做法适合你只想信任某一张特定证书的场景。注意--user-data-dir指向的目录如果不存在Chrome 会自动创建。建议放在临时目录或者专门的项目目录下方便清理。4.4 参数方案的适用边界启动参数方案不是万能的。有些企业环境有组策略强制证书校验启动参数会被覆盖有些 Chrome 版本对--ignore-certificate-errors做了限制比如只在特定条件下生效。另外用这个参数启动的实例地址栏会一直显示“不安全”的提示这是正常的别以为是没生效。还有一个容易被忽略的点如果你用 Selenium、Puppeteer 这类自动化工具驱动 Chrome加参数的方式是在启动选项里配置而不是改快捷方式。比如 Puppeteer 里是args: [--ignore-certificate-errors]Selenium 里是ChromeOptions().add_argument(--ignore-certificate-errors)。这个在自动化测试自签名站点时特别常用。5. 两种方案怎么选一张表说清楚对比维度thisisunsafe启动参数 --ignore-certificate-errors生效范围仅当前错误页整个浏览器实例所有站点持久性刷新即失效实例存活期间一直有效操作成本每次都要敲配置一次即可安全风险低单次单页高全局关闭校验适用场景临时看一眼长期开发调试是否影响日常浏览不影响若共用实例则影响自动化工具支持不适用原生支持选哪个其实取决于你的使用频率。偶尔遇到一次敲thisisunsafe最省事天天跟自签名证书打交道那就老老实实配个带参数的独立实例。我个人的习惯是两者都留着日常用参数实例偶尔在正常浏览器里碰到内网页面就敲一下。6. 比绕过更该做的事把证书配对6.1 自签名证书的正确生成姿势绕过警告是治标把证书配对才是治本。很多内网系统的证书问题根源在于生成的时候就没考虑周全。用 openssl 生成自签名证书时关键是要把 SANSubject Alternative Name配全把你要用的所有域名和 IP 都写进去。只配 CN 字段的老做法现代 Chrome 已经不认了。一个能覆盖多域名和多 IP 的配置大概长这样openssl req -x509 -newkey rsa:2048 -nodes \ -keyout server.key -out server.crt -days 825 \ -subj /CNdev.local \ -addext subjectAltNameDNS:dev.local,DNS:*.dev.local,IP:127.0.0.1,IP:192.168.1.10这里-days 825是有讲究的现代浏览器对证书有效期有上限要求超过一定天数的证书会被判定不合规825 天是个相对安全的数值。SAN 里把*.dev.local通配域名和常用 IP 都列上基本能覆盖本地开发的各种访问方式。6.2 把自签名根证书装进系统信任区比每次绕过更优雅的做法是把你自己的根证书装进操作系统的信任区。这样 Chrome 走正常的证书链校验就能通过根本不会弹警告。做法是先生成一个根证书CA用它去签发服务器证书然后把根证书导入系统。Windows 下双击.crt文件选择“安装证书”存到“受信任的根证书颁发机构”。macOS 下用钥匙串访问导入然后手动把信任设置为“始终信任”。Linux 下把证书拷到/usr/local/share/ca-certificates/然后跑update-ca-certificates。这个方案的好处是彻底、干净不用改任何浏览器配置。缺点是根证书一旦泄露用它签的所有证书都失去意义所以私钥要保管好。团队协作的话可以把根证书分发给成员各自导入服务器证书统一用这个根签。6.3 Nginx 配置自签名证书的实操证书生成好了Nginx 这边配置也有讲究。基础的 HTTPS 配置大概是这样server { listen 443 ssl; server_name dev.local; ssl_certificate /etc/nginx/certs/server.crt; ssl_certificate_key /etc/nginx/certs/server.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; location / { root /var/www/html; index index.html; } }这里有个常见坑ssl_certificate如果配的是服务器证书而中间证书没一起带上浏览器会报“证书链不完整”。自签名场景下通常只有一张证书问题不大但如果你用的是商业 CA 签发的证书一定要把中间证书和服务器证书按顺序拼在一个文件里服务器证书在前中间证书在后。7. 常见问题排查速查表实际用这套东西的时候问题五花八门我把踩过的和见过的整理成一张表方便对照排查。现象可能原因解决办法敲 thisisunsafe 没反应输入法不是英文切到英文输入法重敲敲了还是跳不过去页面焦点不在先在页面上点一下再敲敲了没用且是 HSTS 站点HSTS 强制校验清 HSTS 记录或换域名启动参数不生效参数位置或格式错检查引号内外、空格参数生效但地址栏仍显示不安全正常现象忽略功能不受影响自动化工具里参数无效参数没传进 options检查 add_argument 调用证书装了还报错证书链不完整拼接中间证书域名对不上SAN 没配全重新生成含 SAN 的证书证书突然失效过期了检查有效期并续期换端口后又要重新绕过thisisunsafe 单页有效属正常用参数方案这张表里我特别想强调“证书链不完整”这一条。很多人从云服务商下载证书时只下了服务器证书那一个文件忘了中间证书结果浏览器报错但看不出所以然。判断方法是用在线工具或者openssl s_client -connect看返回的证书链有几张正常应该是服务器证书加至少一张中间证书。8. 几个我踩过的坑和私房技巧先说一个关于thisisunsafe的冷知识它在某些情况下需要你先按一下 Tab 键或者点击页面空白处确保键盘事件被正确捕获。我有次在双屏环境下鼠标在另一个屏幕焦点没切过来敲了半天没反应切过来一点就好了。这种细节文档里不会写但实际很影响体验。关于启动参数我强烈建议用独立的用户数据目录前面提过这里再强调一次。有次我图省事直接在常用 Chrome 上加参数结果那个实例里所有站点的证书校验都关了包括网银和邮箱虽然没出事但想想后怕。后来就固定用/tmp下的临时目录用完就删干净利落。还有一个技巧是给开发用的 Chrome 实例单独建一个快捷方式并固定到任务栏图标可以换个颜色区分。这样你一眼就能看出哪个是“放行一切”的开发实例哪个是正常上网的实例避免混用。这个习惯救过我好几次。最后说下证书续期。自签名证书设了有效期到期后浏览器又开始拦。阿里云这类服务商的免费证书现在续期流程简化了不少但自签名的还是得自己管。我的做法是写个脚本定期检查证书剩余天数快到期了自动重新生成并 reload Nginx。这个脚本不复杂核心就是openssl x509 -checkend加一个 cron 任务具体实现可以根据自己的环境调整。提示无论用哪种绕过方式都请记住它的定位是“开发调试的便利工具”不是“生产环境的解决方案”。生产环境的证书问题老老实实走正规 CA 签发和正确配置别想着绕过。这套东西说到底就是一句话知道自己在干什么知道风险在哪然后选一个匹配当前场景的手段。临时看一眼用thisisunsafe长期开发配启动参数加独立实例想彻底干净就把根证书装进系统信任区。三条路各有各的适用面别拿锤子看什么都像钉子。