为内部服务正确地使用 TLS 证书

Split-horizon DNS 与替代方案

• 许多人批评 split-horizon DNS 脆弱且维护成本高，尤其在大规模场景下更是如此（记录重复、缓存怪异、VPN 路由问题）。
• 也有人认为它在小型/家庭实验室环境里没问题，并且可以和 hairpin NAT 结合使用；真正的痛点是大型企业环境中，内部和公网区域共享同一个名字。
• 还有人明确拒绝使用 split DNS，宁愿采用带内部 IP 的单一公网区域，或者使用 overlay 网络。

ACME、DNS-01 与自动化模式

• 强烈偏好对内部服务使用 DNS-01 验证，而不是 HTTP-01。
• 常见模式：
  • 使用带 DNS API 的公共域名来获取证书（通常是通配符证书），然后把名称指向内部 IP。
  • 使用 CNAME “_acme-challenge” 别名，把 DNS-01 委托给单独的区域/提供商，或像 acme-dns 这样的工具。
  • 由中心化的 ACME 辅助服务或 GitHub Actions 持有 DNS 凭据，并为内部主机签发证书。
• 大家对即将推出的 DNS-PERSIST-01 challenge 很感兴趣，因为它可以减少动态 DNS 更新的需要，不过目前支持仍然有限。

公共 CA 与内部 CA

• 一派观点：“直接运行内部 CA，给内部证书签名，并在你的设备上信任那个 CA。”这被视为干净的密码学解决方案。
• 反驳意见：
  • 在异构的操作系统、语言、容器和浏览器之间分发并管理信任锚很麻烦。
  • 有人认为公共 CA（例如通过 DNS-01 使用 Let’s Encrypt）在运维上更简单，尤其是当你无法完全控制客户端设备时。
  • 还存在对速率限制和信任语义的担忧（公共证书只能证明域名控制权，而不能证明组织身份）。

通配符证书、CT 日志与主机名/隐私担忧

• 有些人担心非通配符公共证书会通过 Certificate Transparency 日志暴露内部主机名；通配符证书可以缓解这一点，但会把密钥风险集中起来。
• 也有人并不担心泄露普通的家庭主机名，或者认为攻击面比模糊性更重要。
• 关于是否应把内部 IP 和主机名放进公共 DNS 的争论也很激烈；有人觉得无伤大雅，也有人完全反对。

客户端信任库与工具碎片化

• 多条评论抱怨，为客户端配置对内部 CA 的信任比应有的更难。
• 不同生态系统使用不同的信任库（OS、Java、浏览器、Node、Python/certifi、容器、snap），导致必须反复安装 CA。
• 这种复杂性是一些人即使面对纯内部服务，也偏向公共 ACME 证书的主要原因。

安全模型与访问模式

• 有些人主张 “BeyondCorp/零信任” 风格：mTLS、设备证书，以及带认证的反向代理，而不是 VPN 加 split DNS。
• 也有人依赖 VPN（WireGuard、Tailscale）加内部 DNS，或者使用在中心终止 TLS 并路由到内部服务的反向代理/负载均衡器。
• 关于对仅内部使用的高价值服务采用公共证书是否合适，意见仍然分裂；有人称其为“bogus”，也有人问为什么会有害。