STUDIO · SPEC SHEET · UNIT S12
内网 HTTPS：从「不安全」到绿锁
定位：内网系统的「不安全」三个字，比真的漏洞更伤使用意愿
内网部署的分析平台功能再好，浏览器地址栏一顶「不安全」横幅，用户第一反应就是「这东西能信吗」。推动过一次完整的内网 HTTPS 化之后回头看，这件事的技术含量不高，但决策点多、坑全在细节，值得把整个路径记下来。
先说根源：「不安全」到底在警告什么
Chrome/Edge 的「不安全」只有两种来源：站点是 HTTP 明文；或者是 HTTPS 但证书校验不过（自签、域名不匹配、过期）。内网系统九成属于第一种，上 HTTPS 就要面对第二个问题——证书签给谁。商业 CA 不给内网 IP 和内网机器名签证书，这是所有内网 HTTPS 方案的共同起点。
五套方案，从临时到正规
| 方案 | 做法 | 优点 | 代价 |
|---|---|---|---|
| 1 忍着 | 继续 HTTP | 零成本 | 用户教育成本永久存在 |
| 2 自签证书 | openssl 自己签，用户手动信任 | 十分钟搞定 | 每台客户端导入，告警因证书过期复发 |
| 3 mkcert 本地 CA | 生成一个本地根证书装进客户端，再签发站点证书 | 浏览器全绿，一条命令签任意内网域名 | 根证书私钥要保管好，换机要重装 |
| 4 真域名 + 商业/免费证书 | 给内网服务挂一个真实域名解析到内网 IP，用 Let's Encrypt/商业证书 | 最正规，客户端零操作 | 需要一个域名 + DNS 控制 |
| 5 统一网关 | 企业统一证书入口反代 | 一次解决全公司 | 依赖 IT 部门排期 |
最终落地是 3 + 4 的组合：有域名的服务走真域名签发，纯内网机器名的服务走 mkcert 本地 CA。
实操里真正花时间的四个坑
一、证书签什么名字。用户收藏的是 https://机器名.域 还是 https://IP，证书就得跟谁匹配——先统计用户实际的访问习惯，再决定 SAN 怎么写，顺序反了就是返工。
二、过期无人知道。内网证书没有邮件提醒。最后是在服务器上加了一个探测服务：定时检查证书剩余有效期，低于阈值先于用户发现。这个探测后来成了日常健康检查的一项。
三、跳转要彻底。443 开了，80 还开着，用户从旧收藏进去还是明文。80 必须做 301 到 HTTPS，别留着「两个都能进」。
四、客户端分发是行政问题。mkcert 的根证书要装到每台电脑，技术上三分钟，组织上要一封写清楚「为什么装、装的是什么」的邮件。技术方案再干净，这一步做不好照样返工。
价值与可复用方法
内网 HTTPS 的本质不是加密（内网流量本来就在企业网里），是让浏览器不再替你向用户发出信任警告。选型口诀一句话：能用真域名就用真域名（方案 4），不能就用本地 CA（方案 3），自签只当十分钟临时兜底（方案 2）。
配套三件事缺一不可：证书有效期探测、80 强制跳转、一封给全员的通知邮件。做完这三件，「不安全」才会真正消失，而不是换了个地方存在。