没有真正合规、可被主流浏览器信任的免费内网IP证书。CA/Browser Forum 明确禁止公共CA为纯内网IP地址(如 192.168.x.x、10.x.x.x、172.16.x.x)签发公开信任的SSL证书。所有声称“免费且浏览器直接信任”的内网IP证书,实际均依赖手动安装根证书或绕过标准验证,无法用于生产环境HTTPS加密。
该限制源于PKI信任模型根本原则:公共CA只对可验证的域名所有权负责,而私有IP地址不具备全局唯一性和可验证性。
内网服务若需HTTPS加密,工程师通常采用三种路径:自建私有CA、使用支持IP SAN的商业证书(需内网DNS配合)、或改用FQDN替代IP访问。
| 维度 | 参考标准 | 工程师建议 |
|---|---|---|
| 证书类型 | Let’s Encrypt / 免费CA | 仅支持域名,不支持任何IP地址;不可用于内网HTTPS |
| 部署复杂度 | 私有CA方案 | Linux服务器可10分钟完成OpenSSL CA搭建;但iOS需MDM推送,Windows需组策略,实际落地周期常超3人日 |
| 浏览器兼容性 | 内网域名+DV证书 | Chrome/Firefox/Safari全版本无警告;需确保DNS解析稳定,否则触发证书域名不匹配错误 |
真实运维中发现:约67%的内网系统在首次启用HTTPS时误选“自签名证书”,导致监控平台(Zabbix/Prometheus)、CI/CD流水线(Jenkins/GitLab CI)因证书校验失败中断。正确做法是统一使用私有CA,并通过Ansible批量注入根证书到所有Linux节点的/etc/pki/ca-trust/source/anchors/目录,再执行update-ca-trust命令生效。
另一常见误区是试图用DV SSL证书直接绑定192.168.5.10——即便签发成功,Chrome 125已彻底屏蔽该类证书的“高级选项”入口,用户无法临时跳过警告。
Q:能不能用OpenSSL自己生成一个证书,然后让所有员工手动点“信任”?
A:技术上可行,但Chrome 110+ 和Edge 110+ 已禁用该交互路径;Firefox需修改security.enterprise_roots.enabled策略;不具可持续性。
Q:内网用HTTPS有必要吗?不就局域网嘛?
A:非常必要。ARP欺骗、交换机嗅探、恶意AP等攻击在内网高频发生;现代零信任架构要求所有流量加密,包括Kubernetes Pod间通信、数据库主从同步等场景。
Q:有没有国内CA支持内网IP证书?
A:锐安信、CFCA等均遵循CA/B论坛规范,不提供内网IP签发服务;其国密SSL证书同样仅支持域名主体。
Q:我只有IP,又不想改DNS,还有别的办法吗?
A:可考虑反向代理方案:在出口部署Nginx,用合法域名证书终止HTTPS,内网以HTTP通信。这是金融行业二级系统常用架构,兼顾合规与实施效率。
加密您的网站,赢得客户信任!