通过 HTTPS 访问私有 IP：证书标识还是主机名？
如果证书如此声明，私有 IP 也可以是有效的 TLS 标识。在 IP SAN 与稳定主机名之间做出选择，然后规划地址变更。
位于 https://10.60.0.25 的服务即使没有 DNS 名称，也可以使用经过身份验证的 TLS。该地址就是客户端必须验证的标识，证书必须准确描述它。需要决定的是，这个地址是否足够稳定、可以充当标识，还是改用主机名更便于维护。VPN 回答的是可达性，而不是这个问题。
把标识和信任处理好，基于 IP 的 URL 就是一种合理的设计。
客户端实际验证的内容
客户端会将 URL 中的引用标识与证书的使用者备用名称进行比对。对于 IP 地址，这意味着一条与该地址相同的 iPAddress 条目。友好的通用名称不能替代它。
RFC 9525 将 IP 地址标识与 DNS 名称区分开，并定义了匹配规则。只把地址放在使用者标签中，或写成 DNS 类型的条目，都不会产生匹配。因此，出现警告时应检查的字段正是 SAN。
信任是第二项独立检查。名称匹配并不能修复不受信任的证书链、已过期的证书，或为其他用途签发的证书。
决策一：地址是否足够稳定，可以充当标识
如果地址在部署的整个生命周期内固定不变，IP SAN 证书就简单而诚实。如果服务可能迁移，每次迁移都会变成一次证书更换和一次协调的客户端更新。
稳定的主机名可以降低这种耦合。客户端使用名称，经批准的 DNS 将其映射到当前地址，地址变更就不再是标识变更。证书仍需要续期，但 URL 不会改变。
在小型环境中，受管理的 hosts 文件条目可以提供映射。它增加了分发责任，但不能取代 TLS 验证。
决策二：客户端将如何信任签发者
对于私有 CA，应通过经过批准的机制把信任锚分发到目标设备。不要训练用户跳过警告，或安装登录页面交给他们的证书。如果你想要公开信任的证书，在据此规划之前，先查看签发者对私有地址的现行规则。大多数公共签发机构不会把私有 IP 验证为公开标识。
检查实际使用的浏览器或应用程序。它的信任存储和验证行为，比操作系统的通用证书文档更重要。要在实际设备上检查，而不只是看控制台。
VPN 网关可能并不是运行 Web 应用的那台机器，因此不要以为隧道证书与它有任何关系。
在地址变更发生之前就做好规划
如果 10.60.0.25 变成 10.60.0.40，旧证书就不再描述该 URL。要把更换和客户端更新一起规划，并且在迁移期间绝不关闭验证。
选择用户将要输入、或应用程序将要配置的标识，然后围绕它协调签发、信任、部署和续期。一个可以访问但警告被忽略的页面，与客户端会验证其标识的服务并不是同一个结果。